PRESTo User Manual

▲

Summary

▲

• What is PRESTo?
• About Us
• Acknowledgements
• Copyright Notice
• Technology
• Running PRESTo
• Configuring PRESTo
• Detailed Description of PRESTo
• PRESTo ChangeLog
• References

What is PRESTo?

▲

PRESTo is a free and open source software platform for Earthquake Early Warning (EEW) that integrates recent algorithms for real-time, rapid earthquake location, magnitude estimation and damage assessment, into an easily configurable and portable package. It is under active experimentation in Southern Italy on the Irpinia Seismic Network (ISNet) (Satriano, Elia et al. [35]), and in several other local and national seismic networks worldwide.

The software is mainly targeted at: managers of seismic networks, civil protections, owners of seismic sensors, companies providing seismic sensors and data-loggers and scientists in the field of seismology and earthquake engineering who are interested in characterizing within seconds (if supported by an adequate network infrastructure) the damaging potential of an occurring earthquake, with the possibility to provide personalized alarm messages to any number of end-users.

PRESTo in fact continually processes the real-time streams of ground motion recorded by the seismic stations (e.g. three-component acceleration or velocity data) for P-waves arrival detection. These data are normally streamed in real-time from the stations using a SeisComP server via the SeedLink protocol, but they can also be read from files (in SAC format), in order to provide a simulation mode whereby waveforms of past events can be played back into the system. While a (real or simulated) event is occurring, the software promptly performs event detection and provides location and magnitude estimates as well as shaking predictions at target sites.

The earthquake location is obtained by an evolutionary, real-time probabilistic approach based on an equal differential time formulation. At each time step, the algorithm uses information from both triggered and not-yet-triggered stations. Magnitude estimation exploits empirical relationships that correlate this parameter to the filtered peak displacement (Pd) measured over the first 2-4 s of P- and S-waves signal. Finally, peak ground-motion parameters at remote sites can be estimated through ground motion prediction equations once location and magnitude are available.

Alarm messages containing the evolutionary estimates of source and target parameters, sent over the internet, can thus reach vulnerable infrastructures at a distance before the destructive waves, enabling the initiation of automatic safety procedures.

This manual provides an end-user guide to the deployment of PRESTo in a seismic network and to its configuration, as well as a description of the algorithms currently implemented, which are summarized in Table 1.

Table 1 – Algorithms implemented in the current version of PRESTo. The system is under active testing and development, so this is subject to change as new versions are made available

Algorithm	Description
Picking	FilterPicker: designed so that it operates stably on continuous, real-time, broad-band signals, avoids excessive picking during large events. (Lomax A., [25])
Location	RTLoc: evolutionary location technique based on an equal differential time (EDT) formulation and a probabilistic approach. Both triggered and not-yet-triggered stations are used at each time step. (Satriano et al., [37])
Magnitude	RTMag: magnitude estimation based on short windows of signal (e.g. 2/4 seconds), following the automatically picked P-waves arrival and predicted S-waves arrival. (Lancieri et al., [24])
Ground Shaking	GMPE: suitable Ground Motion Prediction Equations can be specified by the end user, as formulas in text files. They are evaluated at run-time for estimating the peak acceleration and peak velocity at target sites, based on magnitude and location. (e.g. Akkar and Bommer, [1])

About Us

▲

RISSC-Lab is a laboratory comprised of researchers from the Department of Physics of the University "Federico II" of Naples (Italy), and AMRA s.c.a.r.l. RISSC-Lab is coordinated by Aldo Zollo, full professor of Seismology.

RISSC-Lab carries out research and technological development activities in theoretical and experimental seismology, and is financed through national and international scientific projects.
AMRA s.c.a.r.l., Center of Competence in the field of Analysis and Monitoring of Environmental Risk, is a permanent research enterprise devoted to developing innovative methodologies to approach environmental problems.

• PRESTo [35] code and design by Luca Elia.
• FilterPicker [25] code by Anthony Lomax.
• RTLoc [37] code by Claudio Satriano and Anthony Lomax.
• RTMag [24] algorithm by Maria Lancieri.
• Early Warning Team at RISSC-Lab: Aldo Zollo, Luca Elia, Claudio Martino, Simona Colombelli, Gaetano Festa, Antonio Emolo, Matteo Picozzi. PhD students: Piero Brondi, Alessandro Caruso.

Acknowledgements

▲

The research work behind PRESTo has been supported by the Italian DPC-S5 project. Part of the work has been carried out within the SAFER project (Seismic Early Warning for Europe), founded by the European Community via the Sixth Framework Program for Research. Current development support is provided by Early Warning related Work Packages of these projects: NERA (Network of European Research Infrastructures for Earthquake Risk Assessment and Mitigation, 2010-2014) and REAKT (Strategies and Tools for Real-Time Earthquake Risk Reduction, 2011-2014). Further development specifically aimed at applications to nation-wide networks has been funded by KIGAM (Korean Institute of Geoscience and Mineral Resources).

Copyright Notice

▲

PRESTo EWS is free software. Program and source code are distributed under the terms of the GNU General Public License, version 2 (GPLv2).

PLEASE READ, UNDERSTAND AND AGREE WITH THE GNU GPL BEFORE DOWNLOADING OR USING THE PRESTo SOFTWARE: GNU General Public License, version 2

Technology

▲

PRESTo is written in C++, a programming language that provides optimal speed performance (a key element for an early warning system) without sacrificing the code expressiveness, thanks to its object-oriented nature. The code is easily portable to different operating systems, thanks to the SDL library (Simple DirectMedia Layer), used for abstracting low-level operations, and the OpenGL libraries, a de facto standard for scientific and interactive visualization. Executables are currently available for Windows, Linux (Ubuntu) and Mac OS X. The software is organized into a main thread that implements the core processing procedures activated during an event, and some additional processing threads that handle the continuous tasks, such as waveforms acquisition, using the SeedLink protocol, and their processing.

Running PRESTo

▲

The root directory (e.g. C:\PRESTo) contains the executable (PRESTo.exe) as well as a few directories, such as data (for user provided data) and config (for user provided parameters). The following chapters discuss how to configure the software. To run the program open a command prompt and use the following syntax:

      C:\PRESTo> PRESTo.exe network-name [earthquake-name]

