Files
2025/share/doc/scanloc/html/_sources/apps/scanloc.rst.txt

2966 lines
89 KiB
ReStructuredText

.. highlight:: rst
.. _scanloc:
#######
scanloc
#######
**Module for locating local earthquakes and man-made seismicity by DBSCAN
cluster search.**
Description
===========
Low-threshold monitoring
------------------------
*scanloc* associates detected P and S phases from local and regional earthquakes
and other seismic events for locating. It determines initial hypocenter
solutions by cluster search based on DBSCAN :cite:p:`dbscan`. Additional P and S phases are associated
to existing internal solutions from cluster search or solutions incoming through the messaging
system from external modules.
Due to the clustering and subsequent phase association scanloc facilitates low-threshold
monitoring of high- and low-rate seismicity with high accuracy.
.. _fig-scolv-location-tab:
.. figure:: media/scolv-location-tab.png
:align: center
:width: 16cm
scolv Location tab with an automatic earthquake solution from scanloc based on
P and S phases.
Teleseismic events
------------------
For teleseismic events *scanloc* can also be used to:
* :ref:`Associate more picks from P and S phases <scanloc-assoc>` to external origins,
* Suppress fake events due to detections from large earthquakes recorded by dense local networks at teleseismic distances.
A :ref:`dedicated section<scanloc-zero-weight>` explains the setup and the requirements.
Travel-time tables
------------------
The scanloc package ships with :ref:`densely sampled travel-time tables <scanloc-ttt>` for
:cite:t:`locsat` based on the IASP91 Earth model to enhance locating local earthquakes.
S phases
--------
In order to deliver high-quality picks from S phases, the :ref:`scanloc` package
also includes the *saic* plugin with the enhanced :ref:`S-phase picker<scanloc-spicker>`.
The S-phase picker can be applied to detect S phases on the horizontal components
or on the vertical component in case of 1-component sensors. In addition the scanloc
package comes with the :ref:`graphical debugger for the S-phase picker<scanloc-spick-debugger>`
provided by the *spickdbg* plugin.
Array measurements
------------------
Detections from array measurements including detection time, slowness and
back azimuth can be fully considered by :ref:`scoring <scanloc_scoring>`
depending on the applied locator.
Auxiliary tools
---------------
The scanloc package also ships with auxiliary Python script for
:ref:`real-time or non-real-time playbacks <scanloc-example>` or tuning. Read the
:ref:`dedicated section <sec-scanloc-aux-tools>` for more details.
Workflow
========
scanloc processes picks and origins in the following order:
#. Buffering of :ref:`picks and origins <scanloc-buffer>`,
#. :ref:`Clustering<scanloc-clustering>` of P picks:
* cluster formation,
* splitting of clusters in case of multiple P picks from the same station.
Clustering is skipped in case of an :ref:`external origin <external-origins>`.
#. :ref:`Association<scanloc-assoc>` of P and S picks to clusters and external
origins.
#. :ref:`Locating origins <scanloc-locator>` and formation of
:ref:`internal events <scanloc_internal>`,
#. :ref:`Scoring of origins <scanloc_scoring>` and setting the preferred origin
accordingly of an internal events.
#. Evaluation and :ref:`sending<scanloc-send>` of the preferred origin of an
internal event.
.. _fig-scanloc-workflow:
.. figure:: media/workflow.png
:align: center
:width: 16cm
Simplified work flow of scanloc.
.. _scanloc-buffer:
Pick and origin buffering
-------------------------
.. note::
scanloc processes picks with unique public IDs. However, the accuracy of
public IDs currently generated by :cite:t:`scautopick` is limited to
10 ms by default. In systems with very frequent picks and in
:ref:`pipeline systems <scanloc_pipeline>`
this limitation may result in clashes. Therefore, we recommend to let
scautopick use the same high-resolution public ID scheme as all
other modules by configuring the ID pattern explicitly in global module
configuration (:file:`global.cfg`):
.. code-block:: properties
publicIDPattern = @classname@/@time/%Y%m%d%H%M%S.%f@.@id@
A solution for scautopick will be provided with |scname| in a future release
with version > 6.7.2.
The entry point of *scanloc* is the addObject method which handles incoming
objects from the messaging system. By default it is subscribed to the messaging
group **PICK** and **LOCATION**. Depending on which object type (pick or origin)
is incoming different working steps are proceeded.
* In case a **pick** arrives, *scanloc*
#. tests the pick:
* evaluation status: Rejected picks are ignored unless the
command-line option :option:`--allow-rejected-picks` is given.
* tests the author information against :confval:`buffer.authorWhiteList`.
When the parameter is configured, the pick is ignored if its authors does
not match :confval:`buffer.authorWhiteList`.
#. adds the pick after passing the tests to the pick buffer keeping it
for the time given by
:confval:`buffer.pickKeep` or :option:`--pick-keep`,
#. tries to use the pick for :ref:`clustering <scanloc-clustering>`,
#. checks if the pick can be :ref:`associate to origins <scanloc-assoc>` in
the origin buffer exceeding a configurable :confval:`minScore`.
In case the pick can be associated, the scores for all new origins are
calculated and the origin with the highest score is selected.
* In case an **origin** arrives, *scanloc*
#. tests the origin:
* tests the evaluation mode. Manual origins are ignored unless
:confval:`buffer.ignoreManualOrigins` = *false*,
* tests the author information against :confval:`buffer.authorWhiteList`
and :confval:`buffer.originAuthorWhiteList`. When the parameters are
configured, the origin is ignored if its authors does not match the
configured values.
#. adds the origin after passing the tests to the origin buffer keeping it the time given by
:confval:`buffer.originKeep` or :option:`--origin-keep` seconds,
#. tries to :ref:`associate additional picks <scanloc-assoc>` to the origin.
Adjust the :confval:`buffer.*` parameters according to the times these objects
are required for processing.
.. hint::
You may use :ref:`playback_picks<sec-scanloc-playback_picks>` for printing
information on picks and amplitudes contained in XML files used, e.g., for
tuning or playbacks:
.. code-block:: bash
playback_picks --print picks.xml
.. _scanloc-clustering:
Clustering
----------
In case the pick cannot be associated, the cluster search is started. The
cluster search is based on the algorithm :cite:t:`dbscan` which
takes the required number of neighbours (:confval:`clusterSearch.minSize`)
and :confval:`clusterSearch.maxSearchDist` as configuration parameters.
The algorithm forms clusters of picks by searching for neighboring stations
that have picks. :ref:`Internal origins <scanloc_internal>` are formed from clusters.
The number of origins from cluster search is limited by the configuration parameter
:confval:`clusterSearch.maxOrigins`.
The cluster search considers picks from stations by :math:`distance` with:
.. math::
distance \le maxSearchDist
where maxSearchDist is configurable by :confval:`clusterSearch.maxSearchDist`.
:math:`distance` is the vector sum of the time difference :math:`\Delta t`
between the picks in units of seconds and of a potential travel time
:math:`tt` between the stations in units of seconds:
.. math::
distance = \sqrt{\Delta t^2 + tt^2}
and
.. math::
tt = \Delta x / v
where :math:`\Delta x` is the horizontal distance between the sensor locations
of stations in units of km and :math:`v` is the
:confval:`clusterSearch.averageVelocity` in units of km/s. Activate
:confval:`use3D` for considering 3D distances between sensor
locations. Therefore, :math:`distance` and
:confval:`clusterSearch.maxSearchDist` take units of seconds.
As the cluster search is done over time and location, the additional configurable
velocity parameter, :confval:`clusterSearch.averageVelocity`, is required to transform
the input parameters of the cluster search in the same dimension (time).
The velocity is a weighting factor between inter-station distances and
travel-time differences. A starting value should represent the average apparent
horizontal or the total medium P-wave velocity of the crust.
.. warning::
When the number of buffered cluster origins reaches :confval:`clusterSearch.maxOrigins`,
no more new origins can be formed and warnings are issued. Adjust accordingly:
* :confval:`buffer.originKeep`,
* :confval:`buffer.pickKeep`,
* :confval:`clusterSearch.maxOrigins`.
.. _sec-scanloc-cluster-time:
Limiting in time
^^^^^^^^^^^^^^^^
In real time picks are received in the order of their creation times. They are
considered for clustering if their pick times are within a time window
before the **cluster reference time**. The time window is defined by
:confval:`clusterSearch.maxPickDelay` but the **cluster reference time** is defined
either by the
* Pick time of the latest pick of the received picks when
:confval:`clusterSearch.referenceTimeMode` = 'LastPick' (default),
* Pick time of the latest received pick which defines are group of *N*
picks within :confval:`clusterSearch.maxPickDelay` when
:confval:`clusterSearch.referenceTimeMode` = 'MaxPickDelay'. Here, *N* is the
maximum of :confval:`clusterSearch.minSize`
and :confval:`association.minPhase`. **This mode is relevant if only very few
stations with significantly different data delay provide the picks.**
Otherwise picks may not be available for clustering at the same time
preventing to form clusters and new origins.
Thus, when setting :confval:`clusterSearch.referenceTimeMode` = 'MaxPickDelay'
re-setting the cluster reference time is delayed depending on the amount and
density of incoming picks. With this option picks which have a larger delay can
be considered. Such delays occur, e.g., due to larger data delays or larger
record lengths.
.. math::
pick delay = creationTime - pickTime
where
* :math:`pick.creationTime`:time at which the pick was made,
* :math:`pickTime`: actual time of the phase arrival.
Picks available within a trapezoid-like time window are considered for
clustering.
For a pick with zero delay, the cluster reference time is initially set and picks
within the **blue trapezoid** (figure below) are considered.
Normally, picks have some delay which delays defining the trapezoid. This makes accessible
other picks available with some delay, too, allowing these picks to be considered
(**green trapezoid**). Subsequently, the trapezoid is extended until the
cluster reference time is updated.
This may be the next pick with a larger pick time
(**olive trapezoid**, :confval:`clusterSearch.referenceTimeMode` = 'LastPick') or
the time of the pick which is preceded by at least :confval:`clusterSearch.minSize`
picks within :confval:`clusterSearch.maxPickDelay` (**yellow trapezoid**,
:confval:`clusterSearch.referenceTimeMode` = 'MinPickDelay').
Thus, picks which have a long delay do not fall within the relevant trapezoid and
cannot be considered for clustering as they are not available at the time of clustering.
The trapezoid is set with respect to the cluster reference time, CRT1 in the figure below,
considering the delay of the defining pick and the time until the next relevant
pick which updates the reference time (CRT2):
* CRT2 with :confval:`clusterSearch.referenceTimeMode` = 'LastPick' or
* Deleyed CRT2 since :confval:`clusterSearch.referenceTimeMode` = 'MaxPickDelay'.
The longer the time until the update, the
more picks with larger delays can be considered for clustering, e.g., the delayed
clustered pick in the figure below.
.. figure:: media/cluster-reference.png
:align: center
:width: 18cm
Schematic view of pick time vs. pick delay time of picks for clustering.
The cluster reference time determines the trapezoid within which picks can be
considered for clustering.
Here, the delayed clustered pick only becomes part of the cluster with
:confval:`clusterSearch.referenceTimeMode` = 'MaxPickDelay'.
.. figure:: media/picks_clustering-maxPickDelay10.png
:align: center
:width: 18cm
clusterSearch.maxPickDelay = 10 s.
.. figure:: media/picks_clustering-maxPickDelay20.png
:align: center
:width: 18cm
clusterSearch.maxPickDelay = 20 s.
Real-life examples of picks considered for clustering with different values
for :confval:`clusterSearch.maxPickDelay` and
:confval:`clusterSearch.referenceTimeMode` = 'MaxPickDelay'. P picks with
green symbols are considered for clustering, picks with red symbols are not.
Clearly, the larger :confval:`clusterSearch.maxPickDelay` the more picks are
available for clustering but the more clusters from unrelated picks (false
clusters) may be created.
.. note::
* For small and similar delays of all P picks, :confval:`clusterSearch.maxPickDelay`
can be directly read from travel-time curves. A small margin should be added
account for differences in delay.
* In XML playbacks, the creation times may not be representative of
real-time conditions. Therefore, pick times may be used for the timing instead
of creation times. Read the section :ref:`scanloc-example` for more details
and the consequences.
If picks arrive with a larger delay than others, there is a risk that they cannot
be considered anymore for the cluster. When only few picks are available the events
may then be missed. To overcome the issue, you may increase :confval:`clusterSearch.maxPickDelay`
or set the parameter :confval:`clusterSearch.referenceTimeMode` = "MaxPickDelay".
While increasing :confval:`clusterSearch.maxPickDelay` may slow down the clustering
and increase the risk to cluster unrelated picks,
:confval:`clusterSearch.referenceTimeMode` = "MaxPickDelay" will only increase the
cluster reference time if at least :confval:`clusterSearch.minSize` P picks are
available in the considered time window. Run :program:`scanloc` on the command line
with the :option:`--cluster-search-log-file` to learn about cluster reference
times and the considered picks. A suggestion for :confval:`clusterSearch.maxPickDelay`
is provided in the summary section at the end of the resulting output. For more
options read the section :ref:`sec-scanloc-tuning`.
Within one cluster, the difference in the pick times between the
cluster reference time and any other pick must thus not exceed :confval:`clusterSearch.maxPickDelay`.
Otherwise the pick is rejected from clustering. The parameter :confval:`clusterSearch.maxPickDelay`
has a big impact on the performance of the cluster search. Choosing the parameter
as small as possible will speed up scanloc and will reduce the complexity of the
cluster search.
The DBSCAN algorithm can deliver multiple pick clusters. The cluster search can
be disabled using :confval:`clusterSearch.maxPickDelay`:
.. code-block:: properties
# Maximum allowed difference between P pick and cluster reference time(latest pick time).
# The cluster search ignores all picks which exceed the value. Using "-1" enables all picks
# regardless of the delay. Unit: seconds.
clusterSearch.maxPickDelay = 0
Then, only :ref:`external origin <external-origins>` can be considered for
:ref:`phase association<scanloc-assoc>`.
In combination with :confval:`buffer.futureTimeDelta` or
:option:`--future-time-delta`
applying :confval:`clusterSearch.referenceTimeMode` = "MaxPickDelay" may make
updating the cluster reference time more robust to singular data timing issues.
However, the timing issue of the waveforms and the pick times remain and may
impact the clustering itself. Therefore, :confval:`buffer.futureTimeDelta`
should only be configured with positive values only in extraordinary
circumstances.
Limiting in space
^^^^^^^^^^^^^^^^^
The cluster search can be constraint to stations within a region given by the
coordinate of a central point and the radius around that point. The region constraint
is configured through :confval:`clusterSearch.regionFilter`. Applying this parameter
will disregard picks from stations outside the region for cluster search increasing
the speed and the complexity. Nevertheless, the excluded picks are available for
:ref:`phase association <scanloc-assoc>`.
For running the cluster search in several regions in parallel, different instances
of scanloc taking picks from the same of different pickers can be created and started.
Cluster splitting
^^^^^^^^^^^^^^^^^
Originally, clusters may contain multiple phase picks from the same sensor but
only one pick per sensor shall be accepted. Therefore, the clusters with picks
from the same sensor are split into separate clusters with only one pick per
sensor.
Typcially, the sensors are discriminated by their sensor location codes, LOC, as
defined in the SEED manual :cite:p:`seed-2012` using the NET.STA.LOC.CHA stream
representation. Since some stations provide data for different sensors on the
same sensor location code but with different channel codes (e.g. seismic and
infrasound sensors), the channel code, CHA, may be a better discrimination
measure for sensor identity. On the other hand, picks made on different sensor
location of the same station could be attributed to the same site, e.g., in
regional or telseismic monitoring. Then, the station code, STA, would be
preferred for discrimination. The parameter
:confval:`clusterSearch.streamCheckLevel` allows defining the stream level on
which to check sensor identity.
.. hint::
In order to consider picks from equal sensor location codes but with
different channel IDs, configure scanloc with
.. code-block:: properties
clusterSearch.streamCheckLevel = cha
All new clusters are considered new origins. By activating
:confval:`clusterSearch.checkOrigins`, all new clusters are checked again.
Clusters not meeting the configured cluster criteria are removed from the buffer.
The check imposes an additional overhead on the cluster search but it typically
lowers the chance for fake solutions and it also lowers the load on the
:ref:`phase association <scanloc-assoc>` and scanloc in general.
.. _sec-scanloc-tuning:
Tuning and optimization
^^^^^^^^^^^^^^^^^^^^^^^
Use the option :option:`--cluster-search-log-file` to store detailed information
on the clustering process in a file, e.g., *cluster.log*. The given values can be
used to optimize the cluster search parameters.
.. code-block:: sh
scanloc --ep picks.xml -d [database] --cluster-search-log-file cluster.log > origins.xml
For optimizing the configuration of the parameter :confval:`clusterSearch.maxPickDelay`
use the default value first:
.. code-block:: sh
clusterSearch.maxPickDelay = -1
The given output file contains the clusters with the pick details. After each
cluster the maximum time interval between the first and the last pick in the
cluster is provided. A summary at the end of the file shows the largest value, e.g.:
.. code-block:: sh
+ cluster source: -69.6279, -21.4715, 1231891115.191
+ pick ID: *20090113.235827.36-AIC-CX.PB01..HHZ X: -69.4874 Y: -21.0432 time: 1231891107.368 distance: 14.715 s
+ pick ID: 20090113.235832.91-AIC-CX.PB02..HHZ X: -69.8960 Y: -21.3197 time: 1231891112.918 distance: 8.443 s
+ pick ID: 20090113.235839.53-AIC-CX.PB07..HHZ X: -69.8862 Y: -21.7267 time: 1231891119.538 distance: 10.677 s
+ pick ID: 20090113.235840.94-AIC-CX.PB09..HHZ X: -69.2419 Y: -21.7964 time: 1231891120.940 distance: 14.645 s
+ 1 split cluster
+ cluster
+ 20090113.235827.36-AIC-CX.PB01..HHZ
+ 20090113.235832.91-AIC-CX.PB02..HHZ
+ 20090113.235839.53-AIC-CX.PB07..HHZ
+ 20090113.235840.94-AIC-CX.PB09..HHZ
+ maximum pick time interval for this cluster: 13.572 s
+ minimum maxPickDelay required for this cluster: 13.572 s
+ end
+ end
+ end
+ end
+ summary:
+ maximum experienced cluster time interval: 40.840 s
+ minimum value of clusterSearch.maxPickDelay for all clusters: 13.572 s
The summary value can be used as a lower proxy to set
:confval:`clusterSearch.maxPickDelay`.
Locating
^^^^^^^^
Clusters are located by the configured :ref:`locator <scanloc-locator>`. If the
location fails, the origin is ignored unless :confval:`clusterSearch.preliminary`
is active. Then, preliminary values are chosen:
* Origin location is the center of the detecting stations,
* Origin time is the time of the first phase pick,
* Status is set to `preliminary`.
The status will be unset if more phases can be associated and the new origin can
be located.
.. _scanloc-assoc:
Phase Association
-----------------
When a cluster of P picks meeting :confval:`association.minPhase` is found
or an :ref:`external origin <external-origins>` arrives, :program:`scanloc` tries
to associates additional P- and S-type phase picks which are
:ref:`buffered <scanloc-buffer>` and which meet the association criteria:
* **P-type picks:**
* the epicentral distance does not exceed :confval:`association.maxDist`,
* no other P pick from the same channel exists in the origin,
* the pick time, :math:`t_p`, of the new pick is close to the arrival time
predicted by the travel-time interface, :math:`t_p^{pred}`, considering
:confval:`association.maxPResidual`:
.. math::
t_p^{pred} - association.maxPResidual \le t_p \le t_p^{pred} + association.maxPResidual
* **S-type picks:**
* the epicentral distance does not exceed :confval:`association.maxDist`,
* the evaluation mode of the pick is manual **or** the pick references a P
pick which has been already associated. The reference to a P pick is given
as a comment of the S pick. Example:
.. code-block:: xml
<pick>
...
<comment>
<text>Pick/20230726100411.964268.1316601</text>
<id>RefPickID</id>
</comment>
</pick>
The reference check serves as a quality control feature. I can be dropped by
:option:`--drop-reference-check` and
:confval:`association.dropReferenceCheck`.
* the pick time, :math:`t_s`, of the new pick is close to the arrival time
predicted by the travel-time interface, :math:`t_s^{pred}`, considering
:confval:`association.maxSResidual`:
.. math::
t_s^{pred} - association.maxSResidual \le t_s \le t_s^{pred} + association.maxSResidual
The new set of picks are used for :ref:`relocating <scanloc-locator>`.
In case the buffered pick is a P pick the algorithm
directly attempts to associate the pick solely based on the residual. It tries
to relocate
the solution after each successful association. P picks with travel-time
residuals larger than :confval:`association.maxResidual` are rejected.
After the P-picks are associated and relocated, *scanloc* tries to associate the
S picks. This association is not based
on the residual but on the P pick referenced by the S pick. The S pick is
only associated in case the reference P pick is already associated to the
origin. Also after each S pick a relocation is done. In case the relocation
fails or the event residual is larger than :confval:`maxRMS`,
the S pick is associated with a weight of 0. The score of the resulting
origin is compared with scores of origins belonging to the same event. In case
the score is higher than the rest of the origins, the origin is
:ref:`sent out<scanloc-send>`.
In addition to origins from the cluster search, *scanloc* can also treat external
origins that are created by other associators, e.g., :cite:t:`scautoloc`.
In case an such origin is received *scanloc* tries to associate all picks in the
buffer to the origin. The association and the following processes are the same as
described above. See figure :ref:`fig-scanloc-workflow` for an overview.
The maximum epicentral distance up to which picks are considered is configured
by :confval:`association.maxDist`. However, this parameter can be overruled per
network and station by providing a station table in a file given by
:confval:`association.stationConfig`. As in :cite:t:`scautoloc` each line of the
table consists of the network code, the station code, a switch and the maximum
epicentral distance in degrees. Wildcards can be used for the network and the
station code. The switch causes the associator to consider (=1) or to ignore
(=0) a network or a station.
The last occurrence of an item in a table overrules previous ones, e.g.
.. code-block:: properties
* * 1 180
GR * 1 60
GR GRA1 1 20
Z3 * 0 180
For associating the picks, travel times from look-up tables are used. The
:confval:`association.tableType` and the :confval:`association.table` can be
configured to provide specific tables which may be more appropriate for specific
regions. Currently, only a limited number of travel-time table types
(:confval:`association.tableType`) are supported. scanloc provides
:ref:`densely-sampled travel-time tables <scanloc-ttt>` for LOCSAT.
.. csv-table::
:header: types supported by association.tableType, location of tables for association.table
:widths: 15,100
:delim: ;
homogeneous; model is defined by :confval:`ttt.homogeneous.$name.*` in global module configuration
libtau; @DATADIR@/ttt
LOCSAT; @DATADIR@/locsat/tables, tables should not be modified
Travel times from other sources can be considered by a plugin exposing
the travel times to the travel-time interface.
The considered table must provide the time for all considered phases.
Example configuration (:file:`scanloc.cfg`):
.. code-block:: properties
# Type of travel-time tables for phase association. May be different from locator.
# Use e.g. libtau or LOCSAT.
association.tableType = LOCSAT
# Name of travel-time table used for phase association. May be different from locator
# profile.
association.table = iasp91_scanloc
.. note::
Travel-time tables used during association and location may be different.
Therefore the travel-time residuals visible after relocating may be different
from the travel-time residuals considered during association.
The differences must be considered when configuring :confval:`association.maxPResidual`
and :confval:`association.maxSResidual`.
.. _external-origins:
Processing external origins
---------------------------
Origins received from other modules through the messaging or provided by XML files
can be processed and :ref:`more phases can be associated <scanloc-assoc>`. In
order to ignore such external origins set :confval:`buffer.ignoreOrigins`:
.. code-block:: properties
buffer.ignoreOrigins = true
Processing of external origins may be undesired when
* Involving other modules excepting origins by the messaging system, e.g.,
:cite:t:`screloc`. These modules may run in a loop with scanloc.
* Receiving origins from other systems.
Configure :confval:`buffer.authorWhiteList` with the author names of
origins **which shall be processed**, e.g., :cite:t:`scautoloc`:
.. code-block:: properties
buffer.authorWhiteList = scautoloc@localhost
Automatic and manual origins from all other authors will be ignored.
.. _scanloc-origin-status:
Status of origins
-----------------
The status of origins can be set during pick processing
* Normally, the status of origins is **unset**.
* The status of origins from cluster search which only be located with fixed
depth (:confval:`fixDepth`, :confval:`forceFixDepth`) is set to
**preliminary**.
* The status of origins which can be relocated with a free-depth solution is set
to **unset** if the origin status of the origin was previously set.
However, the evaluation status may be later changed at
different times by different modules, e.g., the gempa module :program:`sceval`.
In order to track this history a journal entry is created and sent
when running scanloc with a connection to the messaging or added to the
XML output long with the origins.
In future versions of SeisComP such journal entries will be made accessible in
:program:`scolv`.
.. _scanloc-send:
Sending of origins
------------------
Before sending a new :ref:`internal origin <scanloc_internal>` to the
messaging or to XML output (:option:`--ep`) it is tested against the
configuration:
* Picks are removed when their travel-time residual > :confval:`association.maxResidual`
and origins are :ref:`relocated <scanloc-locator>`,
* Origins are skipped when the score < :confval:`minScore`,
* Origins are skipped when the depth > :confval:`ignoreDepth`.
The remaining internal origins are evaluated based on :ref:`scoring <scanloc_scoring>`.
The best origin of the same :ref:`internal event <scanloc_internal>` is the one
which has the highest score. When meeting the parameters
:confval:`ignoreDepth`, :confval:`maxRMS` and :confval:`minScore` it is sent to the
SeisComP :cite:t:`messaging` or to stdout in case of non-real-time playbacks
(:option:`--ep`).
In real-time operation, the sending of origins may be delayed allowing to find
new origins with higher score.
The delay reduces the amount of origins in SeisComP systems and the load of
other modules. The send interval is controlled by the :confval:`publication`
configuration parameters.
.. note::
In non-real-time (:option:`--ep`) playbacks, the :confval:`publication`
configuration parameters are ignored and all origins are sent without delay.
.. _scanloc-performance:
Performance considerations
--------------------------
In case of dense large-N networks and high seismicity situations,
very many phase picks, e.g., hundreds of picks for a single event may be
provided to and processed by scanloc. In such situations, scanloc was observed
to slow down with default parameters but a sensible configuration of
:confval:`clusterSearch.maxSize` and :confval:`association.arrivalCountMinRes`
could overcome the obstacles.
* `clusterSearch.maxSize` controls the maximum number of picks in a cluster
after selecting core points and before adding more picks. Since core points
are first collected, clusters may have a higher number of picks. The goal of
this parameter is to speed up scanloc. The parameter may help to increase the
performance of scanloc in case of dense large-N networks where very many
cluster can be formed due to the proximity of stations or generous
configuration.
* `association.arrivalCountMinRes` controls the association of picks to origins.
For origins with a larger number of arrivals than configured, the association
of P and S picks is controlled by the minimum of (`association.maxPResidual`,
`association.maxResidual`) and (`association.maxSResidual`,
`association.maxResidual`), respectively. The goal of this parameter is to
speed up scanloc by only associating picks to already stable origins defined
by many arrivals where new picks later on are unlikely to be removed again
from origins by residual checks. The parameter may help to increase the
performance of scanloc in case of dense large-N networks where very stations
provide phase picks.
.. _scanloc_internal:
Internal Origins and Events
===========================
*scanloc* forms
* **Internal origins** from the locations and the associated picks (arrivals) of
new arrival sets,
* **Internal events** from internal origins based on the
:confval:`eventAssociation.*` parameters. The procedure is similar to
:cite:t:`scevent`. An origin is compared to the preferred origin of an
existing internal event. It is associated to the existing internal event if
one of the criteria applies:
* the origins share a minimum of
:confval:`eventAssociation.minMatchingArrivals` :term:`arrivals <arrival>`.
Arrivals must be identical by the ID of the referenced :term:`pick` unless
:confval:`eventAssociation.compareAllArrivalTimes` = *true*. Then, a margin
of :confval:`eventAssociation.maxMatchingArrivalTimeDiff` applies for
considering different picks to be the same.
* the differences in origin time **AND** :term:`epicenter` is within
:confval:`eventAssociation.maxTimeSpan` **AND**
:confval:`eventAssociation.maxDist`, respectively.
Only if the :ref:`score <scanloc_scoring>` of a new origin exceeds the score
of the last sent origin of the same internal event, the new origin is
:ref:`sent out<scanloc-send>`.
.. _scanloc-locator:
Locating Origins
================
scanloc locates internal origins based on the configuration by the
:confval:`locator.type` and :confval:`locator.profile` parameters. The list of
available locators can be printed by *scanloc*:
.. code-block:: sh
scanloc --locator-list
In order to make an alternative locator available to *scanloc*, the respective
plugin must be loaded.
Consider a fast locator (:confval:`locator.type`), e.g., LOCSAT or
:cite:t:`hypo71` with an appropriate profile (:confval:`locator.profile`).
For LOCSAT dense the provided :ref:`dense travel-time tables <scanloc-ttt>` may
be more appropriate at short epicentral distance than the default one.
Example configuration (:file:`scanloc.cfg`):
.. code-block:: properties
# The locator type to use
locator.type = LOCSAT
# The locator profile to use
locator.profile = iasp91_scanloc
.. note::
Computational speed can be an issue when alternative locators are used
and when many picks are to be tested during association. In this case *scanloc*
can be configured with :cite:t:`locsat` but :cite:t:`screloc` may be used
along with the preferred locator and profile to relocate the origin. The
locator NonLinLoc :cite:p:`nonlinloc` is certainly too slow for being used in
:program:`scanloc` but is a good option for :program:`screloc`.
If the locator fails to locate and :confval:`locator.fixDepth` is active, the
hypocenter depth is fixed to :confval:`defaultDepth` and the origin is relocated.
.. _scanloc_scoring:
Scoring Origins
===============
Each :ref:`internal origin <scanloc_internal>` is evaluated and ranked by
calculating a :math:`score` in order for scanloc to define the preferred origin
of an internal event and for comparison against :confval:`minScore` before
eventually :ref:`sending an origin <scanloc-send>`.
The score is calculated by a score processor which
is provided by a plugin. Score plugins shipped with scanloc can be equally
applied to :program:`scanloc` and :cite:t:`scevent`. The plugins currently
provided along with :program:`scanloc` are:
* *scoresum* (default): :ref:`OriginSum <scanloc_originscoresum>` calculating
the score as a weighted sum of :term:`Origin` attributes.
* *scoremf*: :ref:`OriginMultiFeature <scanloc_originscoremf>` calculating
the score as a weighted sum of :term:`Origin` attributes like in
:ref:`OriginSum <scanloc_originscoresum>` but allowing to add additional
contributions by picks from infrasound, strong motion and low-gain
instruments, authors, gap, etc.
but more processors can be implemented by |gempa| or anyone else. Read the
section :ref:`scanloc_originscore-dev` for the details.
.. _scanloc_originscoresum:
OriginSum
---------
The OriginSum score processor is provided by the plugin *scoresum* located in
:file:`@DATADIR@/plugins/scevent/scoresum.so`. The plugin calculates the
:math:`score` for origins as a weighted sum from
* The number of associated and used P- (Is-) and S-phase picks considering
separately the number of used pick times, slowness and backazimuth
(*pTimeCount*, *pSloCount*, *pBazCount* and *sTimeCount*, *sSloCount*, *sBazCount*),
* The number of loosely associated P and S picks (*p0Count* and *s0Count*).
Such picks are arrivals with 0 weight. They are not used at all for origin
location,
* Source *depth* represented by *depthFactor* (see below) and
* *RMS* time residual represented by *residualFactor* (see below).
Methodology
^^^^^^^^^^^
The score is computed as
.. math::
score =\ &score.sum.p[0] \times pTimeCount + score.sum.p[1] \times pSloCount + score.sum.p[2] \times pBazCount \\
+\ &score.sum.p0 \times p0Count \\
+\ &score.sum.s[0] \times sTimeCount + score.sum.s[1] \times sSloCount + score.sum.s[2] \times sBazCount \\
+\ &score.sum.s0 \times s0Count \\
+\ &score.sum.depth \times depthFactor \\
+\ &score.sum.residual \times residualFactor
with
.. math::
residualFactor =\ \left(\frac{score.sum.normalizationRMS}{RMS + score.sum.normalizationRMS}\right)^4 \\
depthFactor =\ \left(\frac{score.sum.normalizationDepth}{depth + score.sum.normalizationDepth}\right)^4.
where the weight factors :confval:`score.sum.p` [0:2], :confval:`score.sum.p0` ,
:confval:`score.sum.s` [0:2], :confval:`score.sum.s0` ,
:confval:`score.sum.depth` and :confval:`score.sum.residual` can be configured.
The values for *depthFactor* and *residualFactor* are derived from origin
*depth* and *time residual* and the configured values for
:confval:`score.sum.normalizationDepth` and :confval:`score.sum.normalizationRMS`.
Higher weight is given to origins with shallower depth. You may set
:confval:`score.sum.depth` to form the score independent of depth in regions with
shallow and deep seismicity:
.. code-block:: properties
score.sum.depth = 0
Phase picks may not only provide measurements of time but also of slowness
and back azimuth. The existence of these additional values, if used by the
locator, may impact the solution quality which can be considered by the score.
If you believe that slowness and back azimuth may provide valuable information,
the contribution to score by these picks may be increased by configuring
:confval:`score.sum.p` and :confval:`score.sum.s` with additional weights for slowness
and backazimuth like
.. code-block:: properties
score.sum.p = 1,0.5,0.5
score.sum.s = 1,0.5,0.5
Read the documentation of the locators in |scname| in order to understand if
slowness and back azimuth are considered. An overview over locators is given in
the concepts section of the :cite:t:`SeisComP documentation <seiscomp-doc>`.
Configuration
^^^^^^^^^^^^^
For utilizing the *scorsum* plugin with the OriginSum score processor in scanloc
configure scanloc as:
.. code-block:: properties
plugins = ${plugins},scoresum
score = OriginSum
For utilizing the *scoresum* plugin with the OriginSum score processor
in scevent configure scevent as:
.. code-block:: properties
plugins = ${plugins},scoresum
eventAssociation.score = OriginSum
eventAssociation.properties = ...,SCORE,...
.. _scanloc_originscoremf:
OriginMultiFeature
------------------
The OriginMultiFeature score processor is provided by the plugin *scoremf*
located in :file:`@DATADIR@/plugins/scevent/scoremf.so`. The plugin calculates
the :math:`score` for origins similar to
:ref:`OriginSum <scanloc_originscoresum>` but allowing to add additional
contributions by picks from infrasound, strong motion and low-gain instruments,
authors, azimuthal gap, etc.
Methodology
^^^^^^^^^^^
The score is computed as
.. math::
score =\ &score.mf.weights.p[0] \times pTimeCount + score.mf.weights.p[1] \times pSloCount + score.mf.weights.p[2] \times pBazCount \\
+\ &score.mf.weights.p0 \times p0Count \\
+\ &score.mf.weights.s \times sTimeCount \\
+\ &score.mf.weights.s0 \times s0Count \\
+\ &score.mf.weights.strongMotion \times strongMotionCount \\
+\ &score.mf.weights.infrasound \times infrasoundCount \\
+\ &score.mf.weights.depth \times depthFactor \\
+\ &score.mf.weights.residual \times residualFactor \\
+\ &score.mf.weights.gaps \times gapFactor \\
+\ &authorfactor
with
.. math::
depthFactor =\ \left(\frac{score.mf.weights.normalizationDepth}{depth + score.mf.weights.normalizationDepth}\right) \\
residualFactor =\ \left(\frac{score.mf.weights.normalizationRMS}{RMS + score.mf.weights.normalizationRMS}\right) \\
gapsFactor =\ 1.0 - score.mf.weights.gap * \left(\frac{azimuthal gap}{360.0}\right)
.. math::
authorfactor =\
\begin{cases}
0 & \text{if author of pick is not found in score.mf.weights.authors.author} \\
score.mf.weights.authors.score & \text{if author of pick is found as score.mf.weights.authors.author}
\end{cases}
However, when origin time residual or depth exceed
:confval:`score.mf.weights.normalizationRMS` and
:confval:`score.mf.weights.normalizationDepth`, respectively, then
.. math::
score = score.mf.defaultScore
which typically assigns a very low priority to an origin.
Phase picks may not only provide measurements of time but also of slowness
and back azimuth. The existence of these additional values, if used by the
locator, may impact the solution quality which can be considered by the score.
If you believe that slowness and back azimuth may provide valuable information,
the contribution to score by these picks may be increased by configuring
:confval:`score.sum.p` with weights for slowness and backazimuth like
.. code-block:: properties
score.mf.weights.p = 1,0.5,0.5
.. note::
All elements in the equations above starting with *score.mf.* are
configurable parameters. Read the section :ref:`scanloc/ScoreMF` for the full
description of parameters.
Configuration
^^^^^^^^^^^^^
For utilizing the *scoremf* plugin with the OriginMultiFeature score processor
in scanloc configure scanloc as:
.. code-block:: properties
plugins = ${plugins},scoremf
score = OriginMultiFeature
For utilizing the *scoremf* plugin with the OriginMultiFeature score processor
in scevent configure scevent as:
.. code-block:: properties
plugins = ${plugins},scoremf
eventAssociation.score = OriginMultiFeature
eventAssociation.properties = ...,SCORE,...
.. _scanloc_originscore-dev:
Plugin development
------------------
Custom score processors may be implemented by additional plugins. You may
develop such plugins yourself or request a development from
`gempa GmbH <https://www.gempa.de/contact/>`_. An
introduction into the development is given on:
`GitHub <https://github.com/gempa/seiscomp-programming-templates>`_ .
For utilizing the *pluginName* plugin with the *processorName* processor in
scanloc configure scanloc as:
.. code-block:: properties
plugins = ${plugins},scoresum
score = OriginSum
For utilizing the *pluginName* plugin with the processorName processor in scevent
configure scevent as:
.. code-block:: properties
plugins = ${plugins},pluginName
eventAssociation.score = processorName
eventAssociation.properties = ...,SCORE,...
.. _scanloc_pipeline:
Pipeline Systems
================
When operating scanloc in a pipeline, configure :confval:`connection.subscriptions`
to receive picks and origins from and :confval:`connection.primaryGroup` to send
origins to the right message group.
Alternatively you may configure :confval:`buffer.authorWhiteList` for receiving
picks and origins from modules with the listed authors. In this case, configuring
new message groups for receiving and sending objects may not be required depending
on the other modules involved in the pipeline.
Please also understand the note on public IDs of the
:ref:`buffer section <scanloc-buffer>`.
.. _scanloc-redundancy:
Redundant Systems
=================
In redundant systems where origins are received from other machines with idential
or simialar setup you may wish to suppress re-processing these origins. Read
section :ref:`external-origins` for the configuration.
.. _scanloc-zero-weight:
Association of Teleseismic Phases
=================================
Dense local networks used to monitor local seismicity are often able to catch
also a significant number of phases from earthquakes at teleseismic distances.
Such phases include Pdiff or PKP.
Especially PKP may contain a significant amount of energy at higher frequencies.
Therefore PKP is often detected by networks that are tuned to detect
local earthquakes.
Due to the steep incidence and the low horizontal slowness of these phases, they
are sometimes located as fake deep earthquakes below the network.
*scanloc* can be used to suppress this type of fake events.
In a 2-pipeline setup, *scanloc* can associate such teleseismic phases recorded
by the local network with origins that were found by the pipeline for
monitoring teleseismic earthquakes. Then :cite:t:`scevent`
will associate
the origins from the teleseismic pipeline with the fake origins from the
pipeline for local monitoring to the same event. The assumption is that the origins
from the teleseismic pipeline win over the origins from pipeline for local monitoring
because they have more associated arrivals. In this case the origins from pipeline
for teleseismic monitoring that has most phases becomes the preferred origin for
the event. This :ref:`scanloc` feature requires an extended license.
*Setup of a 2-pipeline system*
1. Generate a 2-pipeline system involving at least :cite:t:`scautopick`,
:program:`scanloc` and :cite:t:`scevent` :
* **Pipeline 1** monitors teleseismic earthquakes using :program:`scautopick`,
:program:`scautoloc`, :program:`scanloc` and default message groups.
* **Pipeline 2** monitors local earthquakes using *l1autopick*, *l1autoloc*
and *l1scanloc* using the message groups L1PICK and L1LOCATION.
#. Let *scanloc* not perform cluster search (:confval:`clusterSearch.maxOrigins` = 0)
but allow *scanloc* to only associate P picks from pipelines 2 based on origins
from :program:`scautoloc` (connection.subscriptions = "LOCATION, L1PICK" in the global
module parameters). Configure *scanloc* to associate the picks from pipeline 2
as picks with zero weight when they are, e.g., in the PKP or Pdiff distance
range. Use one zeroWeight profiles per phase.
In order to facilitate association of teleseismic picks, the picks and the origins
must be kept in memory for sufficient time. Increase :confval:`buffer.pickKeep`
and :confval:`buffer.originKeep` accordingly, e.g., to 1800 s.
In this way zero-weight picks will not be used for locating the event but are
part of the origin and can be considered by *scevent*.
#. Configure *scevent* to listen to the message groups from both pipelines (e.g.
LOCATION and L1LOCATION) and activate the *scevent* module parameter
*eventAssociation.allowLooseAssociatedArrivals* (:file:`scevent.cfg`).
.. figure:: media/zeroweight_pipeline.png
:align: center
:width: 10cm
Parameter exchange in a 2-pipeline system. The messaging system, responsible
for the parameter exchange, is representated by the circles, indicating the
message groups. Teleseismic monitoring is configured with scautopick,
scanloc, scautoloc and local monitoring with l1autopick,
l1scanloc, l1autoloc.
*Playback using picks and amplitudes from 2-pipeline system (real-event examples)*
.. _fig-zeroweight1:
.. figure:: media/scolv_zeroweight1.png
:align: center
:width: 10cm
Location tab in *scolv* with zero-weight picks associated by *scanloc* as PKP phases.
.. _fig-zeroweight2:
.. figure:: media/scolv_zeroweight2.png
:align: center
:width: 10cm
Event tab in *scolv* showing the origins from the pipelines for local and
teleseismic monitoring. The preferred origin located near the Solomon
Islands is shown in bold on top. Fake origins in Europe located by pipeline
for local monitoring based on PKP phases falsely considered P phases are
associated to the event but do not form the preferred origin at any time.
.. _scanloc-example:
Real-Time Applications
======================
- Run *scanloc* during real-time processing:
.. code-block:: sh
seiscomp start scanloc
- Run *scanloc* on the command line for real-time processing or message-based
playbacks with debugging output:
.. code-block:: sh
scanloc --debug
Playbacks
=========
Playbacks are used to process waveforms or other data on demand as in real time
or non-real time, with or without connection to the |scname| messaging. Objects
like picks and origins may be provided to scanloc by XML files or through the
messaging.
In playbacks of picks in XML files the performance of scanloc may differ
from real-time operation based on messaging:
* In real-time operation, the picks are made e.g., by :program:`scautopick` at
some time and considered by scanloc according to
their creation times. Delayed picks may become irrelevant for the processing.
Configure :confval:`buffer.pickKeep` and :confval:`buffer.originKeep` accordingly.
However, the **creation times of picks and origins may be obscured** when
created in a non-real-time playback or manually. Objects from non-real-time
playbacks may have almost identical creation times independent of their object
times (pick time, origin time, etc.).
* :ref:`In message-based playbacks <sec-scanloc-rt-playbacks>`, picks and
origins are provided to scanloc via the messaging system. When created in real
time, the **creation times** of these objects form a
realistic time reference for scanloc and should therefore considered using
:option:`--timing`.
* :ref:`In non-real-time XML playbacks <sec-scanloc-xml-playbacks>`
(:option:`--ep`), scanloc considers picks and origins by default according to
their actual **times**.
For objects created in a non-real-time playback object times are most
reasonable as creation time is not a valid time reference anymore.
**However, referencing to object time may result in a behavior which is
different from real-time conditions.**
Therefore, for mimicking real-time conditions in playbacks of objects obtained
in real-time conditions consider the command-line option
:option:`--timing` with *creationTime*.
.. _sec-scanloc-rt-playbacks:
Real-time playbacks
-------------------
Message-based real-time playbacks are useful to test the behavior of scanloc in
real time based on objects like :term:`Picks`, :term:`Origins` and/or
:term:`Amplitudes` generated before by picking/processing:
* **Real time** where the order of the objects is represented by their
creation time.
* **Non-real time**, e.g. manually or by playbacks at high speed. In these cases
creation time is not a useful measure of the timing in real time.
Real-time playbacks are supported by
:ref:`auxiliary scripts <sec-scanloc-aux-tools>` shipped with the scanloc
package.
- **Objects from real-time picking/processing:** Obtain phase picks and origins
obtained in real-time and play them back using :program:`dump_picks`.
Amplitudes are useful if other modules such as :cite:t:`scautoloc`,
:cite:t:`scamp` or :cite:t:`scmag` are involved as well.
**Procedure:**
#. Read picks, origins and amplitudes from the database and store them as
:term:`SCML` in a file, :file:`picks.xml`, for later playbacks. Additional
command-line options may be used to confine the retrieval:
.. code-block:: sh
dump_picks -d [database] -t "2022-04-01 08:00:00.00~2022-04-01 08:05:00.00" -o objects.xml
.. hint::
:program:`dump_picks` allows playing back the objects at high speed by
:option:`--speed` and jumping in time by ::option:`-j`.
#. Play back all objects sending them to the |scname| messaging. Start
*scanloc* separately for debugging on the command line **considering
default timing** by creation time of all objects. When done, send all
objects to the messaging by :program:`playback_picks`:
.. code-block:: sh
seiscomp stop
seiscomp start scmaster scamp scmag scevent
scanloc --debug
playback_picks picks.xml
- **Picks from playbacks:** Play back picks and amplitudes created by a
non-real-time playback possibly in different
:cite:t:`pipeline` sending them to the SeisComP messaging.
* Picks and amplitudes are created in playbacks by :cite:t:`scautoloc` and
stored in XML files (:term:`SCML` format).
* Picks and amplitudes are sent specifically to the message groups PICK, L1PICK
and AMPLITUDE.
* *scanloc* and *l1scanloc* listen to picks from PICK and L1PICKS, respectively.
* :cite:t:`scautoloc` additionally needs the pick amplitudes from the
subscribed amplitude groups.
**Procedure:**
#. Create the XML files by :cite:t:`scautopick` including picks and
amplitudes in a non-real-time playback by the modules as in your 2-pipeline
system. Since picks and amplitudes are created by the playback, their
creation times are not a relevant measure of the order in which they were
created.
.. code-block:: sh
scautopick -d [database] --ep --playback -I [your_waveforms] > picks.xml
l1autopick -d [database] --ep --playback -I [your_waveforms] > l1picks.xml
#. Start all required modules including the scanloc instances
.. code-block:: sh
seiscomp start scmaster scamp scmag scevent scautoloc l1autoloc scanloc l1scanloc
#. Execute :ref:`playback_picks <sec-scanloc-playback_picks>` with
:option:`--timing pickTime` for sending the picks and
amplitudes created by different pickers at different times.
**Consider timing by pick time of the picks:**
:option:`--timing pickTime` is used as an approixmation of the timing since
creation time is not meaningful in this XML playback.
.. code-block:: sh
playback_picks picks.xml:PICK:AMPLITUDE l1picks.xml:L1PICK:AMPLITUDE --timing pickTime
.. _sec-scanloc-xml-playbacks:
Non-real-time playbacks
-----------------------
Non-real-time (:option:`--ep`) playbacks are used for very fast processing of
picks and origins which are provided in XML files (:term:`SCML` format).
The objects were generated before in
* Real time and read from the database e.g., by
:ref:`dump_picks <sec-scanloc-dump_picks>` or
* By non-real-time playbacks, e.g., involving :cite:t:`scautopick`.
* Manually by :cite:t:`scolv`, :cite:t:`lambda`, etc.
In such playbacks, all objects are provided to scanloc
in an XML file with the option :option:`--ep`.
scanloc writes the results in :term:`SCML` to stdout which can be re-directed
into another file for further processing.
.. note::
Execute scanloc always with the appropriate timing.
When picks are created in a non-real-time playback use scanloc with timing
by pick time corresponding to :option:`--timing pickTime` which is the default in
playbacks. For picks obtained
in real time you should use scanloc with the command-line option
:option:`--timing creationTime` for setting the timing to creation time.
* Play back picks stored in XML format to locate events and to determined
the magnitude. Intermediate results are stored in XML files.
Inventory and bindings configuration are read from the database.
The playback is independent of the messaging. Execute scanloc with the
appropriate timing.
**Procedure:**
#. Run the playback
.. code-block:: sh
scautopick -d [database] --ep --playback -I [your_waveforms]> picks.xml
scanloc -d [database] --ep picks.xml --timing [timing] > origins.xml
scamp -d [database] --ep origins.xml -I [your_waveforms] > amps.xml
scmag -d [database] --ep amps.xml > mags.xml
scevent -d [database] --ep mags.xml > events.xml
You may jointly process picks from multiple instances of phase detectors
which are executed first. The picks and origins are provided to scanloc
after merging the XML files. Example:
.. code-block:: sh
scautopick -d [database] --ep --playback -I [your_waveforms] > picks_sp.xml
dlpick -d [database] --ep --playback -I [your_waveforms] > picks_dl.xml
ccloc -d [database] --offline --ep -I [your_waveforms] > picks_origins_ccloc.xml
autothor -d [database] --offline --ep -I [your_waveforms] > picks_origins_autothor.xml
scxmlmerge picks_sp.xml picks_dl.xml picks_origins_ccloc.xml picks_origins_autothor.xml > objects.xml
scanloc -d [database] --ep objects.xml --timing [timing] > origins.xml
scamp -d [database] --ep origins.xml -I [your_waveforms] > amps.xml
scmag -d [database] --ep amps.xml > mags.xml
scevent -d [database] --ep mags.xml > events.xml
#. Enter the results into the SeisComP system. Either:
* **Preferred: Events may exist** in the database.
Update existing events by associating new origins or create new events.
Run the messaging system and all
modules that shall process the new parameters, e.g.
:cite:t:`scamp`, :cite:t:`scmag` , :cite:t:`scevent`.
Use :cite:t:`scdispatch` to send the new objects to
the messaging system.
.. code-block:: sh
seiscomp start scmaster scamp scmag scevent
scdispatch -H host -i mags.xml
Instead of the :file:`mags.xml`, other parameters created by the
playback may be dispatched, e.g., from :file:`origins.xml`. Use
:cite:t:`scdispatch` with *-e* to ultimately prevent sending event
objects.
* **Events do not exist** in the database, use :cite:t:`scdb` to populate
the database with all events in :file:`events.xml`.
.. code-block:: sh
scdb -i events.xml -d [database]
.. warning::
Using :cite:t:`scdb` for writing event information to the database may
result in duplicates if the provided parameters, e.g., events, exist already
with another ID. In this case use :cite:t:`scdispatch` with :file:`mags.xml`
and running :cite:t:`scmaster` and :cite:t:`scevent`
instead of :cite:t:`scdb`. However, *scdispatch* in newer versions of
SeisComP allows ignoring Event objects with the option ``-e``. Then, also
:file:`events.xml` can be dispatched.
* Play back picks stored in XML format, without a database but inventory and
bindings in :term:`SCML` and with a local file for module configuration.
**Procedure:**
#. Set up a local module configuration file, e.g., :file:`./scanloc.cfg`
containing all parameters including :confval:`core.plugins`.
#. Store the station inventory and the binding configuration from a database
in :term:`SCML`:
.. code-block:: sh
scxmldump -d [database] -fI -o inventory.xml
scxmldump -d [database] -fC -o config.xml
#. Continue with the examples above replacing the database parameter
:option:`-d [database]` with :option:`--inventory-db inventory.xml`
:option:`--config-db config.xml`
and adding the module configuration in :file:`scanloc.cfg`. Set the timing
accordingly:
.. code-block:: sh
scanloc --inventory-db inventory.xml --config-db config.xml \
--ep picks.xml --timing [timing] \
--config-file scanloc.cfg > origins.xml
Module Configuration
====================
| :file:`etc/defaults/global.cfg`
| :file:`etc/defaults/scanloc.cfg`
| :file:`etc/global.cfg`
| :file:`etc/scanloc.cfg`
| :file:`~/.seiscomp/global.cfg`
| :file:`~/.seiscomp/scanloc.cfg`
scanloc inherits :ref:`global options<global-configuration>`.
.. note::
Modules/plugins may require a license file. The default path to license
files is :file:`@DATADIR@/licenses/` which can be overridden by global
configuration of the parameter :confval:`gempa.licensePath`. Example: ::
gempa.licensePath = @CONFIGDIR@/licenses
.. confval:: defaultDepth
Default: ``0.0``
Unit: *km*
Type: *double*
Default source depth used for locating origins. The range of
supported values depends on the configured
travel\-time interface and locator.
When origin depth after locating is 0.0 or undefined, the depth
is corrected to \"defaultDepth\" without relocating
since the situation indicates issues.
Note: A similar parameter may require configuration for score
plugins.
.. confval:: ignoreDepth
Default: ``650.0``
Unit: *km*
Type: *double*
Maximum depth of an origin to be sent.
Note: A similar parameter may require configuration for score
plugins.
.. confval:: use3D
Default: ``false``
Type: *boolean*
Compute distances in 3D for cluster search,
phase association and internal event association. Otherwise,
distances are measured from geographic coordinates ignoring elevation.
.. confval:: maxRMS
Default: ``1.5``
Unit: *s*
Type: *double*
Maximum allowed overall residual of an origin to be sent.
.. confval:: minScore
Default: ``0.0``
Type: *double*
Minimum score of an origin to be sent.
.. confval:: score
Default: ``OriginSum``
Type: *string*
Values: ``OriginSum,OriginMultiFeature``
Defines the score processor to be used for ranking origins of
events. Additional configuration of the plugin and the plugin
parameters is required.
.. confval:: pickComparisonLevel
Default: ``loc``
Type: *string*
Values: ``sta,loc,cha``
The level up to which compare stream IDs of multiple picks in
order to avoid origins with multiple picks from identical stream
level, e.g., station \(sta\), sensor location \(loc\) or channel
\(cha\).
The level is derived from the NET.STA.LOC.CHA stream
representation. Picks with equal stream IDs on the given level
are treated as originating from the same stream no matter of the
ID on a lower level. Clusters having picks on streams equal on
the given level are split into new clusters with unique streams.
During association picks equal on the given level are ignored \-
the first assigned pick is considered.
.. _buffer:
.. note::
**buffer.\***
*Define buffering of picks and origins. scanloc only treats picks*
*and origins kept in the buffer.*
.. confval:: buffer.pickKeep
Default: ``180.0``
Unit: *s*
Type: *double*
Time to keep picks. Time comparison is based on the pick
times. In non\-real time playbacks the time to keep picks is
usually compressed.
.. confval:: buffer.pickIgnoreStreamID
Type: *list:string*
Ignore picks created on given stream ID\(s\). Stream IDs may
contain wildcards. Separate multiple IDs by comma.
.. confval:: buffer.ignorePickTimeDifference
Default: ``0.0``
Unit: *s*
Type: *double*
Generally, all available picks are added to the buffer and
made available for processing. Use this option to ignore new
picks made on the same data stream within the given time
difference to a previously buffered pick. A value of 0.0 s
ignores all picks with identical times.
.. confval:: buffer.originKeep
Default: ``180.0``
Unit: *s*
Type: *double*
Time to keep origins. Time comparison is based on the origin
times. In non\-real time playbacks the time to keep orgins is
usually compressed.
.. confval:: buffer.ignoreOrigins
Default: ``false``
Type: *boolean*
Ignore and do not buffer external origins received from
messaging or from XML files.
Default: Accept external origins from messaging or XML and
associate more phases.
.. confval:: buffer.ignoreManualOrigins
Default: ``true``
Type: *boolean*
Ignore and do not buffer manual external origins received
from messaging or from XML files.
The parameter \"buffer.ignoreOrigins\" must be
inactive for this option to be effective.
.. confval:: buffer.originStatusIgnore
Type: *list:string*
Values: ``rejected,reported,preliminary,confirmed,reviewed,final``
Ignore an external origin if its status has any of the given
states. The option is ignored for manual origins if
buffer.ignoreManualOrigins \= false.
.. confval:: buffer.authorWhiteList
Type: *list:string*
Only buffer picks or origins from the given authors.
Separate multiple authors by comma. Picks and origins from
other authors will be ignored. Wildcards are supported.
This parameter overrides
\"buffer.originAuthorWhiteList\". Manual origins are
treated regardless of the author as defined by
\"buffer.ignoreManualOrigins\".
The parameter allows operation of scanloc based on picks and
origins from a specific module, e.g., in a pipeline.
.. confval:: buffer.originAuthorWhiteList
Type: *list:string*
Deprecated parameter which will be removed in 2025. Use
\"buffer.authorWhiteList\" instead which overrides
this parameter\!
Only buffer external origins from the given authors to the.
Separate multiple authors by comma. Manual origins
are treated regardless of the author as defined by
\"buffer.ignoreManualOrigins\".
The parameter \"buffer.ignoreOrigins\" must be
inactive for this option to be effective.
.. confval:: buffer.futureTimeDelta
Default: ``0.0``
Unit: *s*
Type: *double*
The time delta to the future. Positive values allow objects
with times in the future to be buffered when the difference
to current time or to creation time is not larger than the
given value.
Normally, objects like picks and origins are created after
their actual times and all other objects are spurious and
should be ignored. In case of wrong sensor timing or
faster\-than\-real\-time waveform playbacks, objects may be
generated with actual times \(pick time or origin time\) in
the future.
If less or equal to 0.0, then all objects created before
time of the object or with object times in the future are
ignored.
.. _clusterSearch:
.. note::
**clusterSearch.\***
*Parameters controlling the cluster search based on phase*
*picks of configured phase type.*
.. confval:: clusterSearch.phaseType
Default: ``P``
Type: *string*
Phase type of considered picks. Valid types: P or Is.
.. confval:: clusterSearch.minSize
Default: ``4``
Type: *int*
Minimum number of core points \(picks\) to form a cluster.
.. confval:: clusterSearch.maxSize
Default: ``-1``
Type: *int*
Maximum number of picks in a cluster when stopping
clustering. Eventual clusters may still be larger from core
points. Using values < 0 deactivates the feature.
The parameter is meant to support large\-N networks where the
high network density results in very many clusters with high
computational load effectively slowing down the processing
of picks. Using reasonable values such as 10 or 15 will
reduce the number of clusters while maintaining high quality
initial origins.
.. confval:: clusterSearch.maxPickDelay
Default: ``-1.0``
Unit: *s*
Type: *double*
Maximum allowed difference between considered picks and cluster reference
time \(latest pick time\). Optimum values can be derived from
travel times.The cluster search ignores all
picks which exceed the value. Using \"\-1\" enables all picks
regardless of the delay.
.. confval:: clusterSearch.referenceTimeMode
Default: ``LastPick``
Type: *string*
Values: ``LastPick,MaxPickDelay``
Mode to set the cluster reference time. Read the documentation
for the details. Available modes:
LastPick: The pick time of the last incoming P pick is the
cluster reference time.
MaxPickDelay: Setting the cluster reference time is delayed
until clusterSearch.minSize and association.minPhase picks
are available.
.. confval:: clusterSearch.regionFilter
Type: *list:double*
Cluster only picks which sensor locations are inside
the defined region. The region is defined by latitude,
longitude and a radius in km. By default the region filter
is disabled.
Example: 50.1,12.3,20
.. confval:: clusterSearch.averageVelocity
Default: ``7.0``
Unit: *km/s*
Type: *double*
Average velocity used for distance calculation.
.. confval:: clusterSearch.maxSearchDist
Default: ``60``
Unit: *s*
Type: *double*
Maximum allowed distance over all core points and
maximum allowed distance for neighborhood search. Both account
for travel\-time difference, inter\-station distance and the
configured averageVelocity.
.. confval:: clusterSearch.maxOrigins
Default: ``128``
Type: *uint*
Maximum allowed origins derived from cluster search. Set this
option to zero to disable the cluster search completely.
.. confval:: clusterSearch.preliminary
Default: ``false``
Type: *boolean*
Send origins based on cluster search as preliminary origins
if the location fails. Otherwise those origins are ignored.
Consider activating \"checkOrigins\".
.. confval:: clusterSearch.checkOrigins
Default: ``false``
Type: *boolean*
Check, if derived origins fulfill the cluster search criteria
anymore. Activating this option may lower the number of events
and suppress fake events.
.. _association:
.. note::
**association.\***
*Parameters controlling the association of P and S phases to cluster*
*origins or external origins.*
.. confval:: association.minPhase
Default: ``4``
Type: *int*
Number picks in cluster origin to be reached for starting to
associate more P and S picks.
.. confval:: association.maxDist
Default: ``1000.0``
Unit: *km*
Type: *double*
Maximum distance from origin to stations
for associating P and S picks.
.. confval:: association.stationConfig
Type: *file*
The station configuration file contains lines consisting of
network code, station code, weight \(0 or 1\) and maximum
association distance given in degree. The maximum association
distance is the distance in degrees from the origin up to
which this station may contribute to a new origin. This
parameter overrides the global parameter
\"association.maxDist\".
If this distance is 180 deg, this station may contribute to
new origins world\-wide. However, if the distance is only 10
degree, the range of this station is limited. This is a helpful
setting in case of mediocre stations in a region where there
are numerous good and reliable stations nearby. The station
will then not pose a risk for locations generated
outside the maximum association distance. The last item found
in the list overrules previous ones.
Network and station codes may be wildcards \(\*\) for
convenience. Example:
\* \* 1 10
GE \* 1 180
.. confval:: association.maxPResidual
Default: ``4.0``
Unit: *s*
Type: *double*
Maximum allowed difference between measured and predicted arrival
times for associating P phases to origin.
Larger values allow significant correction of initial locations.
.. confval:: association.dropReferenceCheck
Default: ``false``
Type: *boolean*
Allow S\-type picks without checking for a reference pick.
References to P picks are typically added to S picks by
scautopick but picks from other modules may not have this
feature. When this option is active, the reference pick is
not tested at all. Manual picks are always considered
without a reference check.
.. confval:: association.maxSResidual
Default: ``4.0``
Unit: *s*
Type: *double*
Maximum allowed difference between measured and predicted arrival
time for associating S phases to origins. Larger values allow
significant correction of initial locations.
.. confval:: association.maxResidual
Default: ``2.0``
Unit: *s*
Type: *double*
Maximum allowed time residuals of picks after association and
relocation. Picks will be removed at exceedence starting with
largest residual and origins will be relocated.
.. confval:: association.arrivalCountMinRes
Default: ``-1``
Type: *int*
The number of arrivals of an origin for controlling the
association of more picks. Beyond this number, the minimum
of maxPResidual or maxSResidual and maxResidual for
associating P or S phases, respectively, is tested before
association.
The parameter also speeds up the evaluation of origins with
more arrivals than configured: Instead of
testing residuals of arrivals individually and relocating
thereafter, all arrivals not passing the residual check are
removed in a bulk.
The parameter is meant to support large\-N networks where the
high network density results in very many picks and high
computational load, effectively slowing down the quality
check of picks. Setting a reasonable value, e.g., >20 will
only associate the best picks to origins already well
constraint.
Using values <\= 0 deactivates the feature.
.. confval:: association.tableType
Default: ``LOCSAT``
Type: *string*
Values: ``LOCSAT,libtau,homogeneous``
Type of travel\-time tables for phase association.
May be different from locator.
.. confval:: association.table
Default: ``iasp91``
Type: *string*
Values: ``iasp91,iasp91_scanloc``
Name of travel\-time table used for phase association.
May be different from locator profile. Using a different
table\/profile may result in increased runtime.
.. confval:: association.zeroWeightProfiles
Type: *list:string*
zeroWeight\-profile name for associating the configured phases
with zero weight to origins. Multiples profile names may be set
separated by comma. The order of names determines order of
checked phases. Each profile can have different parameters.
.. _association.zeroWeight:
.. note::
**association.zeroWeight.\***
*Zero-weight profiles containing the parameters for associating*
*phases with zero weight to origins.*
.. _association.zeroWeight.$name:
.. note::
**association.zeroWeight.$name.\***
$name is a placeholder for the name to be used and needs to be added to :confval:`zeroWeight.profiles` to become active.
.. code-block:: sh
zeroWeight.profiles = a,b
association.zeroWeight.a.value1 = ...
association.zeroWeight.b.value1 = ...
# c is not active because it has not been added
# to the list of zeroWeight.profiles
association.zeroWeight.c.value1 = ...
.. confval:: association.zeroWeight.$name.phaseType
Type: *String*
One phase type to be associated with zero weight.
Examples: PKP or Pdiff.
.. confval:: association.zeroWeight.$name.minDistance
Default: ``120.0``
Unit: *degree*
Type: *double*
Minimum distance from origin to stations.
.. confval:: association.zeroWeight.$name.maxResidual
Default: ``5.0``
Unit: *s*
Type: *double*
Maximum time residual of the associated phase.
.. _locator:
.. note::
**locator.\***
*Parameters controlling the locator for locating scanloc*
*origins.*
.. confval:: locator.type
Default: ``LOCSAT``
Type: *string*
Values: ``External,FixedHypocenter,Hypo71,iLoc,LOCSAT,NonLinLoc,Router,StdLoc``
The locator type to be used.
.. confval:: locator.profile
Default: ``iasp91``
Type: *string*
Values: ``iasp91,iasp91_scanloc``
The locator profile to be used. Using a different profile\/table
for locating and associating may result in increased runtime.
.. confval:: locator.fixDepth
Default: ``false``
Type: *boolean*
If enabled, the locator fixes the depth to the configured
default value \"defaultDepth\" in case that all
previous attempts to relocate fail.
This option may result in many more origins. It
prevents \"ignoreDepth\" from beeing
effective if \"defaultDepth\" < \"ignoreDepth\".
.. confval:: locator.forceFixDepth
Default: ``false``
Type: *boolean*
If enabled, the locator is forced to fix the depth to the
value configured by \"defaultDepth\". Free\-depth
solutions are thus excluded. Activating this option may be
useful for sources with known depths or in case of sparse
networks.
.. _eventAssociation:
.. note::
**eventAssociation.\***
*Parameters controlling the association of interval scanloc*
*origins to internal scanloc events.*
.. confval:: eventAssociation.compareAllArrivalTimes
Default: ``false``
Type: *boolean*
This parameter is only used in conjunction with
\"eventAssociation.maximumMatchingArrivalTimeDiff\".
If a station has multiple associated arrivals for a
particular event, this flag defines if the time distance
of a new pick to all arrivals must be within
\"eventAssociation.maximumMatchingArrivalTimeDiff\"
or if one matching arrival is enough.
.. confval:: eventAssociation.minMatchingArrivals
Default: ``3``
Type: *int*
Minimum number of matching picks between two origins to be
associated to the same event.
.. confval:: eventAssociation.maxMatchingArrivalTimeDiff
Default: ``-1``
Unit: *s*
Type: *double*
If this time window in seconds is negative, pickIDs
are compared to find matching arrivals. A non negative
value \(including 0\) compares pick times regardless
of the pickID. Pass: \|pick1.time \- pick2.time\| <\= threshold.
.. confval:: eventAssociation.maxDist
Default: ``500.0``
Unit: *km*
Type: *double*
Allowed difference in epicenter between an incoming origin
compared with preferred origins to get associated.
.. confval:: eventAssociation.maxTimeSpan
Default: ``60.0``
Unit: *s*
Type: *double*
Associates an origin with an existing event if the origin
time differs not more than 60 seconds unless the
minimumMatchingArrivals criteria matches.
.. _publication:
.. note::
**publication.\***
*Parameters controlling the publication delay of origin for*
*internal events to the messaging system. The delay*
*time, t, is calculated as t = a x N + b where N is the number*
*of arrivals of the origin. After t seconds, the best origin*
*is published. The first origin is always published.*
.. confval:: publication.intervalTimeSlope
Default: ``0.5``
Unit: *s/count*
Type: *double*
Parameter \"a\" in the equation t \= a x N + b.
Increasing the value reduces the amount of sent origins.
With the option \-\-ep \(playback mode\) this value is set to 0.
.. confval:: publication.intervalTimeIntercept
Default: ``0.0``
Unit: *s*
Type: *double*
Parameter \"b\" in the equation t \= a x N + b.
Increasing the value reduces the amount of sent origins.
With the option \-\-ep \(playback mode\) this value is set to 0.
.. confval:: publication.wakeUpInterval
Default: ``5``
Unit: *s*
Type: *int*
Integer interval to check the origin buffer for sending
origins if no other origins have been created.
Reducing the value may be required in EEW: it increases the
load on scanloc but allows to send origins more rapidly.
.. _scanloc/ScoreMF:
ScoreMF plugin
--------------
Plugin for computing a score for an origin by the OriginMultiFeature
score processor.
.. _score:
.. note::
**score.\***
*Origin score processor "OriginMultiFeature" returning a score*
*for an origin as a measure of goodness. The score is*
*then compared against minScore. Requires to configure*
*the global parameter *plugins* with "scoremf" in order to*
*load this gempa plugin and to set *minScore* and *score**
*accordingly.*
.. _score.mf:
.. confval:: score.mf.defaultScore
Default: ``0.0``
Type: *double*
The default score returned for an origin that fails
completely or is filtered out by thresholds such as for
depth and RMS.
.. confval:: score.mf.strongMotionCodes
Default: ``L,N``
Type: *list:string*
List of one\-letter instrument codes \(2nd letter\) in
channel codes identifying strong motion sensors, e.g.,
in HL?, HN?.
.. confval:: score.mf.infrasoundCodes
Default: ``D``
Type: *list:string*
List of one\-letter instrument codes \(2nd letter\) in
channel codes identifying infrasound sensors, e.g., in
HDF.
.. _score.mf.weights:
.. confval:: score.mf.weights.p
Default: ``1.0,0.0,0.0``
Type: *list:double*
The weight for number of used P arrival measures.
Assumes only arrival time when exactly 1 value is set.
Use a comma\-separated list, wT,wSlo,wBaz, for giving
specific weight to pick time, slowness and back azimuth,
respectively.
Example: 1.0,0.0,0.0 .
.. confval:: score.mf.weights.p0
Default: ``0.5``
Type: *double*
Weight per unused P pick.
.. confval:: score.mf.weights.s
Default: ``2.0``
Type: *double*
Weight per used S pick.
.. confval:: score.mf.weights.s0
Default: ``0.5``
Type: *double*
Weight per unused S pick.
.. confval:: score.mf.weights.normalizationDepth
Default: ``650.0``
Type: *double*
Origin depth is normalized to this value for
computing the score contribution. Shallower depths
contribute to larger score.
This is also the maximum allowed depth. Origins with
depth greater then this value get a score equal to
\"defaultScore\".
.. confval:: score.mf.weights.depth
Default: ``1.0``
Type: *double*
Weight for depth\-based quality score.
.. confval:: score.mf.weights.normalizationRMS
Default: ``1.5``
Type: *double*
Origin RMS is normalized to this value for computing
the score contribution. Lower RMS contribute to
larger score.
This is also the maximum allowed RMS. Origins with
residual greater than this value score equal to
\"defaultScore\".
.. confval:: score.mf.weights.residual
Default: ``1.0``
Type: *double*
Weight for RMS\-based quality score.
.. confval:: score.mf.weights.gap
Default: ``1.0``
Type: *double*
Weight for azimuthal gap score. The smaller the gap
the larger the score.
.. confval:: score.mf.weights.manualPick
Default: ``0.5``
Type: *double*
Weight per used manual pick.
.. confval:: score.mf.weights.strongMotion
Default: ``0.0``
Type: *double*
Weight per used strong motion pick as defined in
\"strongMotionCodes\".
.. confval:: score.mf.weights.infrasound
Default: ``0.0``
Type: *double*
Weight per used infrasound pick as defined in
\"infrasoundCodes\".
.. confval:: score.mf.weights.authors
Unit: *author:score*
Type: *list:string*
List of tuple of authors and score contribution.
If an author matches, the corresponding score
contribution is added to the final score.
Example: \"scautoloc:1,scanloc:10,ccloc:100\".
.. _scanloc/ScoreSum:
ScoreSum plugin
---------------
Plugin for scoring origins in scanloc by score processor OriginSum
.. _score:
.. _score.sum:
.. note::
**score.sum.\***
*Origin score processor "OriginSum": Compute origin scores as*
*weighted averages of number of used*
*P phases (p), number of unused P phases (p0), number of used*
*S phases (s), number of unused S phases (s0), origin depth and*
*residual. The score applies for ranking origins of events. Add*
*the plugin "scoresum" to the global parameter "plugins" and*
*"OriginSum" to the scanloc parameter "score" for applying this*
*score processor.*
.. confval:: score.sum.p
Default: ``1.0``
Type: *list:double*
The weight for number of used P arrival measures.
Assumes only arrival time when exactly 1 value is set.
Use a comma\-separated list, wT,wSlo,wBaz, for giving
specific weight to pick time, slowness and back azimuth,
respectively.
Example: 1.0,0.0,0.0 .
The usage of slowness and back azimuth depends on locator.
They are not considered by Hypo71, NonLinLoc, StdLoc and
FixedHypocenter.
The parameter is used for Is infrasound phases when
considered in clustering.
.. confval:: score.sum.p0
Default: ``0.5``
Type: *double*
The weight for number of added but unused P arrivals.
The parameter is used for Is infrasound phases when
considered in clustering.
.. confval:: score.sum.s
Default: ``2.0``
Type: *list:double*
The weight for number of used S arrival measures.
Assumes only arrival time when exactly 1 value is set.
Use a comma\-separated list, wT,wSlo,wBaz, for giving
specific weight to pick time, slowness and back azimuth,
respectively.
Example: 2.0,0.0,0.0 .
The usage of slowness and back azimuth depends on locator.
They are not considered by Hypo71, NonLinLoc, StdLoc and
FixedHypocenter.
.. confval:: score.sum.s0
Default: ``0.5``
Type: *double*
The weight for number of added but unused S arrivals.
.. confval:: score.sum.normalizationDepth
Default: ``650.0``
Unit: *km*
Type: *double*
Origin depth is normalized to this value for computing the
score contribution. Shallower depths contribute to larger
score.
.. confval:: score.sum.depth
Default: ``1.0``
Type: *double*
The weight of origin depth. Set this value to 0.0 for
scoring origins independent of depth whenever shallow and
deep sources are equally expected.
.. confval:: score.sum.normalizationRMS
Default: ``1.5``
Unit: *s*
Type: *double*
Origin RMS is normalized to this value for computing the
score contribution. Lower RMS contribute to larger score.
.. confval:: score.sum.residual
Default: ``1.0``
Type: *double*
The weight of origin RMS residual.
.. confval:: score.sum.increaseManual
Default: ``false``
Type: *boolean*
Increase the weight for manual picks by a factor of 1.001.
This gives preference to manual picks in case
automatic ones co\-exist for the same station.
Command-Line Options
====================
:program:`scanloc [options]`
.. _Generic:
Generic
-------
.. option:: -h, --help
Show help message.
.. option:: -V, --version
Show version information.
.. option:: --config-file arg
Use alternative configuration file. When this option is
used the loading of all stages is disabled. Only the
given configuration file is parsed and used. To use
another name for the configuration create a symbolic
link of the application or copy it. Example:
scautopick \-> scautopick2.
.. option:: --plugins arg
Load given plugins.
.. option:: -D, --daemon
Run as daemon. This means the application will fork itself
and doesn't need to be started with \&.
.. _Verbosity:
Verbosity
---------
.. option:: --verbosity arg
Verbosity level [0..4]. 0:quiet, 1:error, 2:warning, 3:info,
4:debug.
.. option:: -v, --v
Increase verbosity level \(may be repeated, eg. \-vv\).
.. option:: -q, --quiet
Quiet mode: no logging output.
.. option:: --print-component arg
For each log entry print the component right after the
log level. By default the component output is enabled
for file output but disabled for console output.
.. option:: --component arg
Limit the logging to a certain component. This option can
be given more than once.
.. option:: -s, --syslog
Use syslog logging backend. The output usually goes to
\/var\/lib\/messages.
.. option:: -l, --lockfile arg
Path to lock file.
.. option:: --console arg
Send log output to stdout.
.. option:: --debug
Execute in debug mode.
Equivalent to \-\-verbosity\=4 \-\-console\=1 .
.. option:: --trace
Execute in trace mode.
Equivalent to \-\-verbosity\=4 \-\-console\=1 \-\-print\-component\=1
\-\-print\-context\=1 .
.. option:: --log-file arg
Use alternative log file.
.. _Messaging:
Messaging
---------
.. option:: -u, --user arg
Overrides configuration parameter :confval:`connection.username`.
.. option:: -H, --host arg
Overrides configuration parameter :confval:`connection.server`.
.. option:: -t, --timeout arg
Overrides configuration parameter :confval:`connection.timeout`.
.. option:: -g, --primary-group arg
Overrides configuration parameter :confval:`connection.primaryGroup`.
.. option:: -S, --subscribe-group arg
A group to subscribe to.
This option can be given more than once.
.. option:: --start-stop-msg arg
Default: ``0``
Set sending of a start and a stop message.
.. _Database:
Database
--------
.. option:: --db-driver-list
List all supported database drivers.
.. option:: -d, --database arg
The database connection string, format:
service:\/\/user:pwd\@host\/database.
\"service\" is the name of the database driver which
can be queried with \"\-\-db\-driver\-list\".
.. option:: --config-module arg
The config module to use.
.. option:: --inventory-db arg
Load the inventory from the given database or file, format:
[service:\/\/]location .
.. option:: --db-disable
Do not use the database at all.
.. _Input:
Input
-----
.. option:: --ep arg
Type: *string*
Name of input XML file \(SCML\) with all picks and origins
for offline processing. The database connection is not
received from messaging and must be provided. Results
are sent as XML to stdout.
.. option:: --timing arg
Default: ``pickTime``
Values: ``creationTime,pickTime``
Timing reference in offline processing with \-\-ep: Use
pickTime and creationTime for sorting picks according to
pick time and creation time, respectively. pickTime is
assumed if no timing is specified. Note: In real\-time
processing picks are treated as they arrive corresponding to
creationTime and this option is irrelevant.
.. _Buffer:
Buffer
------
.. option:: --allow-rejected-picks
Allow processing of picks with evaluation status 'rejected'.
Otherwise these picks are ignored and not buffered.
.. option:: --drop-reference-check
Overrides configuration parameter :confval:`association.dropReferenceCheck`.
.. option:: --author-whitelist arg
Type: *list:string*
Only consider picks and origins created by the given
author\(s\). Separate multiple authors by
comma. Wildcards are supported.Empty strings
allow all authors. Manual origins are treated regardless of
the author as defined by
\"buffer.ignoreManualOrigins\". The option allows
operating scanloc based on picks and origins from a specific
module, e.g., in a pipeline.
.. option:: --future-time-delta arg
Overrides configuration parameter :confval:`buffer.futureTimeDelta`.
.. option:: --origin-keep arg
Overrides configuration parameter :confval:`buffer.originKeep`.
.. option:: --pick-keep arg
Overrides configuration parameter :confval:`buffer.pickKeep`.
.. _Locator:
Locator
-------
.. option:: --locator-type arg
Overrides configuration parameter :confval:`locator.type`.
.. option:: --locator-profile arg
Overrides configuration parameter :confval:`locator.profile`.
Type: *string*
.. option:: --locator-list
List all registered locators.
.. _Output:
Output
------
.. option:: --final-only
Limit result set to final origins only. This option is
available for non\-real\-time \(\-\-ep\) processing only.
.. option:: --dump-origins
Don't publish origins, write them to stdout. Useful for
tuning.
.. option:: --cluster-search-log-file arg
Type: *string*
File name to output detailed cluster search information.
Useful for tuning.
.. option:: -f, --formatted
Use formatted XML output along with '\-\-ep'. Otherwise XML
is unformatted.