Errors running Gisola with Localhost

[Carols04]

Dear @nikosT,

We have problems when we change our host and try to execute GISOLA for a particular event (not real-time).
We have tried to run GISOLA for a particular event specifying the evid or the datetime-range.

./gisola.py --event es2023slmwu -c config.yaml -l log_events

./gisola.py --datetime-range 2023-09-08T22:00:00 2023-09-08T23:00:00 -c config.yaml

In the config.yaml (in Watcher) we have set magnitude to null or to mb. We have also tried several values of Range and Playback, including the default ones (Range: 540 s, Playback: 0)
We always get the same:

2023-09-20 11:24:39,652 INFO Connecting to FDSNWS-event host: http://localhost:port
2023-09-20 11:24:39,705 INFO Requesting event with ID: es2023slmwu
Traceback (most recent call last):
File "/opt/gisola/src/./gisola.py", line 167, in
config.init(evt, _cfg)
File "/opt/gisola/src/config.py", line 88, in init
mag=event.getMagnitude(evnt, org)
File "/opt/gisola/src/event.py", line 170, in getMagnitude
return [m for m in evt.magnitudes if m.origin_id==org.resource_id][0]
IndexError: list index out of range

We print m.origin_id for m in evt.magnitudes and we obtained:

[none, none, none, none]

In addition, we have also tried running GISOLA in real-time mode following its guide:
./gisola.py --real-time -c config.yaml -l log_events
We always get a message concerning the quality thresholds, although we have tested several values for the Quality (uncertainties) in the Watcher:

2023-09-20 11:43:54,299 INFO Connecting to FDSNWS-event host: http://localhost:port
2023-09-20 11:43:54,350 INFO Requesting event in timespan: 2023-09-20T09:04:36.299026Z - 2023-09-20T09:26:26.299026Z
2023-09-20 11:43:54,350 INFO Minimum Magnitude and type is set to: 3.5 and mb respectively
list index out of range
2023-09-20 11:43:54,567 INFO Event: 2023-09-20T09:17:46.983380Z | +31.455, -7.832 | 4.090719642 mbign_man | manual
resource_id: ResourceIdentifier(id="smi:scs/0.7/es2023slmwu")
event_type: 'earthquake'
event_type_certainty: 'known'
creation_info: CreationInfo(agency_id='IGN', author='scevent@pacifico01', creation_time=UTCDateTime(2023, 9, 20, 9, 30, 33, 125582))
preferred_origin_id: ResourceIdentifier(id="smi:scs/0.7/Origin#20230920093004.666023.74008")
preferred_magnitude_id: ResourceIdentifier(id="smi:scs/0.7/Magnitude#20230920093013.147251.74024")
---------
event_descriptions: 1 Elements
picks: 24 Elements
origins: 1 Elements
magnitudes: 9 Elements
does not meet quality thresholds. It is removed from process
2023-09-20 11:43:54,568 INFO 0 Event(s) in Catalog:

Now, we don't know how to proceed.

Thanks a lot

Best wishes,
Carolina

[nikosT]

Dear @Carols04 ,

There are many ways to fix or bypass those errors. I would suggest first to see what's the problem though. Concerning the first case, is the http://localhost:port an FDSNWS-event? I believe yes, according to the description of the second issue.

The issue in the first case is that it tries to retrieve the associated magnitude for that particular event based on the selected origin (probably the "preferred" one or the last one). The process can not move on without an associated magnitude.

This depends also on whether you have activated the historical option; I believe not, and you should not. The historical parameter is for measuring the accuracy of real-time operation. It's only for measuring though, you should not activate it in real-time either. It's always better to have the most updated origin based on the assumption that as time passes the estimation of origin is more accurate (e.g. manual solutions).

We have to be sure that the FDSNWS-event brings all the necessary info. Could you share a QuakeML format file via the FDSNWS-event?
http://localhost:port/fdsnws/event/1/query?includeallorigins=true&includeallmagnitudes=true&includearrivals=true&eventid=es2023slmwu&nodata=404

One question also:
File "/opt/gisola/src/event.py", line 170, in getMagnitude it was supposed to be at line 165. Did you add more code in file? Are you sure that does not affect the case?

Also, the Watcher is activated in real-time scenarios only. So in that case it does not matter the values of range or playback.

About the second case:
You could try to have high values in uncertainties so they can pass the check here: https://github.com/nikosT/Gisola/blob/main/src/event.py#L194-L201

Otherwise, comment out those lines and put return True https://github.com/nikosT/Gisola/blob/main/src/event.py#L203 to the respective indentation (4 spaces back)