Amplitude pick timing information

[calum-chamberlain]

For amplitude measurements made at a distinct time (generic amplitudes, ML amplitudes etc.) the QuakeMLs do not obviously link to the time that the measurement is taken at. QuakeML amplitudes do not include a time slot, but as far as I know this is usually handled by associating the Amplitude with a Pick with the appropriate timing information. The only time information in Amplitude appears to be in timeWindow, which is documented as being:

Description of the time window used for amplitude measurement.

and contains a begin, end and referenceTime attribute, which is not explicitly the time that the measurement was taken.

For example (obspy for simplicity):

from obspy.clients.fdsn import Client

client = Client("GEONET")
cat = client.get_events(eventid="2019p603895")
amp = cat[0].amplitudes[0]
print(amp)

Amplitude
           resource_id: ResourceIdentifier(id="smi:nz.org.geonet/Amplitude/20190812103614.085545.302840")
     generic_amplitude: 4643.043213 [lower_uncertainty=225.7984065, upper_uncertainty=225.7984065]
                  type: 'ML'
           time_window: TimeWindow(begin=-12.059999, end=30.68, reference=UTCDateTime(2019, 8, 12, 10, 35, 39, 383131))
               pick_id: ResourceIdentifier(id="smi:nz.org.geonet/20190812.103532.32-AIC-NZ.MSZ.10.HHZ")
           waveform_id: WaveformStreamID(network_code='NZ', station_code='MSZ', channel_code='HH', location_code='10')
         creation_info: CreationInfo(agency_id='WEL(GNS_Primary)', author='scamp@kseqp02.geonet.org.nz', creation_time=UTCDateTime(2019, 8, 12, 10, 36, 14, 85583))

This contains a time_window attribute which I assume is the window that the automatic amplitude pick was made, and reference to a pick. Extracting the referenced pick returns a P pick, which does not correspond to the maximum amplitude:

print(amp.pick_id.get_referred_object())

Pick
         resource_id: ResourceIdentifier(id="smi:nz.org.geonet/20190812.103532.32-AIC-NZ.MSZ.10.HHZ")
                time: UTCDateTime(2019, 8, 12, 10, 35, 32, 323131)
         waveform_id: WaveformStreamID(network_code='NZ', station_code='MSZ', channel_code='HHZ', location_code='10')
           filter_id: ResourceIdentifier(id="smi:nz.org.geonet/BW(4,2.5,15)")
           method_id: ResourceIdentifier(id="smi:nz.org.geonet/AIC")
          phase_hint: 'P'
     evaluation_mode: 'automatic'
       creation_info: CreationInfo(agency_id='WEL(GNS_Primary)', author='scautopick@kseqp02.geonet.org.nz', creation_time=UTCDateTime(2019, 8, 12, 10, 35, 44, 252594))

It doesn't look like Picks are being correctly associated with amplitudes. Thoughts? Should I be looking elsewhere for amplitude timing information?

[ozym]

Without delving into the code, I suspect the pick attached is what kicked off the requirement for an amplitude, rather than anything related to the actual amplitude.

The automatic (or otherwise) system has made a P pick. It then requires an amplitude to go with it (for magnitude say) which is then used to define the "window" in which a peak amplitude is chosen.

This may help, I'm not 100% sure why (or where) the time of the actual peak is stored if at all.

This may help ... https://quake.ethz.ch/quakeml/QuakeML2.0/BasicEventDescription

[calum-chamberlain]

I thought that might be the case. Unfortunately the QuakeML descriptions do not seem to be very prescriptive on what the associated pick should be (the discussion of individual attributes is here). The part on amplitude pick-ids reads:

Refers to the publicID of an associated Pick object.

However, this does seem to be the only place that the measurement time can be placed. In Seisan for example, a discrete Pick is made for every amplitude, which has timing information associated with it. When converting that to QuakeML every Amplitude has its own Pick.

So, while associating the amplitude with the pick that triggered the measurement likely falls with the scope of QuakeML, it doesn't seem like the best use of that slot. I think the amplitude measurements need to have an observation time associated with them - should this be something that should be taken up with the code developers?

[calum-chamberlain]

I just has a quick check of how the NCEDC does it though, and for the first example I found with amplitude picks, their amplitude measurements are not associated with a pick and have no timing information.

from obspy.clients.fdsn import Client

client = Client("NCEDC")
ev = client.get_events(eventid="73129211", includearrivals=True)[0]
[amp for amp in ev.amplitudes if amp.magnitude_hint != "MD"][0]

Amplitude
           resource_id: ResourceIdentifier(id="quakeml:nc.anss.org/Amp/NC/172413399")
     generic_amplitude: 0.0014211
                  type: 'AML'
              category: 'point'
                  unit: 'm'
           waveform_id: WaveformStreamID(network_code='BK', station_code='DANT', channel_code='HHE', location_code='00')
        magnitude_hint: 'ML'
       evaluation_mode: 'manual'
     evaluation_status: 'reviewed'

[salichon]

Hi @CallumNZ having had a quick look at the xml files the amplitudes are associated to a pick (or not) and yeap the amplitudes are measured from a reference time over a time window:

` ....

2019-03-15T23:18:15.31813Z -31.744999 16.325 ` This seems indeed actually to not indicating you the "time" of the largest amplitudes. (NB : most of these are likely automatic ones.) When manually (in details) reviewing amplitudes in seiscomp3 the operator is choosing a time window which is containing an inferred max amplitude to derive the magnitude --> The amplitude time window must be much smaller then. Now you can check:https://service.geonet.org.nz/fdsnws/event/1/query?eventid=2019p620108&format=xml This is for OTVZ HH: `amplitude publicID="smi:nz.org.geonet/Amplitude/20190818104118.523928.21131"> MLv 0.07577646243 2019-08-18T10:34:14.943131Z -0.69 0.11 0.4154191189 smi:nz.org.geonet/20190818.103414.30-AIC-NZ.OTVZ.10.HHZ manual` It looks to me that the timing is correct and amplitude well indicated in time, hence I reckon then that the amplitude attribute "reference time" is what you re looking for Cheers jerome 

[CallumNZ]

@salichon @calum-chamberlain 👍

[calum-chamberlain]

@salichon thanks for that - just to check: For manually corrected amplitudes the reference time is the maximum amplitude, but for automatic ones it isn't? And the associated pick is never the time of the maximum amplitude?

[salichon]

@calum-chamberlain I haven t check the automatic solutions

• it s probably the same information (though the amplitude measure might not be always relevant :) ) It was easier on a reviewed event,

the associated pick is never the time of the maximum amplitude ?

unless it has the largest amplitude - So yes i deem to consider associated pick time =/= max amplitude time

Cheers PS sorry @CallumNZ ! Jerome

[calum-chamberlain]

Thanks for all the helpful info guys - I remain somewhat befuddled by the QML standard in certain places and have sent them an email to seek clarification on where stuff like this should be, mostly for some conversion things for obspy.

Happy to close this and thanks again!