search

seismopy / mopy

A python package to calculate seismic source parameters
11 stars 1 forks source link

Calculating amplitudes for local magnitudes #6

Open sboltz opened 5 years ago

sboltz commented 5 years ago

I was thinking about the ChannelInfo object this morning and I am wondering if we are going to be shooting ourselves in the foot a little bit for using it to calculate amplitudes for local magnitudes?

In my existing code for calculating them, it doesn't require any picks... it just looks at a certain time window after the origin and identifies the maximum peak-to-peak amplitude in that window. With the way that the ChannelInfo object is set up, and how things interact with it downstream, it is required that picks be attached to it in some capacity. Would it be good to add an option to just have the ChannelInfo create a dummy "pick" for every event-channel pair?

Or would it be better to just have the user create picks or somehow specify time windows to calculate local magnitudes?

d-chambers commented 5 years ago

I think having different constructors for the different cases is probably the way to go. For example: ChannelInfo.from_picks(...) vs ChannelInfo.from_inventory or something along those lines. The first would create a row for each pick, the second a row for each channel/event.

sgjholt commented 5 years ago

Having time windows to search the p-to-p amplitudes isn't a bad idea though. We expect the peak amplitude to occur around the Sg arrival so having the user define picks isn't bad. The UUSS uses theoretical Sg times to start their window for their automated ML (of course they refine manually). That being said I think Derrick's solution is good, if I understand correctly it means you can calc ML with or without picks? It is good practice to have well defined windows to calculate ML however.

d-chambers commented 5 years ago

Sure, good point @sgjholt.

I guess the bigger picture. however, is becoming clear that ChannelGroup is a re-implementation of obspy.Trace.stats and TraceGroup is a re-implementation of obspy.Trace/obspy.Stream` with its own advantages/disadvantages.

To that end, we want to preserve their general usefulness as much as possible so being able to flexibly use the index is important. Some ChannelInfo instances could include the phase index, but others might not. Some might even have entirely new index levels. For example, ['channel_id', 'starttime'] could be acceptable for storing contiguous chunks of waveform data.