Examples

3-Systems setup

• Goal: Parameter exchange between 3 separate SeisComP systems (A, B, C)

• Setup:

  • Operate 3 separate SeisComP systems with stand-alone data processing.

  • Run one QuakeLink instance along with each separate SeisComP system.

  • sc2ql delivers the own preferred Origins to own QuakeLink instance.

  • ql2sc [1] imports Origins from remote QuakeLink instance and sends them to the own messaging system, e.g., for processing by scevent [4]. Let scevent integrate the origins as per its own configuration.

  • scevent [4] on the own system associates all Origins and defines the preferred origin.

  • Check the parameters example of the 1+2 system setup for the detailed setup parameters at system A. Repeat for the system B and C.

Figure 2: 3-System setup.

1+2 Systems setup

Parameter exchange at agency A with agencies B, C. Configuration at agency A which may be equally repeated at B and C.

• Goals:

  • Push Event parameters of agency A to own QuakeLink instance running on the same machine of agency A.

  • Agency A allows secure connection from agencies B, C to QuakeLink at A.

  • Import Origins from agencies B and C to A.

• Configuration:

  • Global module configuration (global.cfg)

    • define ID of agency at A which can later be used for prioritizing origins:

      agencyID = A
      

    • Prepend the host name to public IDs of objects such as origins for unique identification:

      publicIDPattern = @hostname@.@classname@/@time/%Y%m%d%H%M%S.%f@.@id@
      

  • scevent [4] module configuration (scevent.cfg)

    • define the priority of agencies and configure to consider agency as a criterion for preferring an origin.

      eventAssociation.agencies = A,B,C
      

      If you wish to always prefer origins from agency A, give it highest consideration:

      eventAssociation.priorities = AGENCY, MODE, STATUS, PHASES_AUTOMATIC, RMS__AUTOMATIC, TIME_AUTOMATIC
      

      However, if you wish to first consider origin quality parameters, then consider AGENCY at a later stage or even drop it:

      eventAssociation.priorities = MODE, STATUS, PHASES_AUTOMATIC, RMS__AUTOMATIC, AGENCY, TIME_AUTOMATIC
      

    • optionally delay origins from agencies B, C by some seconds allowing to first prefer own origins:

      eventAssociation.delayTimeSpan = 10
      eventAssociation.delayFilter.agencyID = B, C
      

    Hint

    Except the order of preferred agencies and the delay filter, the configuration of scevent is typically very similar for the host system. Edge cases can be expected for contradicting configurations of scevent. Read section Edge cases for examples.

  • quakelink module configuration (quakelink.cfg):

    • define the input and output ports as well as the port for the QukeLink website. The defaults are:

      QL.port = 18010
      QL.pluginPort = 18011
      QL.http.port = 18080
      

    • for encrypted communication define ports, SSL certificates and user access

      QL.https.port = 22
      QL.SSL.port = 22
      
      QL.SSL.certificate = ...
      QL.SSL.key = ...
      QL.SSL.users =...
      

  • sc2ql module configuration (sc2ql.cfg)

    Unless quakelink runs with non-default server address or port, sc2ql may as well run with just the default parameters and no further configuration is required.

  • ql2sc [1] module configuration (ql2sc.cfg)

    Add host profiles for hostB and hostC. Decide whether to use secure connection (example: hostB) or non-secure connection (example: hostC). Synchronize the all journals for receiving update on event attributes such type and certainty or manually set preferred origins. Per host profile you may further filter origin transfer by origin-related properties. By blocking (blacklisting) origins with publicIDs containing the name of hostA those origins will not be transferred back again. Specifically allowing (whitelisting) publicID patterns will confine the request to the corresponding origins.

    hosts = hostB, hostC
    
    host.hostB.url = qls://user:passwd@remotehostB:18010
    host.hostB.native = false
    host.hostB.syncEventAttributes = false
    host.hostB.syncJournals = true
    host.hostB.routingTable = Pick:IMPORT_GROUP, Amplitude:IMPORT_GROUP, FocalMechanism:EVENT, Origin:EVENT
    
    
    host.hostC.url = ql://hostC:18010
    host.hostC.native = false
    host.hostC.syncEventAttributes = false
    host.hostC.syncJournals = true
    host.hostC.routingTable = Pick:IMPORT_GROUP, Amplitude:IMPORT_GROUP, FocalMechanism:EVENT, Origin:EVENT
    
    processing.blacklist.publicIDs = hostA
    # processing.whitelist.publicIDs = hostB, hostC
    

    Note

    The following features require SeisComP in version 7.4 or higher:

    • Configuration of the parameter host.$name.syncJournals.

    • Instead of setting the public ID pattern explicitly, the host names can be resolved by environment variables, e.g., ‘@hostname@’. Resolving environment variables configured with processing.blacklist.publicIDs or processing.whitelist.publicIDs.

