Nordic IAML units: how should we convert from QuakeML (AML) to IAML.

[calum-chamberlain]

I think Seisan stores IAML (Amplitude measurements for local magnitudes) as ground-motion in nm on a Wood-Anderson instrument; not the measured trace amplitude on a Wood-Anderson instrument. e.g. the sensitivity of the Wood-Anderson instrument is not applied. After a lot of trawling through the Seisan manual, and playing around with instrument corrections it looks like this is the case.

At the moment reading and writing Nordic does not apply/remove the Wood Anderson sensitivity during IO. This would be easy to implement, but I'm not clear what the QuakeML standard for AML amplitudes is. I had assumed that it was the measured amplitude on a Wood Anderson instrument (with units specified in the units of the Amplitude measurement). Both the EQcorrscan and ObsPy local magnitude picking/converting functions end up with measurements on a Wood Anderson instrument, not the ground motion (e.g. with the sensitivity applied).

The main reason for opening this is that I'm not sure if I/we should be removing/applying the Wood Anderson sensitivity to convert between Seisan IAML and QuakeML AML? Pinging @flixha and @WayneCrawford for some Nordic expertise and thoughts...

The sections of code that could be changed to apply/remove the Wood Anderson sensitivity are here:

https://github.com/obspy/obspy/blob/e4aeb46ceb7ef92819fe887288724583579e1f23/obspy/io/nordic/core.py#L737-L740

https://github.com/obspy/obspy/blob/e4aeb46ceb7ef92819fe887288724583579e1f23/obspy/io/nordic/core.py#L1425-L1429

[flixha]

You're right, in Nordic format the IAML references a value of ground displacement in nm, not the amplitude value that would appear on the Wood Anderson seismograph. In Seisan, the conversion (100000/2080) is built into the formula for the local magnitude scale, Ml = log10(amp) + 1.11log10(r) + 0.00189r − 2.09 (amp in nm, as written in Seisan) -log Ao = 1.110 log(r/100) + 0.00189(r - 100) + 3.0 (Ao in mm on WA, as in Hutton & Boore, 1987) (Let me know if you would like some details on the conversion, but it may be easier to explain via a spreadsheet).

While in Seisan the amplitude is referred under IAML, QuakeML only refers tpo AML, which according to Storchak et al. 2003, and explicitly described by the ISC / IASPSEI standard phase list is:

IAML | Displacement amplitude measured according to the IASPEI standard for local magnitude ML AML | Displacement amplitude measurement for non-standard local magnitude

According to the NMSOP IS 3.3, for ML amplitudes the standard is:

A= maximum trace amplitude in nm that is measured on output from a horizontal-componentinstrument that is filtered so that the response of the seismograph/filter system replicates that of a Wood-Anderson standard seismograph but with a static magnification of 1 (see Table 1 and Figure 1);

The specification between IAML and AML seems to be from 2013, the same year as the last major revision of the QuakeML documentation - that's why the exact specification between AML and IAML may not have been considered for QML.

Taking those different documents together, as I understand it, when one stores an amplitude value under AML in QuakeML, then the filterID would need to point to a filter that contains the information on whether the Wood-Anderson sensitivity was applied or not. Without that filterID, one cannot assume that two AML-amplitudes stored in QuakeML are comparable.

If one wants to stick to the IASPEI standard, then the stored amplitude should be without the Wood-Anderson magnification applied. I don't really know the Obspy / EQcorrscan picking/conversion functions and how people use their output, but I'll have a look at them now. Maybe the fix here should be that all the values put out by the functions and the Nordic-> QuakeML converter need the proper specification on the filter? Without specification, I'd assume it to be the standard, IAML.

[calum-chamberlain]

Hey @flixha thanks for all of that - happy with the conversion in the equations, tracked those down yesterday (rainy Sunday). Thanks for so many references as well, I had gone through NMSOP, the seisan manual, and the QuakeML docs, but hadn't gone to the IASPEI phase list - good to see them both stated there. I hadn't noted the significance of the dates - good point.

I agree on the need for filterID in the AML, although I don't know how Nordic IO (in ObsPy) would be able to interpret that on the fly - is there a standard filterID for everyone that is a Wood-Anderson response applied, with sensitivity? By my reading, the flexibility of ResourceID means that there doesn't seem to be a standard filter to point to for this purpose. The upshot of this seems that nordic IO should never be writing AML amplitudes to IAML, unless explicitly asked to...

