I will try to add that once I find time to do so.
It also depends a little bit on the discussions on the riesgos annual meeting (mid october), if that is a path to follow.
In general I think it makes sense to have that anyway, but it is a matter of priorities.
@nils Thanks for submitting this MR. I'm happy to have another workflow added and the code looks good to me. Could you add a workflow test too?
Nils Brinckmann (782be2d1) at 30 Sep 23:12
Don't shadow import
Nils Brinckmann (e6dcf6f2) at 30 Sep 23:06
Fix some linter issues
This is an idea that came on the trip to Chile. Not sure if we really want to include it into RIESGOS. But Michael Langbein (DLR) works on some administration tools for the management of various WPS processes, and this here could be an option to add there as well (as alternative for the current shakyground 1 that we use at the moment for RIESGOS & as an example for others on how to replace existing services within the RIESGOS storyline).
@gweather For you to know.
Not sure if my suggestion here is works for 100% the same situations as the old code did. But as there was a similar example in the docs (https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscoverage_report) I have some hope.
When I currently made some tests about writing out the xml files that are alike the shakyground1 output that we use for RIESGOS, I realized that the CI has some problems currently.
I tried to check it with the functionality in gitlab here & there seems to be a problem with the following part:
artifacts:
reports:
cobertura: coverage.xml
Taking a look in the docs (https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscoverage_report) it seems to have changed slightly.
In my draft for the !37 MR, I switched over to:
artifacts:
reports:
coverage_report:
path: coverage.xml
coverage_format: cobertura
Maybe, this can be used in general to fix the current problem.
Nils Brinckmann (dcf0d207) at 30 Sep 22:51
Try to fix the gitlab ci
In order to use possibly use shakyground2 for riesgos, we need to write the same output format as shakyground1 did.
Those includes the creation of an USGS style xml shakemap out of an quakeml file.
Nils Brinckmann (d766af1a) at 30 Sep 22:47
Add more info to the usgs shakemaps
Nils Brinckmann (86d149b3) at 30 Sep 22:29
First validating version of usgs shakemap output
Graeme Weatherill (941e6cec) at 09 May 08:36
Fixes bug in quakeml reader, wrong magnitudes
Addresses #29
The quakeml reader was returning the magnitude corresponding to the last in the QuakeML file rather than the preferred magnitude. This MR fixes this to ensure that the preferred magnitude is returned.
Addresses #29
The quakeml reader was returning the magnitude corresponding to the last in the QuakeML file rather than the preferred magnitude. This MR fixes this to ensure that the preferred magnitude is returned.
Addresses #29
The quakeml reader was returning the magnitude corresponding to the last in the QuakeML file rather than the preferred magnitude. This MR fixes this to ensure that the preferred magnitude is returned.
@nils OK, so it looks like a more serious bug is taking place here in the quakeml reader.
For this event multiple magnitudes are reported (mb 4.02, M 4.02 , mB 3.19 and Mw(mB) 1.96). The preferred magnitude was pointing to the mb (which is greater than 3), but the reader is retrieving the last magnitude reported (Mw(mb) 1.96, which is < 3).
From what I can see it has probably always been doing this, which means that it has been creating shakemaps assuming the last magnitude of those in the Quakeml, not necessarily the preferred magnitude. I am fixing this but this may mean that shakemaps for existing events may not have been determined using the correct magnitude.
Graeme Weatherill (f5d040a5) at 05 May 11:11
Bumps black to 22.3.0, fixes OQ to 3.13.0
As I'm adding this suggested filter right now, I wonder about this single event here: I'm may need some tutoring here, but for gfz2022ihab the magnitude < 3 would not apply.
Yes, I will try to resolve the problem here(or at least catch it with a better error). My suggestion was more to avoid eqexplorer wasting computation time and disk space to calculate shakemaps for events that are so extremely unlikely to generate shaking of interest and/or so far outside the range of scenario conditions for which the ground motion models here can be applied.