Hello,
We are configuring ccloc in pick mode, using historical P picks as single-channel templates.
For example, one of our templates is configured as:
event.PR2_P0001.baseID = CCLOC/P/PR2/P0001
event.PR2_P0001.xml = /home/sysop/ccloc_templates_clean/PR2/PR2_P0001.xml
event.PR2_P0001.data = file:///home/sysop/ccloc_templates_clean/PR2/PR2_P0001.mseed
and the XML contains:
2026-08-03T00:10:14.711510ZP
manual
According to the ccloc documentation, when baseID refers to a Pick ID, ccloc operates in pick mode and only picks, rather than origins, are sent out.
Our intention is to use the picks generated by ccloc as input to scautoloc.
Our current scautoloc messaging configuration is:
connection.primaryGroup = LOCATION
connection.subscriptions = PICK, AMPLITUDE
The default connection.primaryGroup for ccloc is also LOCATION.
Could you please clarify to which SeisComP messaging group the picks generated by ccloc in pick mode are actually sent?
Does ccloc send these generated Pick objects explicitly to the standard PICK group, or does it send them to the group configured by:
connection.primaryGroup
If connection.primaryGroup = LOCATION, would the generated picks therefore be sent to LOCATION?
If we want the generated ccloc picks to be consumed directly by a standard scautoloc instance subscribed to PICK, AMPLITUDE, should we configure ccloc with:
connection.primaryGroup = PICK
(or equivalently use -g PICK), or is this unnecessary because ccloc routes Pick objects to PICK automatically?
We would like to make sure that the intended processing chain is:
continuous waveform
|
v
ccloc
(template matching)
|
v
generated Pick
|
v
PICK group
|
v
scautoloc
We are using:
ccloc: 2026.225#cde8340
Framework: 7.3.0 Release
API version: 17.3.0
Thank you very much for your clarification.
Best regards,
Mihai