Electronic Seismologist Logo
July/August 1999

Steve Malone
E-mail: steve@geophys.washington.edu
Geophyics, Box 351650
University of Washington
Seattle, WA 98195
Phone: (206) 685-3811
Fax: (206) 543-0489


As promised in the last Electronic Seismologist (ES) column (Malone, 1999) a continuation of a review of seismic network recording and processing systems is forthcoming ... sort of. Because of lots of other commitments, a touch of the influenza, lost notes (the dog ate my homework), and other worthless excuses the ES did not do as promised and put the Antelope system through as comprehensive a series of tests as hoped. Therefore he cannot pontificate on its merits from a point of significant experience. However, in the tradition of previous columns (get someone else to do his work for him), he proposes to summarize the pontifications of others. Due to fortuitous timing, the ES, in a previous life, coordinated a report by the Council of the National Seismic System to the USGS on the suitability of the Antelope system for routine seismic network recording and processing. A report has been submitted to the USGS, which is taking it under advisement. This column contains excerpts from that report summarizing the response to a formal "Request for Comments" issued by the Council of the National Seismic System in December 1998 (http://www.cnss.org/Antelope.req.html).

The Antelope system is produced by Boulder Real Time Technologies, Inc. and marketed by Kinemetrics, Inc. It is a commercial product derived from the IRIS-sponsored Datascope package but optimized and enhanced for the commercial market. Its applicability to seismic network use has been demonstrated by its use in the Arabian National Network and in several prototype installations at U.S. regional networks. There is now a significant cross-section of seismic network operators who have experience with Antelope, and some are interested in using it over the long run.

As might be expected, there is no single, unified opinion about the merits of Antelope. It would seem that Antelope is a contentious topic. Feelings can run hot and heavy about specific issues, perhaps none more so than on the issue of networks becoming dependent on a small commercial software company, of which the principals used to work in the public sector on Antelope's predecessor. Many perceive the privatization of a previously public system as an ethical issue. The personal feeling of the ES is that, while it may be distasteful to some, it is neither illegal nor unethical. In fact, it is not even unusual. Many universities permit and even encourage taking research results, funded partially by public funds, and using them for profit. In some cases seismic data collected with public money is repackaged with value-added components and provided as part of financial agreements with private industry. Those parts of Antelope developed under IRIS support are still open and free for anyone to use. Value added to that original package without IRIS support should be paid for in some way. Having a commercial product is one way to do that if there are sufficient safeguards against networks being held for "ransom" in the future.

Responses to a solicitation for comments on Antelope by the Council of the National Seismic System in December of 1998 were received from twenty-two individuals. While the request for comments listed several specific questions, many of the responses were in narrative form without clear organization and not necessarily answering the specific questions. Some were very detailed about specific technical or organizational issues. Some were very general, expressing only opinions or feelings about the issues. Many responses were obviously derived from a fairly clear understanding of Antelope and what its technical characteristics were; in some cases special tests or extra efforts were made to understand it and thus provide comments based on knowledge. Other comments were obviously based on little or erroneous understanding of the system or what it could do. A summary of the crux of many of the comments is given below, divided into those comments generally favorable to Antelope followed by those which are unfavorable. Each summary list is given in order of apparent importance based on the number of responses and persuasiveness of the comments. Some aspects of Antelope were considered as favorable by some and unfavorable by others and thus show up in both lists.

Favorable Comments:

  1. Antelope is or seems to be a very good start-to-end, turn-key system including all of the expected major aspects of a seismic recording system from data acquisition to catalog and map production.
  2. Antelope provides a standard, commercial-grade system which all networks could use to make a true national seismic system.
  3. ORB, the guts of Antelope data-handling technology, is an excellent (the best) way of exchanging data between networks and/or remote nodes in near real-time.
  4. Antelope uses modern, high-quality computer concepts and architecture and was produced by very talented people who can be expected to continue the tradition.
  5. Antelope already is very good at combining different types of input data and is easily extendible to yet others.
  6. Antelope has very useful and intuitive monitors for things such as state of health, loads, real-time waveforms, and maps.
  7. Antelope provides a good opportunity for the IRIS community and USGS-supported networks to improve cooperation on common problems.
  8. The nonvolatile nature of the ORB has many advantages over other similar techniques for robustness and data availability.
  9. Antelope has a built-in, simple, and efficient DBMS system for quality control and efficient organization.
  10. Antelope has many similarities and compatibilities with Earthworm and thus can be used in a mixed situation.
  11. Antelope can do real-time earthquake location and notification.
  12. Antelope is now completely Y2K compliant.
  13. Antelope has better picking and locating ability than other systems currently in use.

Unfavorable Comments:

  1. Antelope could end up producing a commercial monopoly, making much of the U.S. seismic network community at the mercy of BRTT/Kinemetrics.
  2. Conversion or start-up hassles would be very large and costly for those not familiar with Datascope.
  3. Source code is proprietary or closed and developed only by a small staff.
  4. The Datascope system has responsiveness and file/record locking problems generating a major hassle for large networks or high event rates needing multiple simultaneous review sessions.
  5. The CSS 3.X database schema used for Datascope does not have all the parameters that many want or need.
  6. The ethics of converting a publicly funded system to a commercial, for-profit system are poor and not to be encouraged.
  7. The built-in Datascope DBMS is home-brew, not SQL, and is limited compared to modern commercial ones.
  8. No direct A/D system is part of Antelope.
  9. ORB has significant technical problems or limitations for very high-volume situations, questioning its reliability.
  10. Antelope runs only on Solaris; some networks have only expertise in NT.
  11. Low performance and responsiveness of Tcl/TK for displays slows manual analysis.
  12. There are worries about responsiveness of BRTT for bug fixes or consultation or enhancements.

Some Additional Thoughts from the ES

The number and type of favorable comments are similar to those of the unfavorable comments, indicating that there is no consensus or even majority opinion on the merits of Antelope for seismic network recording. There were several very strong supporters of Antelope who were obviously very familiar with it and who made thoughtful and persuasive arguments in its favor. Many of the unfavorable comments were relevant only to some situations. The unfavorable comments seem to fall into the four following general categories:

1. Technical concerns about the speed or efficiency or completeness of Antelope for handling certain, particularly large, network requirements.

Some of these comments are likely quite valid; however, they are probably mostly a function of network size. The bigger networks have unique problems as well as local staff and resources to solve them. Antelope is reported as currently being used quite successfully at three medium-sized networks (Alaska, Nevada, and ANZA), indicating that these performance problems may not be an issue for other similar-sized or smaller networks.

2. A concern for the amount of time and effort it would take to switch to Antelope from the current system and the associated costs.

This applies to any major change in a network operating environment, not just Antelope. The concerns here seem to be partly from those who have a working system now and feel that they gain little but hassle if they were to change to Antelope. Others seem to be concerned that Antelope and Datascope are fairly complex systems which will require considerable effort to learn, and without help it will be a very long, difficult, and perhaps unnecessary process.

3. A concern for seismic network dependency on commercial or proprietary software developed by a small, perhaps isolated team.

The concern for becoming dependent on a proprietary system without source code access is a serious issue. There are, of course, many proprietary aspects to any complex system, and thus this should not be a complete show stopper. From the ES point of view, more important than the commercial aspect of Antelope is its closed source code and reliance on BRTT for development of critical parts. No two networks are alike, nor will any one set of programs solve the problems for all. To Antelope's credit, it provides many application programming interfaces (API's) or "hooks" to be used for adapting special procedures or data types, but that is not a guarantee that all future needs can be met. Of course, some might argue that having a major part of such a system controlled by a small talented group is a good thing because it enforces a de facto "standard" on all using the system. Based on the expanding numbers of formats, protocols, and interfaces confusing the exchange of data between, to, and from networks we have seen in recent years, the ES might agree with this assessment.