Network-name is the name of the network, the description of which must be found in a data\network-name directory. Earthquake-name is the optional earthquake to be simulated, using SAC files from directory data\network-name\earthquake-name.

Simulation Mode

When an earthquake name is provided as second parameter, e.g.:

      C:\PRESTo> PRESTo.exe ISNet example

PRESTo will run in simulation mode, and will perform the playback of all the SAC files it finds in data\network-name\earthquake-name (data\ISNet\example in this case). It will open up a graphical window like the one below:

A log file named data\network-name\earthquake-name\earthquake-name.log will be written. SAC files in the earthquake directory must have ".sac" (or ".SAC") extension. The station name is read from the header (KSTNM). The component is assigned according to the last letter of the component name in the header (KCMPNM), if it is either "Z", "N" or "E". Otherwise the component name is guessed from the filename (i.e. ".Z.", ".U.", ".UD.", ".0." in the filename means vertical; ".N.", ".NS.", ".1." means North-South; and ".E.", ".EW.", ".2." means East-West). Make sure there is only one file per component per station, or PRESTo will complain about duplicate component.

Real-time mode

If no earthquake-name parameter is provided, for instance:

      C:\PRESTo> PRESTo.exe ISNet

PRESTo will run in real-time mode, streaming ground motion data from the internet via the SeedLink protocol, using the stations specified in the network description. It will open up a graphical window and start a log file in data\network-name\date_time_realtime.log, where date_time is the timestamp at which the program was started.

User interaction

Click on an element in the window (waveforms, map, magnitude graph) to zoom it in/out. Click on the "m/sⁿ" button to toggle the seismogram units between counts and acceleration (or velocity). In playback mode only, click on "Pause" to pause the simulated time, or on "Restart" to restart the simulation. In addition the following keys can be used:

Key	Description
Shift-ESC	Terminate the program (same as closing the window)
P	Playback only: toggle pause (same as pressing the on-screen button). Shift-P (or Ctrl-P) will advance simulated time in half second steps
R	Playback only: restart simulation
F1	Toggle display of: percent of frame time spent to draw the screen, frames-per-second (should be ~30), window size. Useful to check if the graphics card and CPU performance are adequate
F2 / Print Scr.	Save a screen shot in PNG format (filename: screenshot_<num>.png where <num> is a progressive number). This is saved in the network directory in real-time mode or in the earthquake directory if in playback mode
F10	Screen refresh and event declaration/processing run at 30 Hz by default. This key toggles the speed limit on/off (Note: CPU and GPU usage will max-out if not limited!)

Outputs

A detailed log of the inner workings of PRESTo is saved in the network directory (or the earthquake directory in simulation mode).

Additionally, at the end of any processed earthquake (either real-time detected or simulated), a few summary files are saved: a screenshot, a KML animation (viewable with Google Earth, for instance), an excerpt of the log pertaining only to the earthquake, further stripped-down to be less verbose and suitable to be attached to an e-mail. The logs can be easily parsed with something like AWK. Under Windows the best option to obtain AWK is probably to install Cygwin.

In simulation mode it is also optionally possible to save a screenshot every second in order to assemble a video of the whole simulation. Using an external image manipulation tool, for instance convert (part of ImageMagick), the animation can be produced giving the following command from within the earthquake directory: convert -delay 100 movie_*.png movie.gif.
The suggested output format is GIF, as it retains much of the original detail, and can be shown in any web browser.

For added flexibility, users can provide a procedure (e.g. a batch file under Windows, a shell script under Linux/Mac/Cygwin) that will be launched just as PRESTo is done processing any event, in real-time mode only, in order to perform additional custom actions per earthquake. The user provided executable must be placed in eventpostproc\eventpostproc.bat (eventpostproc.sh under Linux/Mac) and is passed as first parameter the "handle" of the event (i.e. data\network-name\<origin_time>_<quake_ID>). The handle can be transformed in the path of the log for this earthquake by appending ".mail.log" or to that of the full log by appending ".log" (likewise: ".kml" for the KML animation, and ".png" for the screenshot). The eventpostproc procedure can then parse the logs to extract useful data, such as the last estimates of source parameters, and to perform some further actions such as sending an e-mail and SMS, or to insert the source parameters in a bulletin/database.

In real-time mode health state messages and alarms can be sent over the internet to end-users. Health state messages are just very short "heart-beat" message sent regularly to inform the receiving end that PRESTo is up and running, while alarm messages can be of two kinds:

• One alarm message takes the form of short UDP packets sent directly from PRESTo to each target IP address specified in targets.txt. Each message contains the source parameters of the ongoing earthquake, but is target specific since it also provides the peak ground motion and remaining seconds to the S-waves arrival at the site, estimated by PRESTo.
• An additional broadcast alarm message (in QuakeML format) can also be optionally generated, focusing on the earthquake source parameters (magnitude, location) instead of the target-specific information (ground shaking). This message is sent via TCP to a server for the dissemination of alarms to a broader public, instead of being sent directly to each target by PRESTo itself. The server acts as a "broker", relaying the messages to any number of subscribed clients, such as end-users who have installed and configured an Early Warning Display at their own facility. The ground shaking and lead-time estimation at the end-user site is in this case delegated to the receiving software.

Configuring PRESTo

▲

PRESTo is configured through a series of text files. In these files, lines starting with a ‘#’ character are treated as comments (ignored). Moreover, whenever a true/false value is expected, 0 must be used for false and 1 (or any non-zero number) for true. In general you may want to use the supplied template configuration files as a starting point. They contain the format of the data to enter as a comment at the top of the file and possibly a few example items.

Window/Sound configuration in config\config.txt

This file contains a few parameters that affect just some user-facing aspects of PRESTo, not its Early Warning processing. You’ll rarely need to change it.

Graphics / Sound	Default	Description
screen_w, screen_h	0, 0	PRESTo window width and height in pixels. The window must have a 4:3 aspect ratio (i.e. width/height = 1.33333). Use 0 for automatic window size (90% of the desktop)
fullscreen	0 (false)	Enable full-screen mode
vsync	0 (false)	Enable vertical syncing in full-screen mode (smoother graphics, but may adversely affect performance)
sound	0 (false)	Enable sound during an earthquake (siren, earthquake shaking at the target)

