scevent: split origin issue (EvSplitOrg action)

[luca-s]

Dear developers,

I would like to report a strange behaviour I noticed on scevent as a result of a split origin.

We had an event (smi:ch.ethz.sed/sc3a/2020wtaffs) at 2020-11-17 23:11:28 in "Elm GL" that contained an origin (smi:ch.ethz.sed/sc3a/origin/NLL.20201117231135.77423.15151) that was actually a different event. So we split that origin to create an event on its own (smi:ch.ethz.sed/sc3a/2020wtafhp) at 2020-11-17 23:11:08 in "Bourg-Saint_pierre VS". That worked fine.

Then we manually reviewed origin smi:ch.ethz.sed/sc3a/origin/NLL.20201117231135.77423.15151 and created a manual origin smi:ch.ethz.sed/sc3a/origin/NLL.20201118113244.164437.127249 . Again, that worked fine. You can see the results in this screenshots:

The strange behaviour started after.

We have an automatic relocation module (scrtdd) which works similarly to screloc: it listens to origins and provide new relocated ones.

The strange behaviour is that the automatic origins generated by scrtdd (smi:ch.ethz.sed/sc3a/Origin/RTDD.20201118111112.972178.48930, smi:ch.ethz.sed/sc3a/Origin/RTDD.20201118113406.830309.49067, smi:ch.ethz.sed/sc3a/Origin/RTDD.20201118113424.101546.49072) as a relocation result of the origins belonging to event smi:ch.ethz.sed/sc3a/2020wtafhp at 2020-11-17 23:11:08 were wrongly associated to the event smi:ch.ethz.sed/sc3a/2020wtaffs at 2020-11-17 23:11:28.

I looked at the logs and this is what I found out.

Here is the log of the event smi:ch.ethz.sed/sc3a/2020wtafhp creation as a result of the split of smi:ch.ethz.sed/sc3a/origin/NLL.20201117231135.77423.15151 (nothing suspicious here):

Now let's see the scevent log for the origin smi:ch.ethz.sed/sc3a/Origin/RTDD.20201118111112.972178.48930 that was wrongly associated to event smi:ch.ethz.sed/sc3a/2020wtaffs, although the triggering origin smi:ch.ethz.sed/sc3a/origin/NLL.20201117231135.77423.15151 was already part of event smi:ch.ethz.sed/sc3a/2020wtafhp.

We can see the problem in the log: the matching picks seems to be wrong. For some reason scevent believes that there are more mathing picks in event smi:ch.ethz.sed/sc3a/2020wtaffs (4/10) instead of smi:ch.ethz.sed/sc3a/2020wtafhp (0/10 !?!?). It seems there is some sort of stale cached information here.

The same issue happened to origins smi:ch.ethz.sed/sc3a/Origin/RTDD.20201118113406.830309.49067 and smi:ch.ethz.sed/sc3a/Origin/RTDD.20201118113424.101546.49072 that were associated to the wrong event smi:ch.ethz.sed/sc3a/2020wtaffs, although the triggering origin smi:ch.ethz.sed/sc3a/origin/NLL.20201118113244.164437.127249 was already part of event smi:ch.ethz.sed/sc3a/2020wtafhp.

Thank your for your help

Luca

[gempa-jabe]

Thanks for the report. The cached pick list seems to be the correct explanation. I will take a look into it.

[luca-s]

@gempa-jabe thanks

[gempa-jabe]

Please check if af1e30a fixes the issue.

[luca-s]

Thank you for the quick fix. I'll test it and let you know

[luca-s]

The fix solved the issue. Thank you very much