I certainly should put this in to the EQcorrscan picker, and a methodID linking to the docs. RE: EQcorrscan picker, this function is used to remove response and simulate a Wood Anderson (with sensitivity applied) then amplitude picks are made on that Trace. The output is stored as an Amplitude with flag AML. The ObsPy magnitude/Wood Anderson amplitude conversion things don't run into any of this because they don't output to Event format, they just return numbers.

In EQcorrscan the Amplitudes are (incorrectly) associated with a Pick with phase-hint IAML. Because the amplitude picked actually has the sensitivity simulated, this isn't IASPEI standard - I will take care of that at EQcorrscan.

[WayneCrawford]

Glad to see there are competent people w.r.t. IAML and AML: I had no idea!

Cheers Wayne

---

Wayne Crawford CNRS Researcher Institut de Physique du Globe de Paris 1, rue Jussieu 75238 Paris Cedex 05 +33 6 5151 1054

On 3 mai 2020 at 22:39:44, Calum Chamberlain (notifications@github.com) wrote:

Hey @flixha thanks for all of that - happy with the conversion in the equations, tracked those down yesterday (rainy Sunday). Thanks for so many references as well, I had gone through NMSOP, the seisan manual, and the QuakeML docs, but hadn't gone to the IASPEI phase list - good to see them both stated there. I hadn't noted the significance of the dates - good point.

I agree on the need for filterID in the AML, although I don't know how Nordic IO (in ObsPy) would be able to interpret that on the fly - is there a standard filterID for everyone that is a Wood-Anderson response applied, with sensitivity? By my reading, the flexibility of ResourceID means that there doesn't seem to be a standard filter to point to for this purpose. The upshot of this seems that nordic IO should never be writing AML amplitudes to IAML, unless explicitly asked to...

I certainly should put this in to the EQcorrscan picker, and a methodID linking to the docs. RE: EQcorrscan picker, this function is used to remove response and simulate a Wood Anderson (with sensitivity applied) then amplitude picks are made on that Trace. The output is stored as an Amplitude with flag AML. The ObsPy magnitude/Wood Anderson amplitude conversion things don't run into any of this because they don't output to Event format, they just return numbers.

In EQcorrscan the Amplitudes are (incorrectly) associated with a Pick with phase-hint IAML. Because the amplitude picked actually has the sensitivity simulated, this isn't IASPEI standard - I will take care of that at EQcorrscan.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[flixha]

Hi Calum, thanks for putting some atention to these details and doing the changes in the EQcorrscan-picker.

I'm not sure how exactly one should go about filterID to link to common filters like the Wood-Anderson. Should we code these standards into obspy, so that one could load them from a module, and have the ResourceID point to that?

I just checked how a few datacenters set the type of the amplitude. Even though it may not be allowed from the strict values allowed for type in QML documentation, the ISC's fdsnws/event-web service returns amplitudes with <type>IAML</type> - as well as a few others. The ISC also seems to output such picks both as pick with phase_hint='IAML', as amplitude with type='IAML'´, and asarrival` without the actual amplitude-information, so duplicating the information per event.

So is that something we should be addressing in the Nordic I/O codes here?

[calum-chamberlain]

Thanks for pointing out the IAML amplitude type. For some reason I assumed this wasn't allowed because it wasn't in the strict amplitude types in QML (but ObsPy lets it fly). I like the idea of using that type and only converting those to IAML picks in Nordic, and converting all other amplitudes to generic amplitudes.

RE filterID - I would expect that they should be something handled by the datacentre and their software, so setting a "standard" obspy filter probably isn't helpful, nor will get picked up and used. I think that we should continue to ignore that, and just trust that Amplitudes with type="IAML" are what they say they are, and anything that doesn't say that, isn't IAML.

Annoyingly, GeoNet (who use Seiscomp) don't seem to follow other datacentres: they store Amplitude.type as "ML" or "MLv", which to me should be in the magnitude_hint parameter... They also don't supply units, or a time for the amplitude (they supply a time-window within which the automatic amplitude was picked) and the linked pick is just a phase pick. I have asked them and the QML team about what is appropriate here, but it seems like somewhat of a free-for-all, and GeoNet don't seem likely to change their ways to suit my whims (which is fair enough!).

---

Proposed change

Change the Nordic IO code such that only amplitudes with type="IAML" and a corresponding pick with phase_hint="IAML" are converted to IAML picks in nordic. Everything else can be written out as generic amplitude measurements.