Network description in data\network-name

This directory must contain the description of the network and the parameters that depend on network topology and geographic region. The term network here is used loosely, as in general for large networks you may want to create one such directory for each geographic region in the epicentral zone of an earthquake you are going to simulate. This network information must be supplied by the user through the following files:

File Name	Description
time\ (directory)	P- and S-waves travel-time grids used for estimating earthquake location and arrival times at targets. These are binary files that must be generated with the NonLinLoc software and copied here. Note: only full 3D grids are supported, even if using a 1D velocity model (as is commonly the case)
rtloc.txt	List of travel-times grids to load, one grid per line: STA station-name The list must include all stations as well as targets to use. Each entry loads the corresponding travel-times grids from time directory. This file also contains, at the bottom, a few parameters controlling the earthquake location algorithm (RTLoc, see details)
stations.txt	List of the stations to use and their descriptions. Each line contains (separated by spaces): station name, sensor type (ACC or VEL), clipping threshold (counts), data-logger constant (V/count), sensor constant (e.g. V ⋅ s2/m), SeedLink IP or hostname, SeedLink network code, SeedLink channels (e.g. HNZ HNN HNE, or 01HNZ if using 01 as location code) If using velocimeters, they should be broad-band instruments, capable of faithfully recording the low frequencies of moderate-to-large earthquakes. Clipping should be configured depending on the data-logger sensibility (e.g. ~7e6 counts for 24-bit data loggers = 80% of (2^24)/2). Note: only stations listed in rtloc.txt too are allowed here (i.e. whose grid has been loaded).
seedlink.txt	List of stations to stream data from via SeedLink, one per line: station-name Only read in real-time mode. This file is mainly useful to limit the real-time data streaming to a subset of all the stations for whatever reason (bandwidth, data quality or sensor type considerations)
targets.txt	List of target sites to send alarms to (see details), one per line. Each line contains (separated by spaces): "full name", travel-times grid name, show on map (1=true, 0=false), IP or hostname for alarm delivery (0.0.0.0 to disable), UDP port The first target in the list is supposed to be the most prominent, i.e. it will be highlighted in yellow/red on the map during an earthquake
broker.txt	Server for the dissemination of broadcast alarms (see details). One line containing (separated by spaces): IP or hostname (0.0.0.0 to disable), TCP port, "destination" (e.g. /topic/presto), "username", "password"
rtmag.txt	Regression law coefficients and time windows used for magnitude estimation (RTMag, see details). The exact regression law used can be found in the logs, and has the form: M = (log10(Pd) – A – C ⋅ log10⁡(R/10))/B where Pd is the peak displacement (m) in the time window and R is the hypocentral distance in km. Each line contains (separated by spaces): time window (e.g. 2P for P-waves, 2 seconds), components to use (e.g Z or ZNE for all), A,dA, B,dB, C,dC, Standard error, saturation magnitude At this time it is not possible for users to specify a different equation, just different coefficients. The Gutenberg-Ricther law is used as a-priori information on magnitude, its β coefficient is specified as: GR <beta>
pga.txt, pgv.txt	Formulas to estimate the peak ground motion at targets (PGA, PGV). See details. Each file contains two formulas separated by a newline. The first estimates the logarithm of the peak ground motion at the target (cm/s for pga.txt, cm/s2 for pgv.txt); the second the logarithm of its uncertainty. The formulas will use the PRESTo estimates as inputs: earthquake magnitude (Mag), epicentral distance (R_epi) and depth (Dep). log10_pgx(Mag, R_epi, Dep) err_log10_pgx(Mag, R_epi, Dep) The formulas can contain C language conditions of the form: (Mag > 4) ? <formula_high_mag> : <formula_low_mag> to use different laws according to magnitude (or some other input parameter)
map.png	An image of the area covered by the chosen location grid, in PNG format, used to draw the map. The exact longitude and latitude ranges needed are provided in the top part of the logs, along with a Google Maps link. Easiest option: open the Google link in a browser; save the image as "map.png" in the network directory; crop the region outside the black rectangle with an image manipulation program
quake_id.txt	Only read in real-time mode, it contains just an integer number: the earthquake ID (progressive number) to be associated to the next earthquake. In simulation mode the starting ID is always 0

Early Warning parameters in config\params.txt

This single file collects all the parameters affecting the various Early Warning algorithms: P-waves picking, event declaration (binding), earthquake location, magnitude estimation, alarms to remote targets. You’ll also find a few non-critical parameters here, which just affect the way information is displayed on screen. In addition it is possible to activate some debugging features of PRESTo, which are usually best left to simulations only (in some cases they are disabled automatically in real-time mode). The general idea is for parameters in these files to be somewhat independent of the seismic network being used, with network specific parameters being specified in the network directory files. On the other hand some parameters, such as those controlling the event declaration (picks binding) do actually need to be tweaked on a per-network basis do account for the topology of the stations, so bear that in mind. This is a list of all the currently supported parameters grouped by area of influence:

Simulation / Debugging	Default	Description
simulation_speed	1.0	Simulation speed-up factor compared to real time (e.g. 0.5 is half speed, 2.0 is twice as fast)
simulation_write_displacement	0 (false)	For debugging: write the computed displacement waveforms in .sg2 format (SeisGram2K, textual), for all time windows used to find a peak displacement
simulation_movie_period	0.0	If non-zero, save a screenshot every this many seconds (file name: movie_NUM.png where NUM is a progressive number). The screenshots can later be joined together to obtain an animation (using external tools). Warning: generates large files continuously, keep the running times short!
simulation_lag_mean, simulation_lag_sigma	0.0, 0.0	If non-zero simulates random data transmission lags with this Gaussian mean and sigma (seconds)

Debugging	Default	Description
debug_gaps_period	0.0	Insert gaps in the waveforms (holes in the data streams) every this many seconds, for debugging. Use 0 to disable
debug_gaps_duration	0.0	Duration of the gaps (seconds). Use 0 to disable
debug_save_rtloc	0 (false)	Save the location probability density grid for each location estimate (simulation mode only). Warning: generates many large files per earthquake!
debug_save_rtmag	0 (false)	Save the probability distribution of magnitude of every time window and station, for each magnitude estimate

