- © 2014 by the Seismological Society of America
Seismic networks have over the last 10–15 years become nearly exclusively real‐time networks. The software used for data collection is both commercial and largely public domain. The two main public domain real‐time detection systems are Earth Worm (EW; Johnson et al., 1995; http://www.earthwormcentral.org; last accessed March 2014) and SeisComP3 (SC3; www.seiscomp3.org). Both systems receive data in real time, perform triggering, store data in a continuous manner, and automatically determine location and magnitude. For a comparison and evaluation of the two systems, see Olivieri and Clinton (2012). EW and SC3 read data sources using different communication protocols. However, the SeedLink protocol for data exchange, used with SC3, has more or less become the public domain standard for real‐time data transmission due to its simplicity and reliability, and many instrument manufacturers now offer SeedLink as a standard for their seismic field stations. Although both systems provide some degree of automatic processing (SC3 has rather sophisticated automatic location and magnitude ability), most seismic networks would want to do manual processing of some or all of the detected events.
Many users transfer the data to the SEISAN processing system (Havskov and Ottemöller, 1999). SEISAN is probably one of the most complete and widely used public domain processing systems available. In 2011, 27% of the agencies reporting to the ISC used SEISAN and reported in SEISAN format (Dmitry Storchak, personal comm., 2011).
SEISAN can also work directly with the SC3 archive making this a simple way to inspect, process, and extract data from SC3.
We have developed a simple data acquisition system, RTQUAKE, which fully integrates with SEISAN. Its main function is to read real‐time data from SeedLink servers, do triggering of events, and store data in the SEISAN database. Some optional automatic processing can also be done. RTQUAKE works with the SeedLink server in SeisComp‐2.5.2006.104 and SC3. To test RTQUAKE, a comparison of the trigger capability with networks using both SC3 and EW is presented.
The SEISAN system mainly works with event data, so for each event there is one ASCII file (so‐called S‐file) containing all parameter data for the event as well as a link to the corresponding waveform file(s) or position in the SeisComp archive. The S‐files are organized in a database‐like structure that can be accessed through a main processing program. The main task for a real‐time system is then to create this S‐file and the corresponding waveform files and put them into the correct location in the database. SEISAN can also work with different kinds of continuous waveform systems, one of which is the archive system (consisting of day files) used in SC3 and earlier SeisComp systems. Thus, the combination of SEISAN and RTQUAKE is a very complete system for event detection and processing of both local and global events using both event files and continuous data. The last version of SEISAN (www.seisan.info; last accessed July 2013) does most of the processing needed at an observatory, including moment tensor inversion and calculation of all standard magnitudes. SEISAN comes with an extensive manual (ftp://ftp.geo.uib.no/pub/seismo/SOFTWARE/SEISAN/seisan.pdf; last accessed March 2014).
REAL‐TIME SYSTEM RTQUAKE
RTQUAKE consists of a series of independent modules written in C using OpenGL and GD (Boutell) for graphics. The trigger‐recording module RTDET is the core module. The user can chose to run the RTDET module only, which is sufficient for detection and recording of the events. Other modules can be included depending on the degree of monitoring that is wanted. Some examples are shown in Figures 1–3. Common for most modules is that they read incoming streams from a SeedLink server (SeedLink clients). The main modules in the RTQUAKE software include
- Detection and recording of events. Reads data from local or remote SeedLink servers. No graphics. Can run as a stand‐alone module.
Optional modules for monitoring and graphics:
- Graphical monitoring of short‐term average (STA)/long‐term average (LTA) for each station.
- Graphical monitoring of triggers for each station.
- Plots selected components in near‐real time. Reads data from a local or remote SeedLink server.
- Graphical monitoring of latency of stations transmitting to a SeedLink server.
- Creating 24 h temporary data files for each specified station as input for 24 h plot.
- Creates helicorder plots of specified station components.
- Prepares a web menu to show helicorder plots in a standard web browser.
Optional module for phasepicking, location, and magnitude:
- Phase picking for each specified channel. This module is optionally started by the RTDET module. It uses SEISAN programs for location and magnitude.
All modules run under Linux, and RTQUAKE has been tested under Ubuntu, Fedora, and Centos. The system is currently compiled to use a maximum of 300 channels. RTQUAKE comes with complete source code and an extensive manual. Here, we will only describe the main module RTDET; for more details of the other modules, see the RTQUAKE user manual (ftp://ftp.geo.uib.no/pub/seismo/SOFTWARE/RTQUAKE/RTMAN.pdf; last accessed March 2014). The software is found at ftp://ftp.geo.uib.no/pub/seismo/SOFTWARE/RTQUAKE (last accessed March 2014). To demonstrate the use of the software, a setup is prepared for data from the plate boundary project in Chile (http://www.ipoc-network.org/; last accessed March 2014), for which open data is available. The system can then, after installation, be started with one command. Because this is a very active seismic area, new events will normally be detected and recorded within a few minutes.
RTDET receives data from one or more SeedLink servers. Triggering can be done with selected channels using standard short‐term average/long‐term average (STA/LTA) triggering on filtered traces, and a standard network detector is used to declare an event. The network detector will declare an event when a certain number of triggers are present within a given time window, the array propagation window (APW). The network detector includes the option of delayed triggering in the case of delayed data from the acquisition systems in the network. The delay can be up to one hour. This will of course not be a good solution for alarm systems, but delayed signals from different stations will be processed in a delayed time window, and event data saved if it arrives within the delayed time. The corresponding waveform file with user‐selected channels (MiniSeed format) is then extracted from the SeisComp archive (several if reading from more than one SeedLink server) and stored in a SEISAN database together with the corresponding trigger times, and the data is immediately ready for further manual or automatic processing. Optionally, refined detection times can be produced by an automatic phase pick module (Filter Picker, Lomax et al., 2012), and the standard SEISAN location program is then used to locate the event and automatically calculate magnitude (ML and spectral‐based Mw; see SEISAN for details). Both local and global events can be located; however, both the phase picking and magnitude calculation assumes a local earthquake. RTDET is a very simple detection system similar to earlier data acquisition systems, for example, Lee (1989) and Utheim et al. (2001).
Several instances of RTQUAKE can be started to read data from the same SeedLink server with different parameter sets in order to trigger on different conditions like local and teleseismic events or different subnets of stations within the same network. This could, for example, be used to run different instances of RTQUAKE with different parameters on overlapping sets of stations to improve detection of events when using heterogeneous distributions of seismic stations. However, if two overlapping networks trigger on the same event, the overlapping stations will be recorded twice. In a large network, the optimal setup is to have a central SeedLink server receiving data from different SeedLink servers (which can be individual stations) and letting RTQUAKE read data from this server. In this way the SeedLink archive, for all stations, will be directly accessible for the SEISAN processing system. Figure 4 shows a possible configuration.
In this configuration, RTQUAKE runs on the same computer as the local SeedLink server receiving data and SEISAN.
Data from different SeedLink servers and stations are fed into the local SeedLink server, and RTQUAKE connects to the local SeedLink server as a client, selecting the components that will be used for detection.
Detections are recorded directly in the SEISAN database with the corresponding S‐file.
The events can be processed manually immediately.
The software includes an automatic phase picking option to include phases in the S‐file. Optionally, automatic location and magnitude can be done based on these readings.
SEISAN has direct access to the SeedLink server archives.
An alternative configuration can be that RTQUAKE reads data from several different SeedLink servers directly instead of through the local SeedLink server. The advantage is that there is no need to install a local SeedLink server; however, there is then no longer direct SEISAN access to the continuous data.
Figures 1–3 show some of the graphical utilities available in RTQUAKE. Several instances of the program can be executed to show different stations, to apply different band‐pass filters, different color schemes, different window sizes, and different positioning on the screen.
The graphics is dynamic in the sense that the user will see the onsets and duration of the triggers slowly moving to the left toward the APW, in which network triggering takes place. The timelines for the APW and current time are positioned statically, whereas the time scale at the bottom changes according to current UTC time.
Normally, the trigger onsets are marked close to real time near the green line marking the current time. In cases where, for example, data transmission is slow, signals may be received with a significant latency. The triggers will, however, be marked on the plot at the correct time of occurrence when data is available. In Figure 2, we allow for a latency of sevenmin which is the total time from the current time to the end of the APW to the left. The APW has been set to two min. As the trigger onsets move toward and into the APW, the network trigger algorithm will decide whetherthere are sufficient triggers to define a network trigger.
This approach ensures that trigger onsets delayed up to seven min still are contributing to the network trigger inside the APW. The allowed latency and APW are set by parameters optimized by the display. Components that cause frequent false onsets can easily be observed on the display.
TESTING OF RTQUAKE WITH REAL NETWORKS
Five different networks with different station densities and seismic activity have been used for this test:
Seismological Research Center, Ataturk University, Erzurum, Turkey (http://www.atauni.edu.tr/#birim=deprem-arastirma-merkezi; last accessed March 2014): comparison with SC3.
Norwegian National Seismic Network (NNSN; www.geo.uib.no/seismo/nnsn), Bergen, Norway: comparison with EW in a low seismicity area.
Integrated Plate Boundary Observatory Chile (IPOC; http://www.ipoc-network.org/): very high‐seismicity area.
Observatorio Sismologico Politecnico Loyola (OSPL; http://ospl.ipl.edu.do/), San Cristobal, Dominican Republic: long‐term test.
Instituto Nicaraguense de Estudios Territoriales (INETER; http://www.ineter.gob.ni/), Managua, Nicaragua: delayed triggering.
The above systems used in the tests operate in different ways due to their location and configuration. They have different parameter sets and use different stations and different numbers of stations. The trigger criteria are different, and both EW and SC3 have more sophisticated trigger algorithms and more adjustable trigger parameters than RTQUAKE. For the tests it has not been possible to set up parameters for the RTQUAKE system that are identical to EW and SC3. The intention with this comparison is not to make an exact comparison of the different trigger systems, but rather to show the capability of RTQUAKE for real networks in comparison with other systems in routine operation. Thus for simplicity, we used the same parameters for all tests for filter band 2–8 Hz, APW (120 s), STA (2 s), LTA (100 s), trigger ratio (4.0), and detrigger ratio (2.0). The only parametric variation between tests was the minimum number of component triggers within the APW to declare an event (4–10). For all tests, all triggered events were manually checked to investigate whether they were real events. The autolocation option requires good data and was therefore only used with the IPOC network.
SEISMOLOGICAL RESEARCH CENTER, ERZURUM: COMPARISON BETWEEN RTQUAKE AND SC3
The center runs an SC3 system with 43 worldwide stations and 26 stations in Turkey. Of the 26 stations in Turkey, 9 stations are from the regional network operated by Ataturk University and 17 stations from the national network based in Ankara (Ozyazicioglu et al., 2012). The stations used in the test are seen in Figure 5 and only detected events with locations within this area are compared. This test was done during a test period from 11 May 2013 to 21 May 2013.
SC3 had no false triggers, whereas RTQUAKE recorded eight false triggers. On the other hand, RTQUAKE detected 34 real events, whereas SC3 detected 12 real events. Of these, 11 events were detected by both systems (Fig. 5). SC3 detected one event in the middle of the network. This event was not detected by RTQUAKE. With the current parameter setting, SC3 seems to detect and autolocate the major events, whereas RTQUAKE detects a lot more of the smaller events. It is important to note that, although SC3 has fewer real events, it does not mean that the events are not detected, but that they do not fulfill the criteria for automatic location. The trigger criteria for SC3 are rather strict in the sense that it needs a certain number of secure readings of phases to do autolocation. This, however, results in loosing smaller events. Events can be retrieved later, but will not be detected and recorded automatically.
THE NNSN: COMPARISON BETWEEN EW AND RTQUAKE
The NNSN (ftp://ftp.geo.uib.no/pub/seismo/REPORTS/NORWEGIAN_NATIONAL_SEISMIC_NETWORK/Decade_2001-2010_final.pdf; last accessed March 2014) runs a SeedLink server/EW system receiving data from 29 stations (operated by the University of Bergen), 11 stations (operated by NORSAR), 3 stations (Finland), 5 stations (the British Geological Survey), 3 stations (Denmark), 3 stations (Sweden), and 1station (Poland). The stations used in the tests are marked on the map in Figure 6. The normal EW setup for NNSN runs several subnetworks to optimize the number of events detected. To have a more correct comparison of the two systems, a separate EW was set up to run only one subnet for the actual area for NNSN. RTQUAKE was set up with the same subnet. The same pretrigger band‐pass filter was used in both systems;however, the other EW trigger parameters (for Carl Johnson’s STA/LTA trigger) are not directly comparable, and the parameters used by the NNSN EW system were: STA=1 s, LTA=8 s, trigger ratio=2, and minimum number of triggers=4. The test was done for the period 17 June 2013 to 08 July 2013. This network has the largest geographical coverage of the networks tested with both local seismicity, along the Norwegian coast and around Jan Mayen, as well as regional seismicity from the Mid‐Atlantic ridge. This kind of seismicity can be difficult to detect due to large distances and low signal‐to‐noise ratio signals. Figure 6 shows a map of station and event locations. RTQUAKE has 33 events not detected by EW, and EW has 23 events not detected by RTQUAKE. In general, EW has a lot more detections than the RTQUAKE system, probably due to the low threshold used by EW. It also has a lot more false triggers. It should be commented that the events detected by one system and not by the other are minor events, which cannot be located or events doubtful to a certain extent. The locatable events were the same for both test systems and are shown in Figure 6. The locations are taken from the standard NNSN system. No additional events were reported in the test region by NNSN, so we can conclude that no significant events have been missed by RTQUAKE compared with routine NNSN operation.
THE IPOC NETWORK: VERY HIGH‐SEISMICITY AREA
A European–South American group of institutions are operating a network of around 20 stations in the northern part of Chile. The data are available in real time through the GEOFON SeedLink server (http://www.ipoc-network.org; last accessed March 2014). RTQUAKE was set up to use 12 stations from the IPOC seismic network (Fig. 7). During one week, 662 triggers were recorded by the RTQUAKE system, of which all were checked and defined as real‐seismic events. That there were no false triggers is not surprising because it was a requirement to have 10 channels triggering to declare an event. Seventy‐nine detections included more than one event in the recordings.
The University of Chile Seismological Service (SSUCH) is using the Earlybird (Whitmore and Sokolowski, 2002) system for detection and automatic location. Earlybird is a modification of standard EW to provide more rapid preliminary locations. They use the IPOC stations and some of their own stations for northern Chile. Processing is initially automatic and events with a magnitude of 3.0 and above or felt are processed manually and published on their website, www.sismologia.cl (last accessed March 2014; Hector Massone, personal comm., 2013). During the test period, 54 events were processed by the Seismological Service to have a magnitude of 3.0 or above or felt. The events detected by RTQUAKE were compared with the 54 events published by the Seismological Service. Fifty of these were also detected by the RTQUAKE system. The four events, which were not detected, were located in the outskirts of the network, north or south, and therefore less covered by the 12 stations used in the test. It should be pointed out that the locations done by the Seismological Service in Chile are based on the complete Chilean network that includes more stations in the actual area. The test indicates that RTQUAKE can operate in a stable manner in a high‐seismicity area and will detect a lot of the smaller events without detecting many false events, in this test none. However, RTQUAKE is not able to separate triggers for two events close in time.
LOYOLA SEISMIC OBSERVATORY, DOMINICAN REPUBLIC: LONG‐TERM TEST
OSPL collects data from 16 stations. Thirteen stations are downloaded from the Incorporated Research Institutions for Seismology (IRIS) SeedLink server and enter a local SeedLink server. Three stations are operated by OSPL, and the data enter directly into the local SeedLink server. Four of the stations are located in neighboring countries (Haiti, Puerto Rico, and Cuba), and nine stations are operated by the National Seismic Network in the Dominican Republic (Instituto Sismologico Universitario http://uasd.edu.do/index.php/es/2013-08-05-16-56-21/sismologico-universitario-isu; last accessed March 2014).
The institute has operated an RTQUAKE system since it started operations in November 2012. Since then, RTQUAKE has run continuously, and until 25 July 2013, the network has detected 302 real events, which have been located manually with SEISAN (see Fig. 8).
We are not aware what has been missed because there is no reliable public database with which to compare; however, the operation seems to indicate that RTQUAKE can provide long‐term stable operation.
INETER, NICARAGUA: PERFORMANCE OF DELAYED TRIGGERING
INETER collects data from 32 stations of the Nicaraguan seismic network, of which 12 are broadband stations. INETER also includes some short‐period stations from Honduras (5) and El Salvador (6) in the network. Data from all 43 stations are received in real time and processed by EW.
INETER sends data from all their broadband stations to IRIS. Data can then be retrieved from the IRIS SeedLink server, but with some delay, up to several minutes in some cases due to data transmission and delayed delivery from the source.
To test the delayed trigger algorithm in RTQUAKE we configured the system to read data from the IRIS SeedLink server. RTQUAKE was configured with the default parameters for delayed triggering as shown in Figure 2:
Total time window: 20 minutes
Maximum allowed latency: 7 minutes
APW: 2 minutes
In the test period (18 June 2013 to2 July 2013), INETER located 62 events detected by EW (http://webserver2.ineter.gob.ni/geofisica/sis/monitor.html; last accessed March 2014). RTQUAKE detected 58 of the 62 events (see Figure 9). Of the four events not detected, two were remote events in Guatemala and Honduras on the Caribbean side, onein the Pacific west of Nicaragua, and one magnitude 1.8 event in the center of the network. The events missed by RTQUAKE are probably caused by using only 12 of the 43 stations. No events were lost due to the latency caused by reading the data from the IRIS SeedLink server. In addition, RTQUAKE detected 10 real events of which three are in the INETER database (and not processed) and seven were not detected by EW. The test shows that RTQUAKE can handle delays and give similar results as INETER despite using only 12 of the 43 stations used by EW at INETER. Because we experienced time delays from IRIS of several minutes during the test period, some of the triggers would have been lost without the delayed trigger option in RTQUAKE.
RTQUAKE is a simple and stable alternative to EW and SC3. The main advantage of RTQUAKE is the close integration with SEISAN, a simple installation, and setup with free software. RTQUAKE is primarily intended to be used with smaller local networks and could be useful for students who want to work with real‐time seismic data from open stations. The ability to run several instances of RTQUAKE can be useful to tailor thenetwork to different types of events or to improve triggering in a heterogeneous network. However, each instance work independently, and duplication of detections might occur.
The simplicity comes at a cost. RTQUAKE can only work with SeedLink so the user must either tap into existing SeedLink servers (which many manufactures now provide for their recorders) or install the SeedLink server locally. In terms of detections, RTQUAKE seems to have detected all important events in the cases for which a comparison was made despite that no attempt was made to refine the RTQUAKE trigger parameters for each case. However, both SC3 and EW might not have been set up with optimal parameters. From our tests it seems that RTQUAKE triggers similarly to EW and better on local and smaller events than does SC3, which might be due to the parameter setting for SC3. On the other hand, it is possible to make RTQUAKE more sensitive by lowering the detection criteria at a cost of getting more false triggers. Optimal configuration of a system is probably the most important step to get the best event detection and more so for a complicated system. RTQUAKE also detected many distant events with the parameters used; however, we did not compare it with the other systems because the main purpose was to test RTQUAKE for local and regional events. RTQUAKE lacks the sophistication in automatic processing available for EW and SC3, whereasthe graphical network monitoring seems adequate.
Lars Ottemöller read the paper and gave valuable suggestions. Mohammad Raeesi helped with Generic Mapping Tool. Steve Malone gave very valuable feedback and suggestions.