nikost / gisola Goto Github PK

Discussed in #30

Describe the bug
FMVAR value sometimes gets NULL value.

Expected behavior
It should have a float value.

Additional context
Any PR that solves it, is welcomed.

hello, there is a minor issue when dealing with 12Z etc channels in stream.py.

currently they are rotated FIRST (which rotates 12Z to a ZNE frame), and then the inventory is used to remove the response AFTERWARDS. this will cause an inventory error because the newly rotated "ZNE" channels are not in the inventory, only the original "12Z". the solution is to simply just rotate after removing the response.

another related issue involves the "components" kwarg in rotate(). I don't think this is necessary anymore in obspy, and in fact it seems to cause a lot of additional issues. rotating frames works fine just with st.rotate(method="->ZNE", inventory=inv)

Setting the value to null at the Magnitudetype at the Watcher configuration seems that is not working properly. You should use a valid type (depending also on the source of events, e.g. MLh). In any case please, test it before using it by:

• running python3 ./gisola.py --real-time
• and also set Playback to seconds before a known event to see if the mechanism of the watcher is able to catch it, instead of waiting for new events

Hi again-

We have not been able to get nice correlations between synthetic and observed waveforms in Gisola. Using the same data / events in Isola (or other similar codes) generally works very well with high correlation fits so it is not clear what is going wrong.

Looking at the waveforms plotted in the output webpage, the synthetic data appears to be correct / matches the independently filtered observed data, but the observed waveforms in Gisola are significantly longer and look "more stretched out" than they should be. In the below image our filter is [0.01, 0.04, 0.12, 0.14] but it shows a signal 200+ seconds long. In reality it is only 40-50 seconds at most, similar to the synthetic prediction.

The event in this example is a mag 5.6, 19km deep, with stations between 25-83 km away. For simplicity we are only using one frequency filter band (as above) our velocity model is below. It has proven to produce very good fits using other (older) MT codes so I wouldn't suspect that is the problem, unless it is malformed somehow.

Crustal model                       model
depth of layer top(km)   Vp(km/s)    Vs(km/s)    Rho(g/cm**3)
0.0 2.60 1.49 1.08 300 150
2.0 3.54 1.77 1.48 300 150
4.0 4.46 2.19 1.86 300 150
6.0 5.45 2.78 2.27 300 150
8.0 5.79 3.05 2.41 300 150
10.0 6.20 3.38 2.58 300 150
12.0 6.48 3.62 2.70 300 150
14.0 6.81 3.81 2.84 300 150
16.0 7.04 3.96 2.93 300 150
18.0 7.22 4.12 3.01 300 150
20.0 7.30 4.14 3.04 300 150
22.0 7.17 4.13 2.99 300 150
24.0 6.89 4.10 2.87 300 150
26.0 6.66 4.07 2.78 300 150
28.0 6.51 4.04 2.71 300 150
30.0 6.44 4.03 2.68 300 150
32.0 6.59 4.05 2.74 300 150
34.0 6.82 4.08 2.84 300 150
36.0 7.10 4.13 2.96 300 150
38.0 7.37 4.24 3.07 300 150
40.0 7.65 4.39 3.19 300 150
42.0 7.75 4.46 3.23 300 150
44.0 7.85 4.51 3.27 300 1000
56.0 7.92 4.54 3.30 300 1000

To isolate the issue I have allowed only one inversion time window [3.6, 6.9, 245.76] and timeshift [3.6, 6.9, [-67, 10, 167]] option. (I also noticed that despite the event being a 5.6, the window was always 245 seconds when it should have been 409, but I think that may be a separate issue.)

Any ideas what is happening, or have you experienced anything similar? Any help appreciated, thanks!

Is your feature request related to a problem? Please describe.
In some rare cases the ObsPy can not plot a full MT beachball, then Gisola falls back to DC plotting but without noticing the user in the log.

Describe the solution you'd like
Add statement in the procedure's log file.

Describe the bug
When plotting a large range of x-y-z axis, figures might cut out beachballs representation from plot (see the last column).

Screenshots

Describe the bug
All MTs solutions are being acknowledged in order to retrieve the best, however, not all MT solutions as being stored when processing is done. Specifically, are stored:

• all the grid's points MTs calculation for the best timeshift only
• all MTs for all timeshifts that the correlation >= 90%*max_corr