Display	Default	Description
display_heli_min_accel	0.01	Minimum full-scale acceleration (m/s2) to use in the auto-scale of on-screen accelerometric helicorders (i.e. high values will shrink noise to a flat line)
display_heli_min_vel	0.001	Minimum full-scale velocity (m/s) to use in the auto-scale of on-screen velocimetric helicorders (i.e. high values will shrink noise to a flat line)
display_heli_secs	60.0	On-screen helicorder duration (seconds)
display_heli_width	0.55	On-screen helicorder horizontal width (0.0-1.0 with 0.5 = half screen width). The remaining screen area is used for the map
display_heli_max_num	100	Maximum number of helicorders to show on-screen (N). Only the first N stations in seedlink.txt or the first N stations found in SAC files will be displayed. Useful when a large number of stations are used. Note that all stations will be used for Early Warning, regardless of this parameter
display_heli_lag_threshold	10.0	When |Timenow-Timelast_sample| is above this many seconds a station is declared lagging, i.e. yellow helicorder, ghosted out on the map. Note that this includes stations with timestamps in the future (GPS problems)
display_map_fixed_size	1 (true)	The on-screen map auto-zooms to include stations, targets and epicenters. 1 = Keep the aspect ratio of the map fixed (that of the location grid area); 0 = change aspect ratio depending on the elements to display
display_map_station_scale	1.0	Scale factor to adjust the default size of station icons on the map (as well as targets, quakes etc.). Useful for very dense or very sparse networks
display_real_quake	1 (true)	When simulating an earthquake, show on the map its real location (i.e. from a bulletin). This is read from a text-file in the earthquake directory, if present: <earthquake-name>_real.txt, containing: Latitude(°) Longitude(°) Depth(km) Magnitude
display_heli_show_mag	1 (true)	Show on each helicorder the magnitudes measured on each time window

Data Transmission [Seedlink]	Default	Description
slink_timeout_secs	60	The SeedLink connection will be closed and re-opened after this many seconds with no data received
slink_delay_secs	10	Wait this many seconds to re-open the connection after the above timeout
slink_keepalive_secs	0.0	Send keep-alive packets every this many seconds
slink_log_verbosity	0	Verbosity level of the SeedLink log (filename: same as the main PRESTo log, but with ".err" extension instead of ".log"). 0=Normal, 1=Diagnostic messages too, 2+=Error messages too
latency_log_period_secs	600	Write in the main log the data latency statistics (min./avg./max. since the last measurement) for each data stream every this many seconds (0 to disable)

Waveform Preprocessing	Default	Description
waveform_rmean_secs	30	After picking, remove from each 1-second of waveform the signal mean computed on this many previous seconds. The resulting waveform is the one displayed and used to measure peak displacements. Use 0 to disable
waveform_clipping_secs	0	If clipping is detected in a waveform, discard it for this many seconds (0 to disable). Clipping is declared when a sample has an absolute value, in counts, higher than the clipping threshold declared in stations.txt
waveform_min_snr	5	Minimum Signal-to-Noise Ratio (i.e. the ratio of the RMS measured after the phase arrival and the RMS measured before) to use a waveform for magnitude estimation (0 to disable).

FilterPicker [Picker]	Default	Description
picker_filterWindow	4.0	How far back in seconds the previous samples are examined. The filter window will be adjusted upwards to be an integer N power of 2 times the sample interval (deltaTime). Then numRecursive = N + 1 "filter bands" are created. For each filter band n = 0,N the data samples are processed through a simple recursive filter backwards from the current sample, and picking statistics and characteristic function are generated. Picks are generated based on the maximum of the characteristic function values over all filter bands relative to the threshold values threshold1 and threshold2
picker_longTermWindow	10.0	Long term window in seconds. It determines: a stabilization delay time after the beginning of data; before this delay time picks will not be generated. The decay constant of a simple recursive filter to accumulate/smooth all picking statistics and characteristic functions for all filter bands
picker_threshold1	8.0	Threshold to trigger a pick event (potential pick). This threshold is reached when the (clipped) characteristic function for any filter band exceeds threshold1
picker_threshold2	8.0	Threshold to declare a pick (pick will be accepted when tUpEvent reached). This threshold is reached when the integral of the (clipped) characteristic function for any filter band over the window tUpEvent exceeds threshold2 * tUpEvent, i.e. the average (clipped) characteristic function over tUpEvent is greater than threshold2
picker_tUpEvent	0.2	Maximum time the integral of the (clipped) characteristic function is accumulated after threshold1 is reached (pick event triggered) to check for this integral exceeding threshold2 * tUpEvent (pick declared)

Event Declaration [Binder]	Default	Description
binder_stations_ for_coincidence	3	Minimum number of triggered stations in the coincidence time window to declare an event. This and the following parameters need to be tailored for the network topology (i.e. average inter-station distance, network size, seismogenic zone distance etc.)
binder_secs_ for_coincidence	2.0	Duration of the coincidence time window (seconds)
binder_secs_ for_association	15.0	Duration of the association window (seconds): all picks after an event will be associated to the event if their time lies within this many seconds from the first associated pick
binder_quakes_separation	30.0	How many seconds should pass from the first pick of the previous event and the first pick of a new possible event. Below this threshold no new events are declared
binder_quakes_life	40.0	For how many seconds should the earthquake parameters be refined. After this many seconds the earthquake is no longer processed and source parameters estimates are considered "final"
binder_apparent_vel_min, binder_apparent_vel_max	3.85, 20	Picks coincidence and association require the apparent velocities of the picks (measured from the first, earlier pick) to fall within this range of velocities (km/s), i.e. a range compatible with the propagation of P-waves. The lower bound should be higher than the S-waves velocity, the upper bound should be high enough to account for deep / external events (almost simultaneous arrival at distant stations)
binder_apparent_vel_ stations_spacing	30	Average inter-station distance (km). Within this distance to the first pick of a quake, the apparent velocity checks are not enforced (e.g. the apparent velocity can be "infinite" near the epicenter)
binder_apparent_vel_ max_distance	120	Picks more distant than this value (km) from the first pick of an earthquake will not be associated to it

