Earthworm Interactive
Overview
v6.1
April 16, 2002
OBJECTIVES
Version 6.1 is mostly a refinement of v6.0. A number of bugs and deficiencies have been fixed, and the strong motion (Urban Hazard) feature has been significantly enhanced.
OVERVIEW OF FUNCTIONS:
In general terms, v6.0 offers the capabilities described below. A more specific list of new features is given the section "Specific Features".
It permits data acquisition from analog and digital sources, including most commercial data loggers. Considerable effort was dedicated to meet the requirements of urban strong motion monitoring. This involved integrating traditional K2 instruments as real-time, continuous data sources. 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 from traditional dial-up triggered operations has also been integrated.
The resulting data streams can be used to produce automatic event locations, and to compute coda and local magnitude estimates. In addition, automatic ground motion parameters can be computed. Ground motion parameters from a variety of sources and institutions can be acquired and accumulated. All such accumulated parameters can be automatically presented to the USGS ShakemapII package to produce a sequence of shakemaps of significant events.
The system permits rapid exchange of all such data with other systems. Thus, data from other networks can be incorporated for real-time processing and other sites can be configured to operate as backup installations. Such data exchange methods, in conjunction with the database features, can also be used to establish a hierarchy of mutually supporting systems with local, regional, and global mandates.
An underlying real-time Oracle(r) database is used to accumulate and store all event parameters and associated sensor data. This is designed to provide a finite, fixed-length history of automatic and interactive data generated by the system. Archiving is currently limited to extracting events in SAC format, or as Oracle backup volumes; more archiving methods will be developed, including automatic transfers to Data Centers.
In addition to real-time operation, the system can be loaded with sequences of historic data for research and educational uses. The database also permits of loading of data from temporary deployments and the association of such data with existing events in the system.
Most interactions with the system are via web pages. This approach offers a number of advantages: It 'rides' on the commercially available web technology, which provides solutions for many noxious issues such as platform independence, performance, remote access, security, graphics, communication links, and protocols.
The interactions have been designed for use by trained scientific and technical staff, not for public use. Thus, the emphasis has been on high information content and rich interaction modes rather than intuitive operation. It is assumed that training and practice will be provided before an operator can efficiently interact with the system. Similarly, no effort has been made to support high-volume usage, or to protect against hostile use. The expectation is that these web pages will be password protected and that each installation will manage passwords and general network security to its satisfaction.
Interactions with the system fall into three general areas: displays of event data, manual review of events, and control of alarms.
The user can specify event criteria and obtain maps and lists of events meeting such criteria. From these, the user can then obtain more detailed descriptions of events, including parametric and graphic trace data displays. Selected events can be moved to the user's computer in SAC format.
The 'Quick Review' feature provides the duty-seismologist with a rapid, remote tool for editing picks and event parameters, recomputing the solution, and issuing alarms and recalls.
Alarms, automatic and manual, can be controlled via a web-based interface. This allows the creation of alarm types and formats, maintenance of the recipient list, and setting the event criteria, which will trigger alarm delivery.
SPECIFIC FEATURES:
Alarms:
Alarms and notification schemes tend to be quite installation-specific. Our approach therefore, was to obtain requirements from several representative institutions, and to produce a 'first approximation' alarm sub-system meeting the requirements common to these institutions. However, the design is quite general, and the intent is to produce a series of enhanced versions to meet demands as they arise. Functionally, the current version appears as four components:
The design permits easy addition of arbitrary criteria. Similarly, the currently implemented delivery methods are
Additional methods can be readily added. Automatic Alarms: This appears as a utility, which is called by all software modules, which create or modify the parameters of an event in the database. The utility will cause the alarm sub-system to issue all automatic alarms, which meet the criteria of the new event parameters.
Quick Review:
This sub-system is designed to provide the duty seismologist with a remote review capability. The objective of this sub-system is to address the needs of two areas: Rapid response during seismic crises, and routine analysis for regions with low seismicity.
Rapid response features include:
Features for low-volume analysis include:
Operationally, the user can select an event for review from a map or event list. The map offers a quick, intuitive view of event sizes and locations. The event list shows a summary of the event parameters and processing status. Once an event has been selected, a series of event-specific pages offer quick-view summaries of event parameters and associated trace data. These permit quick numeric editing of selected pick parameters, and event relocation. For more detailed analysis, one can invoke an applet which permits graphic interactive pick review. This applet (a customized version of SeisGram2K) offers a generous suite of interaction modes and features, including:
Picks can be edited as desired, and returned to the server when done. From there, the user can choose to recompute location, coda, and local magnitude. After reviewing the solution, the process can be repeated if desired, the event can be deleted, or re-inserted into the database as the reviewed solution for that event. The user then has the options of either executing or suppressing any alarms based on the new solution. If such 'reviewed' alarms are selected, the user has the option to edit or cancel any alarms.
Local Magnitude support:
This consists of an automatic module ("localmag"), and an interactive capability. Both support either the peak-to-peak, or the zero-to-peak methods. It is assumed, however, that an installation will adopt one method.
The automatic module is triggered when an event location is produced by hypoinverse. It collects trace data from WaveServers, computes the Wood-Anderson traces, picks maximums (time and value), and computes a Ml estimate. The resulting ml estimates are stored in the database as part of the automatic solution.
Manual review of ml is part of the Quick Review feature. When reviewing an event, the user is presented a list of channels with automatic amplitude picks. Selecting one of these channels causes the review applet to display the transformed Wood-Anderson trace and any automatic picks. The user can then manually edit the picks, or request the applet to automatically find the maximum value within a specified window. The user may also make new amplitude picks on any channel for which the poles and zeroes are known. When the pick editing process is complete, ml is recomputed using the same "localmag" code, and the results are stored as part of the reviewed solution for that event.
Strong Motion Support:
This currently consists of the following components:
I. ShakeMap support:
II. Strong Motion Data Archiving and Retrieval:
This feature was developed at the request of the Urban Hazrads program at Golden, CO. It permits time history files (.evt) from K2 instruments to be input into an Earthworm database, automatically associated with seismic events, and then selectively retrieved as raw data, or corrected to acceleration, velocity.
Such a data base can be a 'static' repository, in that the seismic events are loaded via a catalog of earthquakes, or it can be a 'live', real-time data base being continuously fed event parameters from automatic and interactive processing.
The retrieval method is via web pages, which can be passworded if requried.
Enhanced trace data saving:
Automatic events are stored along with 'snippets' of trace data. The module storing such snippets has been enhanced to store all channels participating in the automatic solution, a list of mandatory channels, and channels falling within a user-specified magnitude-distance relationship. All such 'snippets' are presented by epicentral distance for picking by Quick Review.
DBMS API:
A major design principle of Earthworm DBMS efforts has been that all applications interface to the database tables only via a suite of interface routines (API). This middle-ware layer imposes additional coding effort, but it provides several critical benefits: It prevents ill-written applications from damaging the integrity of the data base; it shields the authors of applications from having to know the schema and DBMS access languages, it manages the connections to the DBMS, and it offers a clean interface for any future ports to other DBMSs. This API has been in a rapid state of flux.
With v6.0, however, the API has been stabilized and documented to the point where all changes from v6.0 on will be backward compatible. That is, any changes to the API will be such that any application which ran on the v6.0 API will continue to function.
All-on-Windows:
A previous Solaris-only constraint has been removed, making the entire v6.0 package operational on Windows 2000 as well as Solaris. This was done to support small, installations with limited resources, which require the Windows-Intel platform.
DATA BASE MAINTENANCE:
Since Earthworm v6.0 relies of the database for many of its functions, this raises the issue of data base administration (DBA) support. For a modern DBMS like Oracle, this is a fairly involved craft, requiring specialized skills, experience, and software.
Fortunately, such databases are fully remote accessible, which allows all DBMS functions to be viewed and corrected via the Internet. This has given rise to the remote-DBA service industry. We are contracting with such an agency, which promises 24-hour, 7-day-per-week monitoring of any Earthworm v6.0 database which can be accessed via the Internet.
| U.S. Department of the Interior,
U.S. Geological Survey, Reston, VA, USA Questions? Issues? Subscribe to the Earthworm List (earthw). Privacy Statement || Disclaimer || FOIA || Accessibility |
Date last modified: April 16, 2002