Proposed Outline of CISN Northern CA Management Center Outlined: 2003/06/02 Last Updated: 2003/08/08 Introduction: This outline was prepared by Doug Neuhauser, based on a meeting between Dave Oppenheimer, Lind Gee, and Doug Neuhauser in June 2003 to discuss how to move foward. Minor additions/revisions from Dave O 7/31/2003 Summary: The CISN Northern CA Management Center for CISN will consist of two redundant Real-Time Seismic Processing Systems (RTSP), one each located at UC Berkeley and USGS/Menlo Park, and will store earthquake parameters in real-time into a replicated database system. Network Services (NS) for the RTSP, such as wave servers, pick/coda servers, trigger servers, and amp servers, will be located at the data acquisition hubs of the BDSN and NCSN, and will provide data resources from the respective networks to both of the RTSP. An RTSP will perform the following functions: a. Earthquake detection and location. b. Determination of amplitude and ground motion parameters. c. Earthquake magnitude determination. d. Creation of ShakeMap e. Determination of seismic moment tensor. f. Determination of finite fault parameters. g. Rapid distribution of earthquake parameters to appropriate CISN agencies and CISN earthquake notification systems. h. Real-time update of earthquake parameters in unified NCAL database in CISN schema. Ideally, the functional core software components of the two RTSPs will be identical in implementation, with differences in communication/interconnection between modules. However, the details of the actual implementation remain to be determined and it is possible that even some core modules may differ (at least initially) between Menlo Park and Berkeley. I. NETWORK SERVICIES (NS): The Northern CA Management Center will utilize real-time data from two primary networks: the NCSN and the BDSN. The NCSN data acquisition is centered at the USGS in Menlo Park, and the BDSN data acqusition is centered at UC Berkeley. There is currently insufficient funds to ensure reliable and robust distribution of all waveforms to both locations. Therefore, a series of base level services will be provided at each location and will serve all RTSP for the Northern CA Management Center (Network Services Figure). 1. Waveserver All waveforms (continuous and triggered) acquired by USGS/MP and UC Berkeley that may be used by the RTSP or archived by the NCEDC will be made available by one or more waveform request services. The waveform servers must provide the ability to retrieve waveforms based on requests made by channel and time interval. TBD: There may be different waveservers with different interfaces. If so, there must be a list of possible wave servers and the wave server type for each data channel. 2. Pick/Coda server Each network acquisition system will provide a source of pick and codas that will be available to the RTSPs. Picks and codas must be marked by the creater so that they are strongly associated with each other. We will start with the Earthworm picker, since it provides the require functionality. TBD: a. Server distribution service: Earthworm import/export? FreeORB? b. Pick filtering: Where is filtering done - by the pick service provider, the recipient, or both? If the server does not filter, it implies an increase in bandwidth, as picks from multiple channels will be transmitted between UCB and USGS/MP. However, if waveforms flow to both centers and are picked in both places, the recipient must still implement pick filtering. c. Do we need 2 (redundant) pickers at each site (USGS/MP and UCB)? (Yes, probably). 3. Amp Server The Amp server will perform continuous real-time processing of waveforms that will be used for magnitude, peak ground motion, spectral amplitude measurements and amp triggers. The output of the Amp Server will be a multi-valued low frequency timeseries (5 second sample interval) that can be distributed to all RTSP systems. The multi-valued timeseries will also contain state-of-health (SOH info) such as whether there were gaps in the input timeseries, and whether the input timeseries is outside of normal useful range (either high or low). We will start with the TriNet rad software and the WDA and ADA Solaris shared memory implementation of the amplitude processing software. TDB: a. Server distribution service: Earthworm import/export? FreeORB? b. Provide data continuously, and/or allow triggered request based on time window? 4. StaTrig server The StaTrig server will compute STA/LTA ratios of waveform channel(s) at a site and generate station trigger messages for that site. This data will be provided to a StaTrig server that will make the data available to RTSP system. We will initially use Earthworm module CarlStaTrig (or a variant of this code) to perform the STA/LTA computation. TBD: a. Server distribution service: Earthworm import/export? FreeORB? II. RTSP SYSTEM COMPONENTS: At each RTSP, there will be multiple modules that examine waveforms or derived parameters to detect, locate, and parameterize an earthquake. 1. Hypocenter Location System: The purpose of the Hypocenter Location System is to detect and locate earthquake using a phase association system, and to rapidly determine an earthquake hypocenter and optionally an initial (coda) magnitude. Picks and codas from the pick/coda services will be fed info a pick filter, which will feed an Earthworm binder system. A process such as eqproc, which can harvest both "quicklook" and "finalized" event views from the binder output, will feed hypoinverse to produce standardized event locations. The outputs from hypoinverse will be fed, along with the event view type ("quicklook" or "finalized") into the event association system. [See Lombard's description of TriNet event association system.] The Hypocenter Location System will be initially implemented with the standard Earthworm rings, pick filter, binder, and an appropriately configured event eqproc module and hypoinverse "sausage". 2. Subnet Trigger System: The purpose of the Subnet Trigger System is to detect earthquake that may be missed by the Hypocenter Location System. By creating one or more subnets of stations, you can use the coincidence of station triggers within a time window to detect an event. The Subnet Trigger system receives station trigger messages from the Network Services servers, and feed them into a subnet trigger program. The output from the subnet trigger program will be fed into the event coordinator (? and possibly the trigger coordinator?). The initial implementation will be based on the Earthworm program CarlSubTrig. TBD: a. Output distribution service: Earthworm ring? FreeOrb? Database? 3. Amp Trigger System: The purpose of the Amp Trigger System is to rapidly detect a large earthquake that may be missed by the other earthquake detection systems. The Amp Trigger System will examine the reduced amplitudes acquired from the Network Services Amp Server to find amplitude values that exceed a specified threshold. A coincidence of large amplitudes at a specified number of stations will generate an amplitude event. The initial implementation will be based on TriNet evtdetect and evt2ps programs. The evtdetect program reads amp data from an ADA (Amp Data Area shared memory region), and places the output event detection messages in an EDA (Event Data Area shared memory region). The TriNet program evt2ps distributes the event detection messages into a publish/subscribe system. TBD: a. Output distribution service: Earthworm ring? FreeOrb? Database? 4. Regional/Teleseismic Trigger System: The purpose of the Teleseismic Trigger System is to save waveforms for teleseismic/regional events. The system could be triggered by messages from NEIC/other nets or by a (not yet designed) a local system that would analyze incoming data to determine whether a teleseism was in progress. Regional/Teleseismic triggers could be fed into the event coordinator. ? Do we have something for a base-level implementation ? TBD: a. Output distribution service: Earthworm ring? FreeOrb? Database? 5. Event Coordinator: Event Coordinator collects event information from multiple sources, associates these into a single event, writes the event information to the database, and notifies downstream modules of the event. The event sources can include: Hypocenter Location System Subnet Trigger System Amp Trigger System [Teleseismic trigger system] When events from different sources are associated together (currently just by a specified time window), the coordinator will consolidate the event info from the multiple sources into a single event. When an event has been finalized from the the hypocenter location module, or has reached the finalization threshold time, it is written into the database, and downstream processes are notified. The event coordinator keeps event information in its memory for specified period of time. When an event's timeout age is exceeded, the event into is purged from from the event coordinator's memory. [See Lombard writeup on event coordinator] TBD: a. Output distribution service: Earthworm ring? FreeOrb? Database? b. Downstream processing: REDI scheduler or separate scheduler for each process? REDI notification scheme or Earthworm notification scheme? c. Unclear on whether we also need TriNet Trigger Coordinator (to drive RequestCardGenerator (RCG) or to coordinate the trigger msgs). 6. First Motion mechanism The FM program will receive event notification that an event has occurred and will compute a first motion solution if the event satisfies the appropriate criteria (?). The output first motion solutions will be written to the database. This does not require writing new origin tables. Downstream processing will be notifed. TBD: a. Output distribution service: Earthworm ring? FreeOrb Database? b. Table revision required (?) c. Wrappping of the FM code? 7. CISN Magnitude The CISN Magnitude program will compute an Ml and/or an Me magnitude for the event. The program will read the hypocenter info from the database, determine the appropriate stations and time windows for the event, read data from the reduced amplitude time series ADA shared memory region, and compute the magnitude(s). The initial code will be based on the TriNet Trimag program. Trimag currently computes an initial magnitude based on a subset of stations near the event, and then recomputes the magnitude based on a refined station list and time window based on the initial magnitude. The CISN Mag program will notify downstream processes that it has computed a magnitude, and will enter the info into the database. TBD: a. If we have an initial coda magnitude, we may be able to skip the initial magnitude computation. b. What do we do if the event is older than the data contained in the ADA? c. Rules for determining preferred magnitude. d. Output distribution service: Earthworm ring? FreeOrb? Database? 8. Amplitude Readings The Ampgen process will receive event notification from the magnitude process, and based on the size of the event, generate amplitude readings for the required data channels based on event size, station distance to the event, and sensor type. The initial code will be based on the TriNet Ampgen process. Ampgen receives event/magnitude notification, and based on the channel selection process, retrieves amplitude readings from the ADA shared memory area. It will write the amplitudes to the real-time database AND the Earthworm amplitude exchange database. If it is the master system, it will generate and distribute strong motion records to CISN partners. The program will notify downstream processing system that it has computed amplitudes. TBD: a. Output distribution service: Earthworm ring? FreeOrb? Database? 9. Shakemap There are several options for incorporating ShakeMap into the RTSP. The TriNet model is that ShakeMap is very loosely coupled to the RT system. It gets notified of an event (by ID); then ShakeMap queries the database to decide what to do. Alternative, ShakeMap could be triggered in the same way that Ampgen or Mt codes will be - based on notification from the magnitude module. This needs more discussion. TBD: a. When do we want to trigger Shakemap to run? b. How do we notify Shakemap feeder / startup? Earthworm ring? FreeOrb? Database? 10. MT/Mw The MT/Mw program will receive event notification that a ML/Me magnitude has been computed (or is not needed), and will compute a MT solution and Mw if the event satisfies the size criteria. The MT code will retrieve the require waveforms from the waveform server(s). The output Mw and MT solutions will be written to the database. A new input and output origin will be written for the MT solution. Downstream processing will be notifed. TBD: a. One or multiple MT algorithms? b. Rules for determining preferred magnitude. c. Output distribution service: Earthworm ring? FreeOrb Database? d. Table revision required for full MT solution. 11. Finite Fault: The Finite Fault program will receive event notification by the MT/Mw process and will run the Finite Fault (FF) software if the event satisfies the size criteria. The FF code will retrieve the require waveforms from the waveform server(s). Due to the computational requirements of the FF code, it will most likely be run on a separate system. Appropriate inter-system notification is required to schedule the FF code on the remote system. The output of the FF solutions should be written to the database, but we currently have no tables for this info. Downstream processing will be notifed. TBD: a. Output distribution service: Earthworm ring? FreeOrb Database? b. New CISN database tables required for FF solutions. 12. Waveform archive: The Request Card Generator (RCG) on the master RTSP system will receive event notification from event coordinator and the trigger coordinator, and depending on whether the event is a hypocenter event for trigger event, will invoke either the event RCG or the trigger RCG. The request card generators will generate a request card with the SNCL, time period, and eventid for each channel to be archived for this event, and will enter the request card into the database. [See Lombard writeup on RCG.] 13. GM Import The GM Import system will import CISN strong ground motion messages from other CISN source and will enter them as unassociated entries into the database. Currently this is an EW schema. TBD: 14. GM Harvester The GM Harvester process will periodically harvest strong ground records from the unassociated ground motion database, and associate it with known events in the RTSP system database. TBD: a. Can we perform this function at the NCEDC by simply putting all imported ground motion values into an unassoc_amp table in the RTSP CISN schema? III. RTSP SYSTEM DATABASE The RTSP database on each of the RTSP systems will initially use the CISN (aka NCEDC/Trinet) schema and will be implemented on an Oracle database server. The event-related tables will be a snapshot of tables of an NCEDC database. We will use snapshot replication to replicate the data from the RTSP snapshot to the NCEDC database. We will have multiple NCEDC databases, with at least one located at UC Berekely, and one at USGS/MP. We will use multi-master replication to synchronize the NCEDC databases. To ensure that no table row from any database gets overwritten with data from another database instance or snapshot, all IDs (such as origin id, phase ids, etc) should be requested from the database. It will be the responsibility of the database administrators to assign ids in a way the enforces this. If an id (such as an external event id from binder) is used as a unique key within the database, we must ENSURE that the ids do not overlap between systems. However, external ids will be STRONGLY DISCOURAGED. IV. NCEDC functions: 1. Waveform archiver: The waveform archiver at the NCEDC will use the request cards in the NCEDC master database to collect waveforms from the waveservers. When a waveform has been successfully retrieved, it will be written to an event directory, and the waveform description and waveform association for the event will be entered into the database. 2. Event analysis: The event analysis tool jiggle will review the events in the NCEDC database that were generated by the master RTSP system. The event review can be performed on any of the NCEDC multi-master replicated databases, but only one database should be designated as the review database at any time. Waveforms for event review will be retrieve from the NCEDC master waveform archive at UCB. V. ALARMING/Response/Review proceedures We haven't talked about this yet. VI. FUTURE THOUGHTS Some thoughts for future (longer term) development: 1. We should address how to dynamically change configuration of the hypcenter location system to allow for updates in channel usage and channel parameters without having to restart the entire pipeline. 2. Should we eventually migrate away from the EW amp exchange database to only one database with a CISN schema database per RTSP system?