Electronic Supplement to
Seismic Event Recognition in the Trentino Area (Italy): Performance Analysis of a New Semiautomatic System

by M. Garbin and E. Priolo

We developed a semi-automatic procedure to recognize all seismic events occurring in the Trentino region - NE Italy. We are especially interested in recognizing the weakest events, in order to gain a better understanding of the seismotectonic patterns of the area. This new procedure - which uses BRTT Antelope^® software - operates off-line and strongly exploits the capabilities of the North-Eastern Italy integrated network managed by the OGS (NEISN). The results obtained after one year of testing (2010) are definitely appreciable with the total number of recognized seismic events increased by a factor of about 2.8 and the average completeness magnitude decreased (i.e. improved) from M_L ≅ 1.3 to M_L ≅ 1.0.

This electronic supplement contains two sections. The first details the tuning of the two main Antelope^® algorithms used for event recognition and location, i.e., dbdetect and dbgrassoc, respectively. The second provides a brief account of the location errors obtained for the one year testing period using the new recognition procedure.

---

1. The Off-Line System for Seismic Event Recognition

All the metadata concerning the seismic network are collected in individual and - usually - static dbmaster tables (dbmaster is the Antelope^® database which manages all the network information, e.g. sites, instrumentation, channels, etc.), whereas all the tables relevant to waveform file indexing and processing are created and kept in monthly and self-consistent directories. The main engines of this automatic processing step are two programs: dbdetect and dbgrassoc. The first program applies an STA/LTA algorithm on the continuous data stream, selects candidates for phase arrival time, and enters them into the detection table. The second program reads the detection table and, according to a pre-calculated travel-time table between stations and nodes of a regular 3D grid, creates groups of detections that match a candidate origin time with a certain pre-defined tolerance (i.e., associates groups of detections to candidate events), and eventually sifts out events from the list of candidates, first on the basis of the number of stations involved and then on the basis of the standard deviation of the residuals. Note that the detection module (dbdetect in Antelope^®) recognizes only signal variations (i.e. triggers) which could potentially be due to seismic events, but which are often due to noise instead. It is only through a trial-and-error procedure where groups of triggers are associated to trial locations (module dbgrassoc), that possible seismic events can be recognized. Figure S1 shows the flow diagram of the off-line processing adopted for the seismic event recognition which will be described below.

▲Figure S1. Flow diagram of the off-line processing adopted for the seismic event recognition. Details are in text.

Two main tests were run in order to calibrate the detection and association algorithms. In the first, dbdetect was tuned to identify the wider number of triggers pertaining to seismic events on a per channel basis, and to try to distinguish between local and non-local arrivals as well as P- and S-phase candidates, respectively. The second test concerned the detections identified during the previous step and focused on dbgrassoc, with the aim of recognizing the largest possible number of events as well as distinguishing between well-located local events and non-local events (i.e. outside area A), for which accurate location was not a priority.
Successful event detection: this requires that dbdetect be tuned correctly, which basically means finding the correct trade-off between leaving the algorithm free enough to trigger at any possible event on one hand, and avoiding false events, i.e. triggers due to signal noise, on the other. The actual event recognition task is assigned to dbgrassoc. The dbdetect configuration was tuned according to the following procedure: 1) for testing purposes, we chose a 10-day target window of signals for which all existing seismic events had been already recognized accurately; 2) once the configuration was optimized for that window, we ran the same procedure on a number of different time windows in order to verify its validity. Any problematic or unsatisfactory result (e.g.: missed events, wrong associations, too many false events) was used to tune a finer configuration, and entered in the test for further verification.
Some details about the configuration parameters are specified below. In order to distinguish between the different kinds of arrival, the parameter file that drives dbdetect has 4 different configurations: three of them work on vertical channels with the goal of discriminating between local, regional and teleseismic P-arrivals (named  PL, PR, and PT, respectively); the fourth one works on horizontal channels with the goal of identifying S-arrivals (named S). Each of these parameter files produces one or more detection tags, which are read and used in different ways by dbgrassoc during the subsequent location step. Table S1 summarizes the setting of the four configurations and their differences.

	PL (P-local)	PR (P-regional)	PT (P-tele)	S (S-local/regional)
sta_twin	0.5	1.0	6.0	3.0
lta_twin	12.0	40.0	80.0	50.0
nodet_twin	2.0	5.0	10.0	2.0
thresh	3.0 (TN: 2.5)	3.0	2.5	3.0
threshoff	2.5 (TN: 1.5)	2.5	2.0	2.5
det_tmin	5.0	10.0	20.0	2.0
det_tmax	10.0	200.0	600.0	10.0
filter	BW 15.0 4 25.0 4	BW 5.0 4 12.0 4	BW 0.5 4 2.0 4	BW 1.0 4 5.0 4
iphase	lp	rU	Tl	sA
filter	-	-	BW 0.8 4 3.0 4	-
iphase	-	-	Th	-
sta	.*	.*	.*	.*
chan	[EHS]HZ	[BEHS]HZ	[BH]HZ	[BEHS]H[NE]

▲Table S1. The settings of the most significant parameters for dbdetect module. PL, PR, PT, and S define different detection configurations (see also text).

