SEISMIC NETWORK RECORDING AND PROCESSING SYSTEMS (continued)
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.
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 firstname.lastname@example.org.
Posted: 22 July 1999