|Observatories and Research Facilities for EUropean Seismology|
|Volume 5, no 1||March 2003||Orfeus Newsletter|
Turn to the worm: Seismic network operation using the USGS Earthworm systemPaul S. Earle1, Alex Bittenbinder1, Barbara Bogaert1 and Carl E. Johnson2
Development and support of Automatic Earthworm follows the original objective of providing rapid and reliable earthquake notification. The original flow-through model has been extended with a capability to store and serve up to months of continuous trace data, as well as the ability to extract and store event data in various formats, permitting interactive review with various existing analysis tools. Other enhancements include the implementation of a new message-exchange mechanism, and various new flow-through modules to support teleseismic processing. Automatic Earthworm continues to be a modular, stand-alone product that can be configured to perform a variety of tasks, ranging from data relay nodes to complete automatic processing centers. It is operational in a large range of applications, and has become extremely stable.
The bulk of current development work is concentrated on Interactive Earthworm. It is a more complicated beast requiring an Oracle DBMS, associated interface codes, and a web server. Configuration and maintenance requirements are considerably higher than for the automatic system. This increased complexity allows for a greater number of services and interaction modes including web-based review. The objective is to provide a platform for implementing new tools for regional and global seismic processing.
A diverse global community has grown around Earthworm's open-source model. Currently there are over 65 registered installations running on networks ranging in size from a few seismometers to thousands of channels. Users include all major US regional networks, US and foreign volcano observatories, the USGS National Earthquake Information Center, and numerous foreign national centers. Additionally, many Earthworm derivatives have evolved to meet the specific needs of different institutions. Many of these institutions monitor phenomena other than earthquakes including: volcanoes, lahars, tsunamis, and geomagnetic storms. This diverse set of users communicates through the earthworm mail list sever. To join, go to http://lyris.nmt.edu, click workgroups, then click earthw and then click join earthw.
Automatic earthwormAutomatic Earthworm can acquire data from most commercial digital data loggers (e.g., K2, Guralp, Nanometrics, RefTek, GeoTech, Quanterra, PC Systems Design) as well as PC-based digitizers capable of acquiring hundreds of channels. Serial as well as IP communication protocols are supported, permitting a variety of urban telemetry methods, such as radio, voice telephone, frame relay, ATM, Internet, or DSL. Data can also be acquired from traditional dial-up triggered stations.
Earthworm currently has two data exchange methods. One, import-export, provides a method of very rapid exchange of any internal message streams between distant Earthworms. This functions over any telemetry link capable of supporting the TCP/IP protocol, and serves to link distant Earthworms to any desired degree, from simply exchanging real-time sensor data between independent institutions, to completely blending the distant systems into one installation.
The other exchange method is via waveServer. This permits up to months of continuous sensor data to be stored in an Earthworm system, and to be served to distant clients on request. A large suite of such client modules has been developed, such as continuous archivers, manual and automatic event extractors, and interfaces to other packages.
Once the data is acquired it can be filtered and decimated before being processed by a set of modules that perform the basic seismic monitoring tasks. Automatic pick times and amplitudes are calculated using an STA/LAT algorithm (e.g., Allen, 1982). This algorithm is tuned for local and regional P-wave arrivals but sometimes triggers on teleseismic and S arrivals. These picks are then associated with trial epicenters using a binding algorithm. Additionally, events can be detected using an STA/LTA coincidence or a low-frequency detector for volcanic applications.
Trial locations produced by the associator can then be pre-processed in various ways to minimize spurious detections, and then passed to a locator. For location, Earthworm uses Hyp2000, a stand-alone version of hypoinverse (Klein, 2002). Automatic earthworm has a number of magnitude estimation modules that can calculate mb, Md, Ml, MbLg, MwP and Ms.
If an event meets a selection criteria or a system malfunction is detected, Earthworm issues notification via e-mail or pager. After an event has been processed it can be archived to disk in common formats including SAC, AH, PC-SUDS, SEISAN, and GSE. Additionally, using the before mentioned waveserver, all acquired trace data can be made available via the internet for a period ranging from hours to weeks.
Automatic earthworm also has modules for displaying waveform data. It can display animated real-time waveforms (NT systems only) and generate gif format helicorder displays (e.g., http://heli.cr.usgs.gov) for monitoring waveform quality and posting on the web.
Interactive EarthwormInteractive Earthworm's remote access capabilities allow a seismologist to leave the dinner table, manually review an earthquake, display record sections, map seismicity, notify emergency response personal, and return for dessert.
Most interactive tools are accessible via the web and are implemented using commercially available web technology. This provides solutions to many noxious problems such as: platform independence, performance, remote access, security, graphics, communication links, and protocols. Currently, the core interactive tools are getlist, quick review, and alarm manager.
Getlist helps the analyst select and review events. An analyst can display an interactive seismicity map (Figure 1) and get a listing of events matching specified search criteria. The map images event sizes and locations and the event list shows the event parameters and processing status. These pages allow the analyst to do numeric editing of selected pick parameters, and relocate the updated events. Once an event is selected, trace data can be graphically displayed along with additional parametric data. Then data associated with the event can be copied to the user's computer or analyzed using the web-based quick review tool.
Figure 1. Example of the interactive getlist map interface. The user can navigate to a desired region and select target events for detailed analysis. Click figure to see larger image.
Quick review is a web-based earthquake analysis tool (Figure 2). It is a customized version of SeisGram2K, a java applet written by Anthony Lomax (http://alomax.free.fr/software.html). Using quick review the user can produce authoritative reviewed locations and magnitudes by changing existing automatic phase-arrival and amplitude picks and creating new picks. Other quick review features include:
Figure 2. Example of the quick review interface. Quick review allows an analyst to manually review and relocate an earthquake from any place with access to the web. Click figure to see larger image.
Alarm manager is a flexible tool for managing earthquake notifications. Earthworm can deliver these messages by e-mail or pager. The main component of the system is a sequence of web forms that interact with the database allowing the user to manage recipients, formats, and criteria programs. Alarm messages can be tailored to a user specified format in which event-specific parameters such as location and magnitude are automatically inserted in the desired place. Additionally, alarm criteria can be customized for a given recipient, so you don't wake your boss up for every magnitude 2.0 event.
In addition to interactive analysis, Earthworm can automatically generate strong-motion parameters such as peak acceleration, peak velocity, and spectral acceleration values at several frequencies. These parameters can be reformatted by Earthworm and fed into the USGS ShakeMap package (Wald et al., 1999, http://earthquake.usgs.gov/shakemap) to automatically generate maps of ground shaking.
Figure 3. High-level schematic of Earthworm's three-layer architecture.
The guts of the top layer, Automatic Earthworm, consist of a flexible toolkit of processing modules that are connected by a message passing system. Each module conducts a specific task and can be run independently of other modules. A few example tasks include: data acquisition, phase picking, and system health monitoring. Modules communicate by broadcasting and receiving various messages using a set of standard communication modules.
Significant properties of the communication scheme are that: (1) a module cannot be prevented from broadcasting a message whenever it chooses; (2) any number of modules can listen to some sending module(s) without affecting that module; (3) a module receives only the messages of interest to it and it is notified if it missed a message.
The message passing operates within one computer as well as between different computers. Standard TCP/IP network broadcasts (UDP) are used to carry a batch of messages between computers and shared memory regions are used to simulate such broadcasts within a computer. Thus an Earthworm system can be configured to run on any number of computers to meet the needs of a specific installation. Messages can also be shared across the internet between remote Earthworm installations via import/export modules.
The architecture of Interactive Earthworm is conceptually simple but its details are quite involved. Communications rely less on message passing and more on Application Program Interfaces (APIs). Earthworm programs primarily exchange data through the database. Any program that reads from or writes to the database must do so through an extensive set of APIs developed for Earthworm. Some example APIs include CreateEvent(), GetEvent(), CreateMagnitude() and GetMagnitude(). These APIs aid development and greatly reduce the chances of database contamination.
Both computer and seismological skills are necessary. Computer related tasks include: interfacing to communication links, integrating computer hardware, establishing network connections, configuring most modules, and setting up the Earthworm database (if Interactive Earthworm is used). Seismological tasks include selecting and configuring the desired seismic processing modules. In particular, configuration of the location and magnitude modules requires significant seismological expertise. The seismologist must also coordinate data sharing agreements with other networks.
Automatic Earthworm does not require a DBMS so installation requires no proprietary software and no Oracle skills. An automatic system can be installed in about a week by a competent staff running a modest sized network. The additional installation of Interactive Earthworm with its DBMS and remote review capabilities takes several days if a skilled database administrator is available. These times are loose estimates and unforeseen problems can arise that can extend this time even for the most competent staff.
Hardware requirements are flexible and scale with network size. Earthworm is currently supported on Win32 and Solaris platforms, although some modules are platform-specific due to available hardware, such as digitizing, which is available only on "WinTel" platforms. A modern PC or Sun machine is adequate for a modest sized regional network handling about 100 channels running Automatic Earthworm. Where as, large networks, like USGS Northern California Network, require a few dozen machines to process and serve about 1000 channels.
Interactive Earthworm usually requires a dedicated computer to run the DBMS. Currently this is Oracle, Standard Edition, version 8. It offers a network-based service to which applications can attach, request data transfers, and then detach. Such a DBMS supports many concurrent, independent users possibly running different "instances". Thus, Interactive Earthworm does not require its own physical database; it can operate using a department-wide or remote DBMS.
Adequate disk space has to be provided to hold trace data from triggered events until they are moved to off-line media. The space necessary depends on seismicity levels and time of storage. Additionally, waveform storage and distribution provided by waveserver require disk capacity and network bandwidth. The necessary capacity is roughly equivalent to the amount of data to be stored in the circular buffer plus an overhead factor of about ten percent. Network bandwidth requirements for the waveserver are critical on the input side, as the trace input streams are real-time. However, bandwidth for server-side responses is not as critical.
Earthworm is an evolving system. We mentioned the current development focus was on interactive analysis tools but other improvements are forthcoming. These include seamless real-time integration of temporary and permanent station data, state-driven DBMS processing, real-time transport of non-seismic sensor data such as GPS, magnetometer, tide gauge, tilt meter, and acoustic flow monitors, and client-server applications for monitoring system functions including waveform latency, real-time earthquake locations, state-of-health.