AUTOSIGMA: Automatic Processing

Automatic ground motion processing is provided by AUTOSIGMA. AUTOSIGMA may

• Run as a daemon module of the SeisComP system

• Or be executed on demand on the command line by an operator.

Command-line help is available

$ seiscomp exec autosigma -h

Processing as daemon

Typically, AUTOSIGMA is executed in message mode and all information are received from the SeisComP messaging system. Enable AUTOSIGMA and start it separately:

$ seiscomp enable autosigma
$ seiscomp start autosigma

or start with all other modules of your SeisComP system:

$ seiscomp start

Triggering

Initial automatic processing is triggered automatically by the reception of new events fulfilling the criteria of at least one of the profiles defined in profiles. An optional profile-dependent magnitude threshold may be defined by profile.$name.minimumMagnitude. AUTOSIGMA is testing for new events every cron.wakeupInterval seconds. AUTOSIGMA starts processing as soon as the event parameters are received.

The data processing may be delayed with respect to the origin time of the event by cron.delayTimes seconds in order to allow for complete data within the requested time windows. The data may be incomplete due to data delays measured by scqc [12] and because AUTOSIGMA requests dynamic time windows increasing with epicentral distance.

As requested time windows increase with epicentral distance a list of delay times may be provided through cron.delayTimes. In this way data acquisition is restarted after the given time. If configured reasonably the data of more-distant stations will be complete.

Updates

The event parameters are kept in memory for a duration of cron.eventKeep seconds. Re-processing is triggered by event updates where changes in magnitude or hypocentral distance exceed the configured thresholds:

• profile.$name.deltaMagnitude for changes in mangitude

• profile.$name.deltaLocation for changes in epicenter location.

For avoiding blocking of the system by time-consuming data processing, event updates are considered with a minimum delay as configured by cron.updateDelay.

Processing on demand

To execute AUTOSIGMA on demand simply call

$ seiscomp exec autosigma --debug

which connects to the messaging system and processes the data just like a daemon module. The debug option provides additional information about the progress of the processing.

In offline mode, AUTOSIGMA is executed manually for a specific event and without the messaging system. Provide the event ID (<eventID>) for processing a particular event contained in the SeisComP database, e.g.

$ seiscomp exec autosigma --offline -d mysql://localhost/seiscomp --debug -E <eventID>

Data requests

Waveform data are requested using the RecordStream interface for stations at epicentral distances smaller than acquisition.maximumEpicentralDistance. The static maximum epicentral distance defined in acquisition.maximumEpicentralDistance is overridden if the magnitude-dependent maximum epicentral distances are defined in acquisition.magnitudeDistanceTable. The parameters acquisition.initialTimeout and acquisition.runningTimeout control the timeout to wait for first and subsequent records during the requests.

Processing methods

The data are processed using the described algorithms.

Data products and output

The incidents generated by AUTOSIGMA are stored in the SIGMA database defined in output.database. Image and log files are saved in output.exportPath and output.logfile, respectively.

The output files from AUTOSIGMA include:

• Incidents written to the database, e.g. incident.xml. The incidents contain the following information:

  • event information:

    • hypocentre: latitude, longitude, depth, date and time

    • magnitude

    • creation info: agency, author, date and time

  • per processed data stream:

    • creation information

    • unit

    • network, station, location, stream

    • epicentral distance

    • filter parameters

    • calculated parameters

      • CAV- Cumulated Absolute Velocity

      • CI - Characteristic Intensity

      • EDA - Effective Design Acceleration

      • Ia - Arias intensity

      • Ia05 - 5% of Arias intensity

      • Ia95 - 95% of Arias intensity

      • PGA - Peak Ground Acceleration

      • PGV - Peak Ground Velocity

      • PGD - Peak Ground Displacement

      • T - duration

      • Tm - mean period

      • Tp - predominant period

      • response spectrum

      • pdPvR: ratio. The actual values are given by pgd and pgv amplitudes which must be configured.

        Note

        • snrPd and pdPvR are implemented according to Caruso et al. [30]. For sending pdPvR, snrPd or any other amplitude, snrPd must exceed processing.minSnrPd.

        • For computing snrPd and pdPvR identical time windows for pgd and pgv amplitudes must be configured to be complient with Caruso et al. [30].

        • The incrementation of the time window for measuring pgd and pgv (e.g. 1 s, 2 s, 3 s) can be realized by running 3 the different plugins in parallel with their specific configuration of the time windows. The sections Configuration parameters and Setup provide examples.

      • snrPd: Signal-to-Noise ratio of PGD in the data time window after the trigger and the PGD within the noise time window before ():

        

        is the measured pgd amplitude and is PGD measured in the noise time window.

• Map files with epicenter and stations written to output.exportPath showing

  • PGA: grid-gpa.png

  • MMI: grid-mmi.png

  

  Figure 1: grid-pga.png file showing a PGA map.

  These files may be subject to further processing by custom scripts defined in output.exportScript.

  The generation of image files is controlled by the configuration parameters

  • capture.dim.x, capture.dim.y: the pixel resolution of the image.

  • grid.extent.lon and grid.extent.lat: the geographic extend of the generated grid.

  • grid.dim.x, grid.dim.y: the pixel resolution of the generated grid.

• Grid files in Surfer format written to output.exportPath representing

  • PGA: grid-gpa.grd

  • MMI: grid-mmi.grd

  These files may be subject to further processing by custom scripts defined in output.exportScript.

  For viewing the output grid files on maps, the GUI modules showing maps can be configured with the mapmultigrid [8] plugin.

• Table files for waveforms written to output.exportPath. One file per station containing

  • acceleration: NET.STA.LOC.STR-acc.slist

  • velocity: NET.STA.LOC.STR-vel.slist

  • displacement: NET.STA.LOC.STR-disp.slist.

  These files may be subject to further processing by custom scripts defined in output.exportScript.

• Table files for spectra written to output.exportPath. One file per station containing

  • acceleration: NET.STA.LOC.STR-acc.spec

  • velocity: NET.STA.LOC.STR-vel.spec

  • displacement: NET.STA.LOC.STR-disp.spec.

  These files may be subject to further processing by custom scripts defined in output.exportScript.

• Log files written to output.logfile.

The output files can be copied to other directories or files and processed by a user-defined script configured in output.exportScript. Read the Configuration section for more details.

Note

AUTOSIGMA does not remove or alter the output files once they are written to output.exportPath. It only creates the new files and overwrites existing ones. Files referring to previous incidents persists if not overwritten. All files should be treated by the output.exportScript in the user-defined way, e.g. deleted, moved or sent to someone by e-mail.