|autoappname|: Automatic Processing =================================== Automatic ground motion processing is provided by |autoappname|. |autoappname| may * Run as a :ref:`daemon module ` of the |scname| system * Or be :ref:`executed on demand ` on the command line by an operator. Command-line help is available .. code-block:: sh $ seiscomp exec autosigma -h .. _autosigma-daemon: Processing as daemon -------------------- Typically, |autoappname| is executed in message mode and all information are received from the |scname| messaging system. Enable |autoappname| and start it separately: :: $ seiscomp enable autosigma $ seiscomp start autosigma or start with all other modules of your |scname| 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 :confval:`profiles`. An optional profile-dependent magnitude threshold may be defined by :confval:`profile.$name.minimumMagnitude`. |autoappname| is testing for new events every :confval:`cron.wakeupInterval` seconds. |autoappname| 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 :confval:`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 :cite:t:`scqc` and because |autoappname| requests dynamic time windows increasing with :term:`epicentral distance `. As requested time windows increase with epicentral distance a list of delay times may be provided through :confval:`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 :confval:`cron.eventKeep` seconds. Re-processing is triggered by event updates where changes in magnitude or :term:`hypocentral distance ` exceed the configured thresholds: * :confval:`profile.$name.deltaMagnitude` for changes in mangitude * :confval:`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 :confval:`cron.updateDelay`. .. _autosigma-demand: Processing on demand -------------------- To execute |autoappname| on demand simply call :: $ seiscomp exec autosigma --debug which connects to the messaging system and processes the data just like a :ref:`daemon ` module. The `debug` option provides additional information about the progress of the processing. In offline mode, |autoappname| is executed manually for a specific event and without the messaging system. Provide the event ID () for processing a particular event contained in the |scname| database, e.g. :: $ seiscomp exec autosigma --offline -d mysql://localhost/seiscomp --debug -E Data requests ------------- Waveform data are requested using the :term:`RecordStream` interface for stations at :term:`epicentral distances ` smaller than :confval:`acquisition.maximumEpicentralDistance`. The static maximum epicentral distance defined in :confval:`acquisition.maximumEpicentralDistance` is overridden if the magnitude-dependent maximum epicentral distances are defined in :confval:`acquisition.magnitudeDistanceTable`. The parameters :confval:`acquisition.initialTimeout` and :confval:`acquisition.runningTimeout` control the timeout to wait for first and subsequent records during the requests. Processing methods ------------------ The data are processed using the :ref:`described algorithms`. .. _sec-autosigma-output: Data products and output ------------------------ The :term:`incidents ` generated by |autoappname| are stored in the SIGMA database defined in :confval:`output.database`. Image and log files are saved in :confval:`output.exportPath` and :confval:`output.logfile`, respectively. The output files from |autoappname| 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 * :term:`epicentral distance ` * filter parameters * calculated parameters * :term:`CAV`- Cumulated Absolute Velocity * :term:`CI` - Characteristic Intensity * :term:`EDA` - Effective Design Acceleration * :term:`Ia` - Arias intensity * Ia05 - 5% of Arias intensity * Ia95 - 95% of Arias intensity * :term:`PGA` - Peak Ground Acceleration * :term:`PGV` - Peak Ground Velocity * :term:`PGD` - Peak Ground Displacement * :term:`T` - duration * :term:`Tm` - mean period * :term:`Tp` - predominant period * response spectrum * **pdPvR**: :math:`PGD/PGV` ratio. The actual values are given by **pgd** and **pgv** amplitudes which must be configured. .. note :: * **snrPd** and **pdPvR** are implemented according to :cite:t:`caruso-2017`. For sending **pdPvR**, **snrPd** or any other amplitude, **snrPd** must exceed :confval:`processing.minSnrPd`. * For computing **snrPd** and **pdPvR** identical time windows for **pgd** and **pgv** amplitudes must be configured to be complient with :cite:t:`caruso-2017`. * 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 :ref:`sigma-amplitude-plugin-params` and :ref:`sigma-amplitude-plugin-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 (:math:`PGD_N`): .. math:: snrPd = 20 * log_{10}(PGD/PGD_N) :math:`PGD` is the measured **pgd** amplitude and :math:`PGD_N` is PGD measured in the noise time window. * Map files with epicenter and stations written to :confval:`output.exportPath` showing * :term:`PGA`: grid-gpa.png * :term:`MMI`: grid-mmi.png .. figure:: /base/media/autosigma/grid-pga.png :width: 50% :align: center grid-pga.png file showing a PGA map. These files may be subject to further processing by custom scripts defined in :confval:`output.exportScript`. The generation of image files is controlled by the configuration parameters * :confval:`capture.dim.x`, :confval:`capture.dim.y`: the pixel resolution of the image. * :confval:`grid.extent.lon` and :confval:`grid.extent.lat`: the geographic extend of the generated grid. * :confval:`grid.dim.x`, :confval:`grid.dim.y`: the pixel resolution of the generated grid. * Grid files in Surfer format written to :confval:`output.exportPath` representing * :term:`PGA`: grid-gpa.grd * :term:`MMI`: grid-mmi.grd These files may be subject to further processing by custom scripts defined in :confval:`output.exportScript`. For viewing the output grid files on maps, the GUI modules showing maps can be configured with the :cite:t:`mapmultigrid` plugin. * Table files for waveforms written to :confval:`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 :confval:`output.exportScript`. * Table files for spectra written to :confval:`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 :confval:`output.exportScript`. * Log files written to :confval:`output.logfile`. The output files can be copied to other directories or files and processed by a user-defined script configured in :confval:`output.exportScript`. Read the :ref:`Configuration section ` for more details. .. note:: |autoappname| does not remove or alter the output files once they are written to :confval:`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 :confval:`output.exportScript` in the user-defined way, e.g. deleted, moved or sent to someone by e-mail.