search

krischer / instaseis

Instant high-frequency seismograms from an AxiSEM database
http://instaseis.net
Other
52 stars 23 forks source link

Allow higher sampling rates for the custom source time function #44

Closed krischer closed 6 years ago

krischer commented 8 years ago

From @sstaehler in #43

Just one more nagging: The discussion on the sampling rate of STFs stopped abruptly, some time ago. In the meantime, there was a discussion between several QuakeML stakeholders and STFs will most likely be a part of the "Basic Event Description" package of QuakeML 1.2. Usually they will have higher sampling rates than the typical Instaseis databas. Therefore, I think it will be necessary that Instaseis can handle the case that STFs have a higher sampling rate than the database.

Great news, as that's really missing in QuakeML right now.

There is no always correct method for this but Instaseis could handle it in one of four ways:

  1. Upsample the seimograms and then convolve - this unfortunately will introduce high and not simulated frequencies into the seimograms and thus might confuse users.
  2. Downsample the STF with an acausal/zerophase filter - this will not shift the peak arrival but might introduce lots of energy before the actual arrivals. This effect is potentially quite strong, especially for lower frequency databases.
  3. Downsample the STF with a causal linear phase filter - this preserves causality but the seismograms will appear shifted in time.
  4. Downsample the STF with a minimum phase filter - this would be nice but unfortunately the phase is no longer linear and thus the seismograms are distored.

I guess number 2 makes the most sense.

Additionally all methods that downsample the STF will require some careful tapering of the resampled STF. Also the design of the lowpass filter is not trivial.

All in all this will be quite complicated to implement so that it always works - that's why I opted to just push that responsibility to the user for now. But if really required we can get it done it I guess.

sstaehler commented 8 years ago

@krischer True, it is non-trivial, but once we have more file formats that naturally contain STFs, it's almost impossible to push that responsibility to the user.

I think that 2 & 3 are the ways that most users would find "natural", so we should support them. My guess is that most users would find 3 (causal filter) the default behaviour, since it allows to keep the beginning of time windows for waveform measurements fixed with respect to the arrival time. But in the end, supporting 3 as default and 2 as an option should not be much additional work.

krischer commented 8 years ago

I agree :smile:

I'll postpone this for a while as I think its not crucial for now. This might give us enough time to get a proper aliasing/downsampling filter into ObsPy which we could then just use here.

alexhutko commented 8 years ago

I also like no phase shift for default which pushes users to use a higher freq database or make a more appropriate STF themselves if they are worried about this. Making #2 an option is fine. Any rough estimates when this well get into ObsPy, in the next release? Weeks? Months? danke.

krischer commented 8 years ago

Just to be clear: option number 3 would introduce a phase shift but the resulting signal is causal. Option number 2 has no phase shift but the signal becomes acausal - this is also what currently happens with the sourcewidth parameter as I guess that is what most people expect.

Any rough estimates when this well get into ObsPy, in the next release? Weeks? Months?

As it is most likely me who is gonna do it I can influence this ;-) This is not straightforward to do but I think we have a reasonable idea on how to go about it. I'd say end of September is realistic.

krischer commented 6 years ago

Closing as I don't think we'll do something about it in instaseis.