Understanding the FinDer report from sceewlog

[dufangqing]

Dear all,

I understood that scfinder can compute and update solutions every second (configurable), but I noticed that there were sometimes several solutions provided at the 1s time window, and they tend to be the same solutions. Is this a normal thing or is there something wrong? Here I also attached a report example I got from sceewlog:

Thanks a lot,
Du

[FMassin]

Hello,

Please keep scfinder's finder.scanInterval > finder.processInterval in order to avoid duplicates. We can suggest finder.scanInterval = 1.0 and finder.processInterval = 0.8.

Also, scfinder produces both basic and strong motion origins once the strong motion data model extension is applied to database (see https://docs.gempa.de/sed-eew/current/apps/scfinder.html#description). So every FinDer origin might look duplicated. But it could be disabled by setting finder.strongMotionGroup = LOCATION_FDSM and excluding LOCATION_FDSM from scevent configuration (thus leaving these strong motion origins unassociated).

Let me know if that fixes your issue.

[dufangqing]

Also from this plot I uploaded, you can see that it took a long time to obtain the first solution. It is because there's a huge latency when I use msrtsimul and feed the simulated waveforms to scfinder (msrtsimul -v -c file.mseed | seiscomp-finder exec scfinder --playback --inventory-db file.xml -I -), and I guess this means the waveforms that fed to scfinder are completely wrong? Do you think this latency would be a problem? Thanks

[FMassin]

Every origin is still duplicated. You must define LOCATION_FDSM in scmaster groups following https://www.seiscomp.de/doc/apps/scmaster.html#message-groups

[dufangqing]

Sorry, I am afraid I am still not sure how to exclude the LOCATION_FDSM from the scevent configuration... Here are the modifications that I made so far:

1. scmaster.cfg:
   defaultGroups = AMPLITUDE,
   PICK,
   LOCATION,
   MAGNITUDE,
   FOCMECH,
   EVENT,
   QC,
   PUBLICATION,
   GUI,
   INVENTORY,
   ROUTING,
   CONFIG,
   LOGGING,
   IMPORT_GROUP,
   SERVICE_REQUEST,
   SERVICE_PROVIDE,
   LOCATION_FDSM

2. scfinder.cfg:
   finder.strongMotionGroup = LOCATION_FDSM

[FMassin]

LOCATION_FDSM is not included in the default config of scevent, so no need for anything else.

[dufangqing]

But I still have the duplicates, not sure why...

[FMassin]

Also from this plot I uploaded, you can see that it took a long time to obtain the first solution. It is because there's a huge latency when I use msrtsimul and feed the simulated waveforms to scfinder (msrtsimul -v -c file.mseed | seiscomp-finder exec scfinder --playback --inventory-db file.xml -I -), and I guess this means the waveforms that fed to scfinder are completely wrong? Do you think this latency would be a problem? Thanks

Why would there be latency? The data are timestamped with current time while streamed...

[dufangqing]

I am not sure to be honest. I also enabled logging for msrtsimul and it is obvious that there's already latency in msrtsimul:

OX_V325 102.91 2024-03-06 10:34:37.432706 12.08
OX_V325 102.91 2024-03-06 10:34:37.432706 12.08
OX_V325 102.91 2024-03-06 10:34:37.432706 12.09
10:34:49 [warning] OX.V387.00.HNE: max delay exceeded: 13.882985s
10:34:49 [warning] OX.V387.00.HNE: horizontal gap too high: 60.168004s
10:34:49 [warning] IT.MDG..HGE: max delay exceeded: 13.882567s
10:34:49 [debug] [IT.MDG..HGE] Query inventory
IT.MDG..HGE: set clip mask: clipped = 114
10:34:49 [warning] IT.MDG..HGN: max delay exceeded: 13.883037s
10:34:49 [debug] [IT.MDG..HGN] Query inventory
IT.MDG..HGN: set clip mask: clipped = 114
10:34:49 [warning] IT.MDG..HGZ: max delay exceeded: 13.883350s
10:34:49 [debug] [IT.MDG..HGZ] Query inventory
IT.MDG..HGZ: set clip mask: clipped = 114
10:34:49 [warning] OX.V302.00.HNE: max delay exceeded: 13.882808s
10:34:49 [warning] OX.V302.00.HNN: max delay exceeded: 13.883366s
10:34:49 [debug] check_station_thresh: Size of raw_pga_data_list = 258 size of pga_data_list_above_noise = 258
10:34:49 [debug] remove_noisy_stations: Size of pga_data_list at start = 258
10:34:49 [debug] remove_noisy_stations: Size of pga_data_list good stations at end = 258
10:34:49 [debug] determine_trigger: Number of Finder objects within Scan_Data = 1

And for the max delay exceeded warning I got when the packet delay is larger than 3s, the fun thing is that I do not get such a warning when I only playback waveforms of the OX stations and I get such a high delay when I playback the OX waveforms combined with waveforms recorded by other stations. Is this a common phenomenon that more waveforms for playback may introduce higher packet delays?

However, I also tried only simulating the waveforms (recorded by many networks) with msrtsimul and the latency was within 3s, is it possible that msrtsimul and scfinder working together may cause higher latency somehow?

[FMassin]

Yes that seems to be an issue with msrtsimul. I guess it would probably be very useful to fix the data delay issue first. Of course data packet are sorted? Maybe monitoring data delay (scqc or slinktool -p) would help? The best experts about this are on the seiscomp forum, sorry.