Multiple templates per stream

[damb]

For the time being, only a single template is allowed to be processed per detector per stream. Though, it would be feasible for a detector to apply multiple template (processors) to a single stream.

Question:

• Is processing multiple templates (based on multiple arrivals) with regards to a single stream a reasonable scenario? I mean from a scientific perspective.

[damb]

@kaestli

[kaestli]

I can imagine that one could think about different templates covering just the highest bursts of energy of the p, or s phase respectively (thus looking at earthquake energy only, and skipping the noise-dominated part in between. Especially in teleseismic applications.
However I have not heard talking about this at SED. I guess it is not a priority.
(would your application mind in any respect? would it not be treated as "just another template"?)

[luca-s]

@damb what happens with the current implementation if the scientists use scdetect similarly to SeisMatch, that is multiple templates for the same stream? Will scdetect create multiple detectors, one per template? So the ability for a detector to process multiple templates would be just an optimization?

[damb]

@damb what happens with the current implementation if the scientists use scdetect similarly to SeisMatch, that is multiple templates for the same stream? Will scdetect create multiple detectors, one per template?

It depends on the template configuration (i.e. the content of the template.json). You can set up either a detector handling a single template and thus emitting detections based on a single template (waveform) or you can configure a detector to perform multi-stream processing.
If I don't miss something, in the scenario you describe, setting up multiple detectors (each covering the same stream, but with a different template (stream) configuration) would be the right way to go.

Though, what is still not in-place is a detector covering a single stream with multiple template configurations. Note that the configuration may differ not just only in the template waveform used, but also w.r.t. e.g. filtering.

So the ability for a detector to process multiple templates would be just an optimization?

I wouldn't use the word optimization, here. Instead, I would rather say this feature would allow for additional configuration options.

[damb]

(would your application mind in any respect? would it not be treated as "just another template"?)

As already mentioned, the current implementation isn't able to cope with detectors covering multiple template (stream) configurations each covering the same (real-time) stream to be processed.

So yes, implementing this feature would allow for additional scenarios to be covered.

[damb]

I guess it is not a priority.

Ok. I leave this issue open by now. As a reminder for myself.

[mmesim]

Just a question:
@damb Is this still an open issue?

[damb]

Yes.

[damb]

Do you have high priority for this? Would this feature be of use for you?

[mmesim]

I'm not sure that I fully follow the conversation here. Let's chat about that tomorrow.