Probabilistic Location [RTLoc]	Default	Description
locate_period	0.5	Re-locate an event at least every this many seconds (even if no new picks have been received)
locate_force_sac	0 (false)	Force earthquake location to that read from the SAC headers (simulation mode only)
locate_force_lon	-12345	Force earthquake longitude (degrees, simulation mode only). Use -12345 to disable
locate_force_lat	-12345	Force earthquake latitude (degrees, simulation mode only). Use -12345 to disable
locate_force_dep	-12345	Force earthquake depth (km, simulation mode only). Use -12345 to disable
locate_use_ non_triggering_stations	1 (true)	Use the information that some stations have not triggered yet at each time step. Can improve the location when less picks are available
locate_ignore_error	0 (false)	Ignore the earthquake location uncertainty, treat it as zero (not shown on screen, does not affect magnitude uncertainty, etc.)

Magnitude Estimation [RTMag]	Default	Description
magnitude_max_value	8.0	Maximum possible magnitude. By clipping the magnitude PDF distribution to this value, we avoid non-null probabilities for unreasonably high magnitudes. Especially when using short time windows to estimate Pd (in the first few seconds), when the PDF above high magnitudes is constant, due to saturation effect of the regression laws
magnitude_outlier_threshold	3.5	When computing the Bayesian magnitude, ignore outliers i.e. values measured by some stations in one of their time windows that diverge greatly from all of the other stations/time windows. Useful to reject very high values from a broken sensor, or very low values from a wrong pick. This parameter is the maximum acceptable modified Z-score (according to Iglewicz and Hoaglin, increases as the sample deviates from the median). Often set at 3.5 (0 to disable)
magnitude_low_fmin	1.0	Minimum frequency (Hz) of the band-pass filter applied after integration (low-magnitude events)
magnitude_low_fmax	25.0	Maximum frequency (Hz) of the band-pass filter applied after integration (low-magnitude events)
magnitude_high_threshold	5.0	Magnitude value above which we define the earthquake "high-magnitude". This is needed to choose the band-pass filter to apply after integration to measure the displacement
magnitude_high_fmin	0.075	Minimum frequency (Hz) of the band-pass filter applied on displacement (high-magnitude events)
magnitude_high_fmax	3.0	Maximum frequency (Hz) of the band-pass filter applied on displacement (high-magnitude events)
magnitude_ secs_before_window	5.0	Magnitude is estimated using the peak displacement over post-arrival time windows. To obtain a more accurate displacement, extend these time windows to this many seconds before the arrival. The peak is still searched on the non-extended windows though
magnitude_p_secs_short	2.0	Duration of the short P-waves time window (seconds)
magnitude_p_secs_long	4.0	Duration of the long P-waves time window (seconds)
magnitude_s_secs	2.0	Duration of the S-waves time window (seconds)
magnitude_ p_can_overlap_s	0 (false)	1 = Do not discard P-waves time windows when they overlaps the S-waves time window

Alarms to Targets [Alarms]	Default	Description
alarm_heartbeat_secs	60.0	Send a heart-beat message to targets (and brokers) every this many seconds
alarm_during_simulation	0 (false)	Send alarm messages even during a simulation (use only for testing!)
alarm_max_period	1.0	After this many seconds have elapsed from the previous alarm, send a new alarm even if source and target parameters did not change

Detailed Description of PRESTo

▲

This chapter should reveal a few more details on the inner working of PRESTo, but it’s otherwise not strictly needed by end-users in order to install, configure and use the system.

Initialization

Upon launch the application reads its configuration from config\config.txt and opens a window. The Early Warning parameters are read from config\params.txt. The description of the seismic network is read from the data\network-name directory. The travel-time grids specified in data\network-name\rtloc.txt are read from the data\network-name\time directory, to be used for the location of earthquakes and the lead-time calculation at targets. In simulation mode the SAC files from the user specified directory, i.e. data\network-name\earthquake-name, are read for play-back and logs are saved in the earthquake directory (i.e. data\network-name\earthquake-name\earthquake-name.log). In real time mode the data streams to the remote stations are opened, the main log is written in data\network-name\date_time_realtime.log while a SeedLink log is written in data\network-name\date_time_realtime.err.
Any error during this phase causes the program to abort after reporting the error in a dialog window.

Data Transmission

Ground acceleration (or velocity) from three components is acquired from the list of stations specified in seedlink.txt (real-time mode), or rather from SAC files in the earthquake directory specified as second parameter (simulation mode). If some of the horizontal components are missing, PRESTo will still work and try to dynamically compensate for that during magnitude estimation by replicating the other horizontal component, if available, or even replacing both of them with the vertical component.
For each channel, a thread running concurrently with the rest of the program performs the following sequence of processing steps, potentially a hundred times a second:

• Checks whether a new waveform packet is available. During real-time operation normally SeedLink packets are received at a constant pace, say one per second, unless the station was lagging behind and is sending more data to recover the delay.
  In simulation mode, data is read from SAC files in one-second packets in the same fashion as SeedLink streams, with the optional possibility of simulating random communication delays and data gaps. In this mode it’s also possible to speed up or slow down the flowing of time compared to real-time.
  When new ground motion data is available this thread:
  • Performs automatic picking with A. Lomax’s FilterPicker algorithm. The procedure is capable of analyzing only the new packet of data, as it retains memory of past computations, rather than having to re-process the whole waveform every time. Only five parameters (specified in params.txt) are needed to tune the algorithm (three of which can be derived from the remaining two if needed).
  • Updates the mean of the most recent packets and removes this mean from the new packet.
  • Adds the new packet to the existing waveform

Early Warning

The main thread, which runs in parallel with the acquisition threads, keeps a list of the last P-waves picks as well as detected earthquakes, in order to perform the Early Warning on more than one earthquake at once. It performs the following steps (30 times per second):

• Processing of P-wave Arrivals (Binding)

