autolambda: Methods

autolambda provides some array methods for automatic data processing which are also available in lambda:

  • Slowness-wavenumber analysis

  • Backprojection

  • PMCC

The configuration of autolambda should be based on the parameters tested and applied in lambda. Some arrays and a basic configuration of the processing is provided with the default confguration. For your own application you need to configure in autolambda.cfg at least:

  • One or more arrays, e.g. GERESS, with all required elements.

  • One or more base profiles for defining common data processing parameters the profile teleseismics

  • One or more profiles for each method to be applied defining the specific parameters.

  • The method-dependent bindings of arrays and profiles

Slowness-wavenumber analysis

autolambda implements the automatic slowness-wavenumber analysis based on F-K analysis or beampacking.

For using the method you need to configure, as a minimum, at least one array with its base and processing profiles in the form array;base profile;slownessgrid profile, e.g.

bindings.slownessgrid = GERESS;tele;tele

Backprojection

autolambda implements the automatic backprojection analysis for detecting and for locating seismic events based on F-K analysis or beampacking.

Currently, only stacking of filtered waveforms along the travel-time curves of P or S phases is supported. The computation of other characteristic functions and stacking along multiple travel-time curves is planned.

For using the method you need to configure, as a minimum, at least one array with its base and processing profiles in the form array;base profile;backprojection profile, e.g.

bindings.backprojection = GERESS;local;local

PMCC

autolambda implements the automatic PMCC analysis.

For using the method you need to configure, as a minimum, at least one array with its base and processing profiles in the form array;base profile;pmcc profile, e.g.

bindings.pmcc = GERESS;tele;tele

Modes of Operation

Daemon mode

autolambda can be operated in message daemon mode running constantly in the background. For the deamon mode autolambda must be started. For automatic startup it must be enabled:

seiscomp enable autolambda
seiscomp start autolambda

On demand

autolambda can be operated on demand and executed in

  • Message-based mode to process real-time or non-real-time data. The results from autolambda, e.g. picks and origins, will be sent to the messaging system where they are accessible to the connected modules for further processing.

    Examples:

    1. Run autolambda on the command line with the given module configrationion of the system but print descriptive debug output:

      autolambda --debug

    2. Run autolambda with data from a miniSEED file. All runtime information are printed to the terminal:

      autolambda -I [data input by RecordStream] -H [messaging host] --console=1

  • Offline mode to process non-real-time data without connection to the messaging. The data are typically sent to an XML file or to standard output. Read the section Offline data processing for more details and examples.

Playbacks

Playbacks may be used to process a particular set of data as in real-time operation of as fast as prossible.

Message-based data processing

Data may be proceessed on demand in message-based non-real-time operation. The results are automatically sent to the messaging system.

  • Reference time: Consider that the other modules which shall receive picks and origins, e.g. scanloc [7], scautoloc [8], scamp [6], scmag [11] or scevent [10] must also be able to process these objects. For currently close stations or stations with changed inventory, additionally set the reference time:

    autolambda -I [miniSEED file sorted by time] -H [messaging host] --ref-time "2018-08-27 01:00:00.000"

  • For real-time operation, start autolambda in one terminal with a real-time RecordStream, .e.g. slink or caps. You may also play back the data in another terminal using msrtsimul [3].

    Terminal 1 runs autolambda with caps recordstream:

    autolambda -I caps://localhost:18002 --debug

    Hint

    For playbacks based on a CAPS server read the instructions on real-time playbacks using caps.

    In case of a playback, terminal 2 provides the data:

    msrtsimul -v [your sorted miniSEED file, 512 Bytes records]

Offline data processing

In offline mode the processing results, e.g. picks and origins, are printed to stdout. The can be redirected to an XML file which can be passed in to other modules such as scanloc [7] and processed using the option --ep.

  • Run autolambda with data from a miniSEED file. Connect to the database to get all station information. The reference time can be set to the epoch of the data guaranteeing that the array is recognized. The default refefence time is the time of execution. All runtime information are printed to the terminal:

    autolambda --ep -I [miniSEED file sorted by time] -d [host]/[database] --console=1 > results.xml

  • For data processing from closed stations or from stations with changed inventory, the reference time must be set to the respective period ensuring that station inventory is defined therein, e.g.

    autolambda --ep -I [miniSEED file sorted by time] -d [host]/[database] --ref-time "2018-08-27 01:00:00.000" > results.xml

  • Additional progress report may may provided as an info message independent of the debug messages. The report is usefull to evaluate the processing speed. Use the option --progress, e.g. for intervals of 900 s

    autolambda --ep -I [miniSEED file sorted by time] -d [host]/[database] --ref-time "2018-08-27 01:00:00.000" --console=1 -v --progress 900 > results.xml

Configuration and Setup

The control parameters of autolambda are described in the configuration section.

Note

autolambda can be configured with standard RecordStreams provided in SeisComP. Additional powerful RecordStreams such as failover [2] and router [5] ship as recordstream plugins with gempa’s recordstream package.

Single instance

  1. Arrays: Define the arrays to be considered by creating array profiles in the arrays configuration section.

  2. Waveform processing: Create or adjust at least one base profile as profiles.base.$name. Configure the basic parameters for waveform processing. Examples exist for processing waveforms recorded a local or telseseismic distances.

  3. Method-specific settings:

    • Slowness-wavenumber analysis: Create at least on profile as profiles.slownessgrid.$name defining the extent and the resolution of the slowness grid.

    • Backprojection: Create at least one profile as profiles.backprojection.$name defining the extent and the resolution of the search area as well as the travel-time table for stacking waveforms along the travel-time curves. Currently, “LOCSAT” or “libtau” are supported for the type.

    • PMCC: Define the parameters for forming pixel families.

  4. Bindings: Define per method the array to use along with one base and one method profile. Create the array bindings for slownessgrid, backprojection or PMCC, bindings.slownessgrid, bindings.backprojection or bindings.pmcc, respectively.

    • one array can be used with multiple methods at the same time.

    • one method can be used with multiple arrays at the same time.

    • an empty bindings parameter causes the method to be ignored.

  5. Consider other system settings and integrations:

    • pipeline [4]: Configure connection.primaryGroup to send picks to the desired primary group when using a autolambda in a non-standard processing pipeline.

    • scanloc [7]: configure association.minPhase = 1 if you wish to associate more picks to origins from backprojection.

    • locator: Depending on the method picks may have values for backazimuth and slowness. If incorrect, they may bias the location. Thus, their use may be deactivated per locator in global configuration, e.g. for LOCSAT [1] by LOCSAT.usePickBackazimuth and LOCSAT.usePickSlowness (requires SeisComP v>5.0.0).

    • Event association: You may wish to configure scevent [10] to create events from origins with only one phase picks, when applying backprojection.

Multiple instances

One or more arrays can be used for multiple tasks by configuration of the array bindings parameters. You may therefore set up and operate multiple instances of autolambda with different configurations. To start a new instance, e.g. called l1alambda

  1. Create the module alias:

    seiscomp alias create l1alambda autolambda

  2. Configure this new alias module as a single instance.

  3. Operate the alias module.