A Proposal For a
Seismic Recording and Processing System For Northern California
The following schematic describes a processing system for a joint Berkeley - Menlo Park seismic array. It presumes that a relatively high-speed communications
pipe between the two sites is available to allow the current network topology to be balanced with respect to where the short-period vertical and broadband instruments are recorded. It also presumes that in the event of the complete failure of this pipe there is sufficient redundancy in terms of coverage and instrument type that each side can produce workable, all be it sub-optimal, earthquake estimates.
The various boxes in the schematic have the following functions:
Packet Switcher: A number of functions are lumped together in this box. The data from the stations is either already packetized or it is put into packets and these are copied onto the three outputs and a pre-selected set are shipped on the high-speed link across the Bay. The three outputs are the Wavepool, Amp Pool, and the real-time processing thread. The functions of the box could probably be constructed from EW and Comserve software and several of the functions can be found in the TriNet system.
Wave Pool: This functions like a tape-recorder of the system by placing the incoming data in ring buffers that have capacity of several days of record time. It supports a simple API to allow processes to retrieve data from the pool both locally and over the internet (data center). It will probably need a 15-minute memory cache to make it sufficiently efficient to keep up with the real time system in a major sequence.
Amp Pool: This is a sequence of ring buffers that contains several flavors of maximum amplitude measurements in sub-sampled windows (say 5 secs). They are computed for all appropriate channels continuously regardless of earthquake activity in order to avoid processing spikes during earthquakes. The pool has an API that will return the amplitude values for a given station at a particular time. This API will connect through the low-speed link to the parallel system.
Real Time Thread: This starts the system that will provide locations, magnitudes, alarms and moment-tenor information, as well as populate a database.
Picker: Reduces the incoming packet stream to a sequence of event detections on each channel which are then passed into the associator either directly or through populating a database. The "picks" are also copied to the parallel system through the low-speed link.
Associator: Receives picks from both the local system and remote system and collects them into events which it passes on to the event step. The locator must be able to ignore duplicate picks. Unassociated picks either die here are are left in the database for some length of time
.
Event. Receives preliminary locations and picks from the associator, and relocates the event with a more sophisticated algorithm and velocity model. It gets the magnitude estimate from the "Mag" program and moment tensor from the "Moment" program which takes as their input the estimated location. If an event is kept, that is it passes certain quality controls on the number of reporting stations and errors in parameter estimates, then it is put into the database. This means that the event, origin, arrival, and amp tables are populated along with their association tables. The "event" generates request cards for the seismograms with a magnitude-distance-time algorithm and places those in the "waveform_request" table. The event also starts the alarm process which then reads the database. The "event" program may also attempt to coordinate with the "event" program of the parallel system.
Mag. This program estimates the local magnitude starting with the estimated origin provided by the event program. Amplitude readings at the appropriate times are obtained from the Amp Pool either locally or through the API over the slow-link to the parallel system.
Moment. The components for the static moment tensor are obtained by cross-correlating the waveforms with calculated Green's function for orthogonal sources. The correlations are done either locally with waveforms from the local Wave Pool or remotely with an API over the low-speed link to the parallel system.
Database. The real-time database is an integral component of the real time system and may run on the real-time computer itself. Its data is replicated (but not immediately deleted) to the Data Center database on a rapid time scale (a few seconds). If the link to the Data Center is interrupted, replication will wait until it is re-established and analysis of the data can be done on the real-time system, with modifications passed on to the Data Center.
Data Center. The Data Center receives database replications from both systems with the "source" field in the tables being used to distinguish the origin of the entry. One of the recording systems will be the "master" at any given time, and its "event" table entries will be marked with "selectflag=1". This is a first approximation of the best estimate of parameters for the event. Subsequent analysis may change this. The Data Center is responsible for retrieving the waveforms that were requested by the "event" program. A strategy will need to be developed to determine which Wave Pool the data are retrieved from. The alarming function will be carried on by the Data Center so that significant updates to earthquakes are sent out.
An alternative to a single on-site real-time database is to separate this function into two on-site databases. This variation is shown in the following schematic. The first (the real-time database) can be considered to be part of the real time processing system. That is, it is a place for programs to put various parameters and estimates so that other programs can read them. In the TriNet, model that parameters are explicitly passed to processes through a publish/subscribe mechanism. Additional processes (i.e. new experimental applications) are accommodated as new subscribers. Here, the processes are notified of a change and they get the parameters from the database. New process will simply be additional readers of the database.
The second database (the local analysis database) is the one that is available to do analysis from and is the home for higher-level processes such as moment-tensor inversion and slip-function estimates. This will likely be placed on a separate computer to prevent interference with the real-time system. Depending on the compatibility of the schema, the movement of data from the real time database to the local database may be a replication function or a more complicated translation function. The local database will be replicated to the Data Center machines as in the first schematic.