1. The list of new, not-yet processed picks is updated (picks are produced by the acquisition threads)
2. Each new pick is confronted with past recent picks:
   
   • The pick is associated to the latest earthquake if it lies in the corresponding association time window (i.e. within a few seconds from the first pick associated to that event) and if it’s from a non-associated station. Additionally the arrival must be consistent with the propagation of P-waves (its apparent velocity must be within bounds)
   • Conversely, if the new pick lies in the coincidence time window of a sufficient number of non-associated picks, a new event is declared. At least a few seconds must have passed from the first pick of the latest event, and picks must satisfy the apparent velocity check as well.
   • Otherwise the pick is stored in the non-associated picks list, and kept for a few minutes.

• Real-Time Earthquake Location (RTLoc)

3. The probabilistic earthquake location of recent earthquakes is updated using the RTLoc algorithm, if either new picks have been associated, or some time has passed. The most probable hypocenter, origin time and covariance matrix (uncertainty ellipsoid) are computed based on the P-waves arrival times at stations and, optionally, non-triggered stations and current time. RTLoc needs two 3D grids per station, holding the travel times from each point of the location grid to the station (one grid for P-waves and one for S-waves).

• Real-Time Earthquake Magnitude Estimation (RTMag)

4. For each station associated to a still occurring earthquake that has been successfully located:
   
   • The theoretical S-waves arrival is computed based on source location and travel times grid.
   • On a time window after the arrival (param: 2 seconds), if available, the peak displacement is measured, yielding a magnitude probability distribution for the station, MS (see below for details).
   • The magnitude distribution for the station over a short time window after the automatically detected P-waves arrival (param: 2 seconds), MP_short, is computed if waveform data is available and, optionally, if the time window does not overlap the S-waves time window above.
   • Similarly, the magnitude distribution for the station over a longer time window after the automatically detected P-waves arrival (param: 4 seconds), MP_long is computed (if data is available and, optionally, there is no overlap with the S-waves time window).
   • The peak displacement id obtained through (double) integration, band pass filter (param: 0.075 – 3 Hz) and finding the maximum modulus of the vector sum of the three components over the time window (configurable to work on some components only).
   • The magnitude probability density function for each time window and station is a Gaussian with mean value M given by:
     M = (log₁₀(Pd) – A – C ⋅ log₁₀(R/10))/B
     where R is the hypocentral distance in km, Pd is the filtered peak displacement in meters and A, B and C are coefficients that depend on the signal window (they are specified in rtmag.txt).
5. The earthquake magnitude probability distribution is obtained by multiplying the MS, MP_short and MP_long distributions for all stations, and with an a priori distribution corresponding to the Gutenberg-Richter law. This provides both a most likely magnitude (peak of the distribution) and uncertainty (magnitude range where the integral of the distribution rises from 5% to 95%).
6. If the resulting magnitude is below a threshold (param: 4), it is re-computed (repeating the two previous steps) using the displacement filter for low-magnitude events (param: 1 - 25 Hz). This makes it possible to test the behavior of the system on low-magnitude events (for networks in low seismicity geographic areas, for instance) while at the same time performing Early Warning for moderate-to-large earthquakes.

• Peak Ground Motion at remote sites (PGA, PGV)

7. Using magnitude and location from the previous steps, the peak acceleration and velocity are estimated at stations (to compare with measured ones) and targets, using the attenuation laws provided in pga.txt, pgv.txt. It is possible to provide different laws depending on the estimated earthquake parameters, for instance to use one law, such as Akkar and Bommer [1], for high magnitude events and another for low magnitude events. The seconds remaining before the estimated S-waves arrival at these remote sites is also computed using the estimated source parameters and the velocity model.

• Alarms sent to remote sites (Targets)

8. Alarm messages are sent over the internet to the remote target sites specified in targets.txt. The messages take the form of short UDP packets that contain, encoded as textual key-value pairs: earthquake parameters and their uncertainties; target-specific estimates such as the peak ground shaking expected at the recipient site, and the remaining seconds before the arrival of destructive waves (S-waves) there. The exact format of the alarms can be found in the logs (e.g. running a simulation with localhost as target IP and with alarm_during_simulation set to 1). Alarms are sent for any occurring earthquake in real-time mode (and optionally during simulations too, for testing) each time the above parameters change of a non-negligible amount (to not flood the receiving end), but anyway never less frequently than once per second (user configurable). The UDP transport layer has been chosen since alarms are short, stream-like (e.g. the most recent message supersedes previous ones) and need to be delivered as fast as possible, i.e. what UDP is best at. In addition to "earthquake" messages, "heart-beat" messages are also continuously sent to targets (e.g. every few seconds) to signal the working condition of the EWS to targets.

• Alarms sent to message servers (Brokers)

9. An additional broadcast alarm message (in QuakeML format) is also optionally provided, focusing on the earthquake source parameters (magnitude, location) instead of the target-specific information (ground shaking). This message is sent via TCP to a server for the dissemination of alarms to a broader public, instead of being sent directly to targets. The server acts as a "broker", relaying the messages to any number of subscribed clients, and it must run a messaging software that supports the STOMP protocol, such as ActiveMQ. The broker.txt file can specify the server IP and login credentials. A typical use of this feature is to alert any number of end-users who have installed and configured an Early Warning Display at their own target site. In this case the receiving software is responsible for providing a shaking prediction at the site of installation, based on the earthquake location and magnitude.

• Final per-event step (Mail etc.)

10. Only in real-time mode, a user provided procedure is launched as a last step after processing an event: PRESTo\eventpostproc\eventpostproc.bat (eventpostproc.sh under Linux/Mac). It may perform custom actions using the final estimates of the earthquake parameters, such as sending e-mails, SMS and inserting the event in a database/bulletin. The procedure is passed a handle to the relevant output files produced by PRESTo, i.e. a filename with path relative to the PRESTo root dir, deprived of the extension part, i.e. data/network-name/YYYY-mm-dd_HH.MM.SS.MS_EqkID where the date is the estimated origin time and the ID is the progressive earthquake ID. The procedure is expected to append the extension it is interested in (currently either ".log", "mail.log", ".kml" or ".png") and use / parse the related file as it sees fit. The example shell script shows how to send an SMS and an e-mail containing the final source parameters and PGA, PGV at targets, a Google Maps link for the epicentral area, with attached PRESTo screenshot.

PRESTo ChangeLog

▲

References

▲