The latter concern the filter applied to the signals before the main processing procedure, the parameters of the STA/LTA algorithm and the channels/stations involved. For instance, local P-phase recognition works on high sampled data streams of both short period and broadband seismometers band-pass pre-filtered between 15.0 and 25.0 Hz. The threshold values of signal to noise ratio are set at 3.0 and 2.5 to define a detection as ON or OFF, respectively. These values are lowered for PAT stations to 2.5 (ON) and 1.5 (OFF) respectively, in order to maximize sensitivity towards local events. The length of the short time window is set at 0.5 s to accommodate several cycles of the lowest frequency allowed. If detection remains ON for less than 2 s, it is removed (nodet_twin). If it exceeds 2 s, it is kept on for at least 5 s (det_tmin). The process_twin parameter refers to the length of hunks into which waveform data are broken, prior to processing. Lowering the value of this parameter simulates the processing of data packets acquired in real-time, and results in a generally higher number of detections, thus increasing processing time considerably. Moreover, given the high sensitivity required, a lot of detections correspond to noise fluctuations. For this reason, the process_twin parameter was reasonably set at 60 s.

Once dbdetect has produced a satisfactory detection table, the next step is to configure dbgrassoc. The location algorithm works on the detection table and on a configurable number of tables containing the source-receiver travel-time, pre-calculated for each station-node couple, where nodes sample the volume according to a regular grid. To accomplish this task, we used the IASPEI91 velocity model, included by default in Antelope^® package. The goal of the dbgrassoc configuration was to distinguish between local and non-local events, with the latter including both regional and teleseismic events. Three different grids and corresponding travel-time tables were built, namely local, regional and tele, hierarchically included into each other, though with different grid spacing parameters. Event recognition proceeds on each grid simultaneously, finding the best location, if any. In order to solve conflicts which may arise when different solutions are found for different grids, a priority scheme is applied, whereby solutions located within broader and coarser grids that fall within the boundaries of smaller and finer grids are rejected.

Below are some details of how dbgrassoc functions and of the type of configuration that was adopted. First, a pick list is drawn up from the detection table according to the maximum phase move-out expected for an event located at the margin of the station network (process_time_window = 200 s). The pick list is then updated each time a new detection is imported from the table (process_ncycle = 1). Different subsets of detections included in the pick list are defined for each grid in order to search it for possible solutions. For instance, possible solutions for the local grid are created by using only detections tagged by dbdetect with lp or sA (parameter phase_sifter), where lp or sA identify possible P-phases and S-phases, detected respectively on vertical and horizontal channels (parameters P_channel_sifter and S_channel_sifter). Given a specific node to be evaluated as a possible epicenter, a reduced pick list is created using travel-time tables from the original pick list, which accounts for origin times corresponding to the picked stations. These origin times are close to each other if the specific node actually represents an epicenter for those picks/stations. Admissible spacing between origin times (cluster_twin) depends on uncertainty in automatic picks, velocity model and location grid. For example, cluster_twin was set at 1.5 s for the local grid. Another important parameter is the minimum number of stations to be used depending on the distance from the epicenter (nsta_tresh). It is kept low at local distance to increase sensitivity, while it is increased with distance to decrease the amount of false events. The following configuration proved to be satisfactory: minimum number of 3 stations within a radius of d ≤ 50 km, 4 stations for d ≤ 90 km, and 5 stations for d ≤ 120 km. For regional and tele grids the pattern is simpler, since only a minimum number of P-phases need to be included in cluster_twin, regardless of the distance. Therefore, the minimum number of stations and cluster_twin were set respectively at 4 and 1.5 s for the regional grid, and 6 and 2.0 s for the tele grid.

Event recognition relies on P-phase detection for all grids. S-phases are used with local and regional grids as well, although with some expedient. Noisy stations (e.g.: BALD) are explicitly down-weighted. Moreover, given the irregular station distribution over the regional grid, picks from station clusters with station-to-station distance inferior to 40 km are down-weighted (sta_weight_radius = 0.35 degrees) by the inverse of the number of elements (stations) in the cluster.

Once the seismic events have been identified, dbampmag computes the local magnitude. The attenuation-with-distance relation of Bragato and Tento (2005) was used in this case, while no station-specific correction was applied.

The last step of the automatic part of the procedure extracts waveforms on a “per event” basis and stores them in the Department server, called PickServer, which is used by seismologists for manual processing. Extracted waveforms include the stations associated by the dbgrassoc program, as well as all stations within a range of 40 km from the epicenters.

After the first 10-day testing period, the reliability of the final configuration was further verified for a longer period (4 months) by comparing the seismic events recognized automatically by means of the new procedure and those recognized manually by the PAT operator. At this stage, some further tuning steps were still needed in order to capture the few events that were still missing. The procedure was then applied to the entire 2010 dataset, with further reverse check and negligible adjustments. At this point, the procedure can be considered as having been fully developed and validated.

Though the need for manual validation of the automatically-generated results is crucial in order to remove inevitable false events, Antelope^® has proved to be very effective in recognizing micro-seismic events. However, the tuning of the main functions needed for this purpose (i.e., dbdetect and dbgrassoc) has been far from straightforward. The scope and precise meaning of the parameters involved was often obscure, and we had to perform a huge number of trial-and-error tests - a very frustrating experience - to set the parameters so as to obtain the intended results.

2. Location Errors

Location errors are adequately low (Figure S2). About 94% of the 717 localized events features maximum horizontal standard error (ε_max) below 2 km. This percentage decreases to about 65% if depth error (ε_z) is included. Nevertheless, if the weak events with unconstrained depth (~19%, mainly due to mining activity) are excluded, the percentage of events with maximum error below 2 km increases to about 81% (Figure S3).

▲Figure S2. Distribution of standard location errors resulting from the error ellipsoid projection on the surface of the Earth (project_ellipse module from Antelope^® contrib). Events not constrained in depth are not represented.ε_max, ε_min: major and minor horizontal errors, respectively; ε_z: vertical error.

▲Figure S3. Cumulative number of events as a function of location standard error. Events not constrained in depth (~19% of the whole dataset) are not represented. The blue and red lines represent major horizontal error (ε_max) and maximum error, respectively.

[ Back ]