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 system

Paul S. Earle1, Alex Bittenbinder1, Barbara Bogaert1 and Carl E. Johnson2

1US Geological Survey, Golden Colorado
2Science and Technology International, Honolulu, HI

Abstract - Introduction - Capabilities
Architecture - Installation and system requirements - Closing remarks and future directions - Acknowledgements - References

Abstract

Earthworm is flexible seismic processing system that takes you from the back of a digitizer to a news release while distributing and archiving products along the way. It uses real-time data from a diverse set of instrumentation to produce a wide range of products including: automatic and reviewed earthquake locations, magnitudes, alarms, and numerous higher-level products. It enables the rapid exchange of waveform and parametric data, thus, allowing output from multiple networks to be incorporated for real-time processing and the creation of backup installations. It consists of hundreds of open-source modules that can be used as building blocks for a customized processing system. Earthworm's continued survival is based upon broad community support, the commitment of the Earthworm core development team, dedicated USGS funding, and frequent updates and enhancements. Earthworm's modular design and message passing communications result in a scalable adaptable system for networks of all sizes. The development team is currently improving interactive processing utilities, extending earthworm's teleseismic processing capabilities, developing modules to calculate a wide variety of magnitudes, and integrating new data loggers. The purpose of this article is to provide a brief overview of the system's capabilities, architecture, and installation and maintenance requirements so a network operator can assess the suitability of Earthworm for his or her needs. For a more complete description see the online documentation at http://gldbrick.cr.usgs.gov.

Introduction

The Earthworm project began in 1993 at the US Geological Survey (USGS) in Menlo Park with the initial objective of providing improved automatic earthquake notification. The emphasis of the first incarnation was speed and reliability so a flow-through system was created that had no analyst review capabilities. However, the basic design principles of modularity, system independence, scalability, connectivity, and robustness have (Johnson et al., 1995) allowed Earthworm to mature over the last 10 years into Earthworm v6.1, a system capable of meeting the majority of processing needs of a modern seismic network. Such needs include: interactive review of acquired events, real-time TCP/IP data exchange, association of late-arriving data, incorporation of diverse data types, and production of catalogs and archive volumes. Today, Earthworm development is progressing at a number of cooperating sites, and is coordinated at USGS Golden, Colorado. From here, the earthworm core development team distributes new releases, maintains documentation, and provides support. The ongoing effort consists of two distinct but integrated projects, Automatic Earthworm and Interactive Earthworm.

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.

Capabilities

An exhaustive listing of Earthworm's capabilities and modules is beyond the scope of this article, so only the capabilities that we feel are of most interest to a network seismologist are discussed. We describe how the various modules interact later in this article. The capabilities of Automatic and Interactive Earthworm are covered separately. Some institutions prefer to use only the Automatic system because it does not require the additional expense and expertise necessary to run an Oracle DBMS. In this scenario, a network might use earthworm's automatic processing and real-time data exchange capabilities and use a non-earthworm software package for interactive review that accesses triggered data automatically archived in various formats.

Automatic earthworm

Automatic 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 Earthworm

Interactive 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.

click for large figure

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:

  • Filtering using preset or custom filters
  • Interactive and computer-aided arrival-time and amplitude picking
  • Generous suite of trace-selection and scaling methods
  • Wood-Anderson and other transforms
  • Three-component support, including rotation and particle motion displays
  • Multi-trace and zooming features
  • Concurrent analysis by multiple users
Quick review is designed for rapid, remote review of critical events. In addition, however, it can be used for routine analysis for networks with moderate seismicity. To handle larger networks, the Golden development team is currently completing work on incorporating the Jiggle analysis package into earthworm. Jiggle was developed at USGS Pasadena for routine analysis of data collected on 150 broadband stations by TriNet in Southern California.

click for large figure

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.

Architecture

Figure 3 depicts a high-level schematic of Earthworm. It shows a three-layer model that consists of a top layer (Automatic Earthworm), a bottom layer (Interactive Earthworm), and a connecting middle layer (Oracle database). Trace data enters the top layer and flows through an automatic processing system that outputs event notifications and malfunction alarms. Trace snippets and derived event parameters such as picks, hypocenters, and magnitudes are fed into the database. Additionally, continuous trace data is buffered to waveserver. These data are then accessed by the interactive bottom layer to produce human reviewed solutions and the products discussed in the previous section.


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.

Installation and system requirements

Every seismic network using Earthworm has its own unique mission and resources. Given this and the flexibility of Earthworm, no standard installation exists. The installation time and hardware requirements increase with the complexity of the network. However, a few basic requirements exist for all installations.

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.

Closing Remarks and future directions

Earthworm provides a flexible set of open-source tools for running a seismic network and exchanging real-time data. As with most open-source projects Earthworm relies on community input and participation (Malone, 1998). The Earthworm development team has incorporated many suggestions from the community into new releases. And many user contributed modules are distributed from the Earthworm website. Earthworm support is also a community effort. Questions are posed and answered using the earthworm mail list server. To join, see the instructions given at the end of the Introduction.

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.

Acknowledgements

We thank Dan McNamara, Lynda Lastowka and David Wald for thoughtful suggestions and Lucky Vidmar for Figures 1 and 2.

References

  • Allen, R., 1982. Automatic phase pickers; their present use and future prospects. BSSA, 72B(6), S393-S410.
  • Johnson, C.E., A. Bittenbinder, B. Bogaert, L. Dietz and W. Kohler, 1995. Earthworm: A flexible approach to seismic network processing, IRIS Newsletter, 14(2), 1-4.
  • Klein, F.W., 2002. User's guide to HYPOINVERSE-2000, a Fortran program to solve for earthquake locations and magnitudes, Open-File Report - U.S. Geological Survey, Report: OF 02-0171, 123 pp.
  • Malone, S., 1998. Of Cathedrals, bazaars, and worms. Seism. Res. Lett., 69(5).
  • Wald, D.J., V. Quitoriano, T.H. Heaton, H. Kanamori, C.W. Scrivner and C.B. Worden, 1999. TriNet ``ShakeMaps'': Rapid Generation of Instrumental Ground Motion and Intensity Maps for Earthquakes in Southern California Earthquake Spectra, 15, 537-556.
page 3
Copyright © 2003. Orfeus. All rights reserved.