Event score & Cross Correlation Coefficient

[mmesim]

This is an idea that Tobias had and links to issue #53. @kaestli

Could we somehow incorporate the Cross Correlation Coefficient (CCC) in the event score metric? If not the CCC itself, then maybe the standard_error. Could that be implemented in the scevent? Is it better to create a separate table for the CCCs or merge these with the existing metric?

[mmesim]

@luca-s

[luca-s]

The possibility offered by scevent is to call a custom script that evaluates an origin and returns a score for that. scevent can then use the score to decide which origin is the preferred one among the many that it has associated to the same event. In the script called by scevent we can add any logic we like e.g. we simply extract the CCC from the origin comment and return the value.

Currently, at SED, we use the score to compare origins generated by the same locator (nonlinloc) but we don't use it to compare origins across different methodologies (nonlincloc, double-difference, template matching). To compare different methodologies we have a simple priority list defined in scevent configuration that currently select nonlincloc over double-difference (this is because SED is slow in making changes and we continue with the well-known path for a long time before starting preferring a new methodology). The same will happen with scdetect.

[luca-s]

what you describe above refers just to the prioritization of origins (once they are already associated) in order to set the preferred origin. Is this correct?

Yes, correct.

May scevent also be used for associating origins based on a ?

No. scevent has its configurable logic to define when two origins belong to the same event, which is based on origin time, location and phases. Is that logic not enough for your use case? Do you believe two detections for the same templates end up in different events?

[damb]

No. scevent has its configurable logic to define when two origins belong to the same event, which is based on origin time, location and phases. Is that logic not enough for your use case? Do you believe two detections for the same templates end up in different events?

Ok, thanks. My idea was to use scevent in order to cluster scdetect-cc origins detected by a single detector (i.e. referring to the same template).

[luca-s]

My idea was to use scevent in order to cluster scdetect-cc origins detected by a single detector (i.e. referring to the same template)

You mean independently of the origin time? In that case scevent is not a good fit. What is the purpose of that clustering? Just for analysis?

[damb]

You mean independently of the origin time? In that case scevent is not a good fit.

Yes.

What is the purpose of that clustering? Just for analysis?

For analysis, yes. I'm aware that this can be done differently (e.g. query would do it already).

Though, clustering (in general) becomes interesting once deploying template configurations automatically.

[luca-s]

I don't have in mind a tool that can do what you are trying to achieve. You probably need to write your own script.

[luca-s]

The same will happen with scdetect.

I mean that we will add scdetect as a new method and it will be of a lower priority than nonlinloc and the score will not be even considered. However, for events detected only by scdetect (we expect many more than nonlinloc), then the score will be used to select the best scdetect origin among many, if there are many.