1. Akkar S. and Bommer J.J., "Empirical prediction equations for peak ground velocity derived from strong-motions records from Europe and the Middle East", Bull Seism Soc Am, 97-2 (2007), 511–530, doi: 10.1785/0120060141
2. Allen R.M. and Melgar D., "Earthquake Early Warning: Advances, Scientific Challenges, and Societal Needs", Annu Rev Earth Planet Sci 47 (2019), 361–388, doi: 10.1146/annurev-earth-053018-060457
3. Allen R.M., Baer G., Clinton J., Hamiel Y., Hofstetter R., Pinsky V., Ziv A. and Zollo A., "Earthquake early warning for Israel: Recommended implementation strategy (No. GSI/26/2012)", Ministry of Energy and Water Resources Geological Survey of Israel
4. Allen R.M., Gasparini P., Kamigaichi O. and Böse M., "The Status of Earthquake Early Warning around the World: An Introductory Overview", Seism Res Lett 80 (2009), doi: 10.1785/gssrl.80.5.682
5. Behr Y., Clinton J., Kastli P., Cauzzi C., Racine R. and Meier M.-A., "Anatomy of an Earthquake Early Warning (EEW) Alert: Predicting Time Delays for an End-to-End EEW System", Seism Res Lett 86 (2015), 830–840, doi: 10.1785/0220140179
6. Brondi P., Picozzi M., Emolo A., Zollo A. and Mucciarelli M., "Predicting the macroseismic intensity from early radiated P wave energy for on-site earthquake early warning in Italy", J Geophys Res Solid Earth 120 (2015), 7174–7189, doi: 10.1002/2015JB012367
7. Carranza M., Buforn E. and Zollo A., "Performance of a Network‐Based Earthquake Early Warning System in the Ibero‐Maghrebian Region", Seism Res Lett 88 (2017), 1499–1507, doi: 10.1785/0220170081
8. Caruso A., Colombelli S., Elia L. and Zollo A., "QuakeUp: an advanced platform for the Earthquake Early Warning", EGU General Assembly Conference Abstracts (2018)
9. Caruso A., Colombelli S., Elia L., Picozzi M. and Zollo A., "An on-site alert level early warning system for Italy", J Geophys Res Solid Earth 122 (2017), 2106-2118, doi: 10.1002/2016JB013403
10. Cauzzi C., Behr Y., Clinton J., Kästli P., Elia L. and Zollo A., "An Open‐Source Earthquake Early Warning Display", Seismological Research Letters 87 (2016), 737–742, doi: 10.1785/0220150284
11. Clinton J., Zollo A., Marmureanu A., Zulfikar C. and Parolai S., "State-of-the art and future of earthquake early warning in the European region", Bull Earthq Eng 14 (2016), 2441–2458, doi: 10.1007/s10518-016-9922-7
12. Colombelli S., Carotenuto F., Elia L. and Zollo A., "Design and implementation of a mobile device app for network-based earthquake early warning systems (EEWSs): application to the PRESTo EEWS in southern Italy", Nat Hazards Earth Syst Sci 20 (2020), 921–931, doi: 10.5194/nhess-20-921-2020
13. Colombelli S., Amoroso O., Zollo A. and Kanamori H., "Test of a threshold-based Earthquake Early Warning method using Japanese data", Bull Seism Soc Am 102-3 (2012), 1266-1275, doi: 10.1785/0120110149
14. Cremen G. and Galasso C., "Earthquake early warning: Recent advances and perspectives", Earth-Science Reviews 205 (2020), 103184, doi: 10.1016/j.earscirev.2020.103184
15. Cremen G., Zuccolo E. and Galasso C., "Accuracy and Uncertainty Analysis of Selected Methodological Approaches to Earthquake Early Warning in Europe", Seism Res Lett (2021), doi: 10.1785/0220200414
16. Elia L., Gosar A., Lenhardt W., Mucciarelli M., Pesaresi D., Živčić M. and Zollo A., "Testing the "PRESTo" early warning algorithm with OGS, ARSO and ZAMG seismic data: first results", EGU General Assembly (2014), doi: 10.13140/RG.2.1.1439.3043
17. Emolo A., Caccavale M., Caruso A., Elia L., Park J.-H., Lim I.-S. and Seong Y.-J., "Optimization of PRESTo Early Warning System for South-Eastern Korea", AGU Fall Meeting (2018), doi: 10.1002/essoar.10500062.1
18. Emolo A., Picozzi M., Festa G., Martino C., Colombelli S., Caruso A., Elia L., Zollo A., Brondi P. and Miranda N., "Earthquake early warning feasibility in the Campania region (southern Italy) and demonstration system for public school buildings", Bull Earthquake Eng 14 (2016), 2513–2529, doi: 10.1007/s10518-016-9865-z
19. Fabozzi S., Bilotta E., Picozzi M. and Zollo A., "Feasibility study of a loss-driven earthquake early warning and rapid response systems for tunnels of the Italian high-speed railway network", Soil Dyn Earthq Eng 112 (2018), 232–242, doi: 10.1016/j.soildyn.2018.05.019
20. Festa G., Picozzi M., Caruso A., Colombelli S., Cattaneo M., Chiaraluce L., Elia L., Martino C., Marzorati S., Supino M. and Zollo A., "Performance of Earthquake Early Warning Systems during the 2016–2017 Mw 5–6.5 Central Italy Sequence", Seismo Res Lett 89 (2018), 1–12, doi: 10.1785/0220170150
21. Gasparini P. and Manfredi G., "Development of Earthquake Early Warning Systems in the European Union", Wenzel, F., Zschau, J. (Eds.), Early Warning for Geological Disasters, Advanced Technologies in Earth Sciences. Springer Berlin Heidelberg, Berlin, Heidelberg (2014), pp. 89–101, doi: 10.1007/978-3-642-12233-0_5
22. Kim H.M., Laskowski M., Moghadas S., Sajad A. and Asif M., "A framework for comparing early warning systems across domains: A step toward a data-integrated public health EWS", Proceedings of the 2014 IEEE 15th International Conference on Information Reuse and Integration (IEEE IRI 2014), 80–86, doi: 10.1109/IRI.2014.7051875
23. Lancieri M., Fuenzalida A., Ruiz S. and Madariaga R., "Magnitude Scaling of Early-Warning Parameters for the Mw 7.8 Tocopilla, Chile, Earthquake and Its Aftershocks", Bull Seism Soc Am 101 (2011), 447–463, doi: 10.1785/0120100045
24. Lancieri M. and Zollo A., "Bayesian approach to the real-time estimation of magnitude from the early P and S wave displacement peaks", J Geophys Res 113-B12 (2008), doi: 10.1029/2007JB005386
25. Lomax A., Satriano C. and Vassallo M., "Automatic Picker Developments and Optimization: FilterPicker - a Robust, Broadband Picker for Real-Time Seismic Monitoring and Earthquake Early Warning", Seism Res Lett 83 (2012), 531–540, doi: 10.1785/gssrl.83.3.531
26. Manconi A., Picozzi M., Coviello V., De Santis F. and Elia L., "Real-time detection, location, and characterization of rockslides using broadband regional seismic networks", Geophys. Res. Lett. 43 (2016), 6960–6967, doi: 10.1002/2016GL069572
27. Marmureanu A., Elia L., Martino C., Colombelli S., Zollo A., Cioflan C., Toader V., Marmureanu G. and Craiu G.M., "Earthquake early warning for Romania – most recent improvements", EGU General Assembly (2014)
28. Pazos A., Romeu N., Lozano L., Colom Y., López Mesa M., Goula X., Jara J.A., Cantavella J.V., Zollo A., Hanka W. and Carrilho F., "A Regional Approach for Earthquake Early Warning in South West Iberia: A Feasibility Study", Bull Seism Soc Am 105 (2015), 560–567, doi: 10.1785/0120140101
29. Pesaresi D., Picozzi M., Živčić M., Lenhardt W., Mucciarelli M., Elia L., Zollo A. and Gosar A., "A cross-border regional earthquake early warning system: PRESTo@CE3RN", Nat Hazards 86 (2017), 431–440, doi: 10.1007/s11069-016-2695-0
30. Picozzi M., Zollo A., Brondi P., Colombelli S., Elia L. and Martino C., "Exploring the Feasibility of a Nation-Wide Earthquake Early Warning System in Italy", J Geophys Res (2015), doi: 10.1002/2014JB011669
31. Picozzi M., Elia L., Pesaresi D., Zollo A., Mucciarelli M., Gosar A., Lenhardt W. and Živčić M., "Trans-national earthquake early warning (EEW) in north-eastern Italy, Slovenia and Austria: first experience with PRESTo at the CE3RN network", Adv. Geosci. 40 (2015), 51–61, doi: 10.5194/adgeo-40-51-2015
32. Picozzi M., Emolo A., Martino C., Zollo A., Miranda N., Verderame G., Boxberger T. and the REAKT Working Group, "Earthquake Early Warning System for Schools: A Feasibility Study in Southern Italy", Seism Res Lett 86 (2015), 398–412, doi: 10.1785/0220140194
33. Pinsky V., "Modeling warning times for the Israel’s earthquake early warning system", J Seismol 19 (2015), 121–139, doi: 10.1007/s10950-014-9454-z
34. Nazeri S., Shomali Z.H., Elia L. and Zollo A., "An application of PRobabilistic and Evolutionary early warning SysTem (PRESTo) for 2011-02-20 Mn 4.0 Sharif-Abad earthquake", The 17th Iranian Geophysical Conference (May 2016)
35. Satriano C., Elia L., Martino C., Lancieri M., Zollo A. and Iannaccone G., "PRESTo, the earthquake early warning system for Southern Italy: concepts, capabilities and future perspectives", Soil Dyn Earthq Eng (2011), doi: 10.1016/j.soildyn.2010.06.008
36. Satriano C., Wu Y.-M., Zollo A. and Kanamori H., "Earthquake early warning: Concepts, methods and physical grounds", Soil Dyn Earthq Eng 31 (2011), 106–118, doi: 10.1016/j.soildyn.2010.07.007
37. Satriano C., Lomax A. and Zollo A., "Real-time evolutionary earthquake location for seismic early warning", Bull Seism Soc Am 98-3 (2008), 1482–94, doi: 10.1785/0120060159
38. Vassallo M., Satriano C. and Lomax A., "Automatic picker developments and optimization: An optimization strategy for improving the performances of automatic phase pickers", Seism Res Lett 83 (2012), 531-540, doi: 10.1785/gssrl.83.3.541
39. Zollo A., Caruso A., De Landro G., Colombelli S. and Elia L., "A Bayesian Method for Real‐Time Earthquake Location Using Multiparameter Data", J Geophys Res Solid Earth 126 (2021), doi: 10.1029/2020JB020359
40. Zollo A., Colombelli S., Elia L., Emolo A., Festa G., Iannaccone G., Martino C. and Gasparini P., "An Integrated Regional and On-Site Earthquake Early Warning System for Southern Italy: Concepts, Methodologies and Performances", Wenzel, F., Zschau, J. (Eds.), Early Warning for Geological Disasters (2014), 117–137. Advanced Technologies in Earth Sciences. Springer Berlin Heidelberg, Berlin, Heidelberg, doi: 10.1007/978-3-642-12233-0_7
41. Zollo A., Festa G., Emolo A. and Colombelli S., "Source Characterization for Earthquake Early Warning", Encyclopedia of Earthquake Engineering (2014), pp. 1-21, Springer-Verlag Berlin Heidelberg (Eds.), doi: 10.1007/978-3-642-36197-5_244-1
42. Zollo A., Amoroso O., Lancieri M., Wu Y.-M. and Kanamori H., "A threshold-based earthquake early warning using dense accelerometer networks", Geophys J Int 183 (2010), 963–974, doi: 10.1111/j.1365-246X.2010.04765.x
43. Zollo A., Lancieri M., Nielsen S., "Earthquake magnitude estimation from peak amplitudes of very early seismic signals on strong motion records", Geophys Res Lett 33 (2006), doi: 10.1029/2006GL027795
44. Zuccolo E., Bozzoni F. and Lai C.G., "Regional Low‐Magnitude GMPE to Estimate Spectral Accelerations for Earthquake Early Warning Applications in Southern Italy", Seismological Research Letters 88 (2017), 61–71, doi: 10.1785/0220160038