Edge cases

scevent priority list

Consider two testbed systems, TB1 and TB2 with the different configurations of scevent:

• TB1:

  eventAssociation.agencies = GEMPA_TB1,GEMPA_TB2
  eventAssociation.priorities = MODE, STATUS, PHASES_AUTOMATIC, RMS_AUTOMATIC, AGENCY, TIME_AUTOMATIC
  

• TB2:

  eventAssociation.agencies = GEMPA_TB1
  eventAssociation.priorities = MODE, AGENCY, STATUS, PHASES_AUTOMATIC, TIME_AUTOMATIC
  

On both systems, scevent gives preference to origins with agency ID GEMPA_TB1 as defined by eventAssociation.agencies. However, the test of the agency ID is done at different stages as configured by eventAssociation.priorities.

In a real-life scenario, both systems, TB1 and TB2, have received origins, O1 and O2, from their own processing plus the preferred origin the other system had preferred. scevent preferred the origins from the respective other system, hence O2 on TB1 and O1 on TB2, see figure below. None of them has a magnitude available which, however, exists on the other system. This poses a serve issue which can be avoided by configuration of scevent.

Figure 3: TB1: Origins with preferred origin and missing magnitudes.

Figure 4: TB2: Origins with preferred origin and missing magnitudes.

The sequence of procedures that resulted in the unfavorable situation were:

1. Both systems create origins and receive origins from their own QuakeLink server. Only the current preferred origin is sent to the QuakeLink server. Initially no magnitudes are available since amplitudes are measured with some delay. Magnitudes are created and updated on for origins on their originating system as amplitudes become available.

2. TB2 creates an origin, O2, slightly before TB1 creates origin O1. O1 and O2 become preferred on TB1 and TB2, respectively and are therefore sent to the QuakeLink servers with very little delay.

3. Due to latencies, O2 is received on TB1 before O1 is received on TB2.

4. TB1 prefers O2 and TB2 prefers O1 due to the different configurations of the scevent instances.

5. Because O1 and O2 are not preferred anymore on TB1 and TB2, respectively, the created and updated magnitudes are not sent to the QuakeLink server via sc2ql and cannot be received on the remote servers TB2 and TB1. On the other hand, no amplitudes/magnitudes are measured/computed for the incoming origins since they are sent to the EVENT message groups to which neither [2] nor [8] are subscribed and which, consequently, cannot react. Therefore, the origins preferred on TB1 and TB2 lack the magnitudes which they have on the original system TB2 and TB1.

   Note

   In order to avoid other side effects, origins received from QuakeLink should not be re-processed locally.

The solution to the issue is to

• Equally prioritize origins on both systems where agency is tested on the same level. Configuration of scevent on TB2:

  eventAssociation.priorities = MODE, STATUS, PHASES_AUTOMATIC, RMS_AUTOMATIC, AGENCY, TIME_AUTOMATIC
  eventAssociation.agencies = GEMPA_TB2,GEMPA_TB1
  

  or

• Configure the agency priority which prioritizes origins from the own agency. Configuration of scevent on TB2:

  eventAssociation.priorities = MODE, AGENCY, STATUS, PHASES_AUTOMATIC, RMS_AUTOMATIC, TIME_AUTOMATIC
  eventAssociation.agencies = GEMPA_TB2,GEMPA_TB1
  

Push external events to QuakeLink

• Goal: Populate the QuakeLink database with the event parameters existing in a file in SCML format. database of a particular type and on a particular host [type://user:password@host/database].

• Solution: use qlpush. Example:

  qlpush -H localhost:18011 events.xml
  

Import events from an external SeisComP

• Goal: Read events back in time from a remote QuakeLink server on demand and provide the parameters to QuakeLink in local system.

• Solution: use ql2sc [1]. The remote is configured in ql2sc.cfg. Example for fetching events from the past 10 days from quakelink which are sent to a SeisComP system:

  ql2sc --backLog 864000 --debug
  

Retrieve event information from a QuakeLink server

• Goal: Connect to quakelink to fetch the updated event parameters for an event from the QuakeLink server.

• Solution 1: use qltool. Example for fetching the parameters from event gempa2018abcd and storing in a SCML file:

  qltool -E gempa2018abcd > gempa2018abcd.xml
  

  Solution 2: use the download button in the event browser of the QuakeLink web interface.