scoctoloc

The use of a global associator in scautoloc makes it suitable for locating seismic events world-wide, because it is able to associate events using tricks specifically tuned to work with teleseismic pick data. For smaller networks, when locating seismic events at a regional or even local scale, a lot of what scautoloc does is unneeded and is in fact overkill.

This is where scoctoloc comes into play. It uses the very efficient PyOcto associator, hence the name 'scoctoloc'.

scoctoloc is the scautoloc sibling for small networks of up to approximately 800 km. In fact it is meant to replace scautoloc in regional/local monitoring setups.

Main use cases

There are three main use cases for scoctoloc:

• Real-time (online) mode with pick data arriving via messaging. This is what most users will use scoctoloc for.
• Offline mode with bulk parametric data read either from database or XML. Could be the post-processing of data from a temporary experiment.
• Offline playback mode that simulates real-time behaviour. This is mostly for testing or post mortem analysis in case something went wrong.

Real-time (online) mode

Picks are received as they are sent by the real-time picker. The picker can be the standard SeisComP scautopick or any other picker. We are currently testing it online for a network in northern Chile and it works well.

Invocation can be as simple as

seiscomp exec scoctoloc \
	--center-latlon -22,-70 \
	--pick-authors 'dlpicker' \
	--debug

to use picks generated by 'dlpicker' for a network centered at 22°S, 70°W.

This is work in progress. Many features are missing and some config parameters are still hard coded. Stay tuned.

Offline mode

We need an inventory and the parametric data, both as SeisComP XML files.

An example call might look like this

seiscomp exec scoctoloc \
	--inventory-xml inventory.xml \
	--input-xml gfz2024tdcj.xml \
	--whitelist whitelist.txt \
	--center-latlon -22,-70 \
	--output-xml output.xml \
	--debug

Pretty self-explaining so far. The whitelist contains a list of network and station codes to filter against, in order to only work with a specific subset of the data. The network center latitude and longitude define the projection center of out network.

Playback (real-time simulation) mode

You can try it out like in the offline example above by simply adding the --playback option.

Usage

scoctoloc accepts the generic SeisComP options that control the use of config files, connection to messaging and database, as well ad debugging. These are settings usually found on a SeisComP system in a global.cfg file and are shared by most modules of a SeisComP processing. For example -d, --database, -H, --host, -u, --user etc. Refer to scoctoloc --help and the SeisComP documentation for more information.

Below is a description of the scoctoloc specific parameters.

Config options

--pick-authors arg

specify list of allowed pick authors

--whitelist arg

specify stream whitelist

--center-latlon arg

specify network center lat, lon

--max-distance arg

specify network radius from center lat,lon

--max-depth arg

specify max. hypocenter depth in km

--locator arg

specify locator (default is LOCSAT)

--test

test mode - no results are sent to messaging

--debug-data-dir

specify folder to dump input for debugging in PyOcto (off by default)

--processing-delay

When processing incoming picks immediately, we process them normally in the order of the waves arriving at the stations of our network.
First the P wave at the nearest station, then the P wave at the second-nearest station, perhaps followed by the S wave of the nearest station, then the P wave of the third-nearest station and so on.
In other words we start with very few picks and add picks to the processing as they arrive, which depending on the size of the network may take anywhere from a few seconds to several minutes.
Depending on the number of stations in the network, many origins would be generated if we update the solution for every additional pick associated.
If desired, this is feasible, but it might fill the database with many unneeded origins, which were preferred origins for only a few seconds.
We could as well accept a bit of a delay, collect more picks and process them all at once, resulting in the earliest origins being delayed.

One strategy to control this behaviour is a processing delay.
Picks are buffered for a configurable delay before they are processed, resulting in most if not all picks of an event to be     available at the time of the processing, but also delayed availability of the solutions.

Input options

--input-xml arg

specify input xml file

--inventory-xml arg

specify inventory xml file

--model-csv arg

specify velocity model csv file

--model-const arg

specify P velocity[, S velocity[, density]] as comma-separated values

--start-time arg

specify start time of processing time window

--end-time arg

specify end time of processing time window

Playback options

--playback

Lets scoctoloc run in playback mode. This simulates closely the behaviour of a real-time processing.

--use-pick-time

Normally the pick creation time is used in playbacks.
Sometimes this is not feasible, e.g. if the creation time is not meaningful because the picks were created not by a SeisComP online processing or we want to use manual picks as if they were automatic picks.
We can then use the pick time as playback time.

Output control

--output-xml arg

Specify output xml file. All generated origins will be written in SeisComP XML format.

--pyocto-locations

Include the raw PyOcto locations (before relocation) in the output (both XML and messaging).

Tests

Work in progress.

Issues

• See this issue on Github. This is the reason why we have to import pyrocko.modelling before any SeisComP imports until a better solution is found.
• A lot more configuration options need to be added.