4. There already is a seismic recording and processing system (Earthworm) for community use, so why worry about yet another one?

For several reasons, many seismic network operators do not think that Earthworm does or will provide all that is needed. Several operators who now express strong interest in using Antelope have tried Earthworm or parts of it and seem to feel that it is not as complete, efficient, or effective as Antelope, though most use parts of Earthworm along with Antelope. The lack of a coupled or supported manual analysis system for Earthworm is a major drawback for some. There also seems to be some general dissatisfaction with Earthworm support provided for those places where Earthworm was previously installed. Many comments suggest the two systems are partially complementary and that each could meet many of the needs of most seismic networks.

As mentioned before, the ES has a strong personal preference for the development strategy originally outlined for Earthworm (Johnson et al., 1995) in which an open, "adaptable, scalable seismic data processing system that can evolve with technological trends" would provide a basis for regional seismic network operations in the U.S. This system would have an "ability to readily incorporate preexisting computer code" and provide committed support which would "range from supplying turn-key services to accepting suggestions and contributions." This seemed to the ES to be a good way to have the community involved in, and contributing to, the development of a useful system. Based on many of the comments received, this original concept of having Earthworm be a community effort, both in determining the direction it was to go and in contributed modules, has not worked. While many important contributions to the Earthworm system originated from outside the USGS Earthworm team, something broke down in this process for continued development for some groups. Some users of Earthworm modules or concepts have not reciprocated by feeding back modifications or new modules to the core system, i.e., taking without giving back anything. While several networks are currently successfully using Earthworm as their main automatic recording and notification system and are exchanging data between networks, there is a perception by a significant number of networks that it is or will not be appropriate for them.

Where the fault lies in this apparent failure of providing a system for everyone is a mystery to the ES. Likely there is no one model or system that will be satisfactory for everyone. There certainly is room for two well supported, at least partially competitive recording and processing systems for seismic network use. In fact, a little competitiveness may be a good thing. As long as the two systems can cooperate on some levels, as they seem to do now, having them push each other may be a win-win situation for the rest of us.


Malone, S. (1999). Seismic network recording and processing systems I, Seism. Res. Lett. 70(2), 15-178.

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.

SRL encourages guest columnists to contribute to the "Electronic Seismologist." Please contact Steve Malone with your ideas. His e-mail address is steve@geophys.washington.edu.

Posted: 22 July 1999
URL's updated: 21 January 2003