groundmotion-processing
groundmotion-processing copied to clipboard
usgs
LD.MMNY.HH should not pass for event se609212
The blown-up feature on the E component looked like something was blown up during processing because the raw data looks fine. I lowered the water level to 30 from 60 and the result looks more reasonable to me.
I can't think of a simple way to automate a flexible water level in cases where a larger water level leads to some blown-up values. There is a useful plot=True parameter that obspy's removeResponse method takes for checking if the response removal is the problem.
I'm not sure if this adds much, but I plotted the sensitivity of PGA to the water level for this record. Something strange is going on with the HHE channel. It is not clear to me if this is a problem with our default water level or if something else is going on.
I redid this for a handful of other HH stations to see if this is common (vertical PGA axis now normalized and logged). To me, this indicates that the sensitivity to the water level and the ambiguity of where to set it means that we should just not use this instrument type.
processing.remove_response() has an argument output with a default value of ACC. For a velocity sensor (HH* channels), I don't think this is robust. I think we need to remove the response with output=VEL and then differentiate to get acceleration. This is how I have traditionally removed the response for broadband instruments using obspy.
Question: You said HH*, but did you mean to be this restrictive? Should this apply to ?H? channels?
That change looks like a massive improvement in terms of stability. That said, the HHE channel of LD.MMNY looks like it is still going to be problematic. Also, WI.DHS looks funky so I'll look into that one further, but that is more of an exception than the rule.
So we've improved the sensitivity to water level, but the original issue is the unrealistic spike in HHE and it still remains. @smithj382 is looking into the spike removal algorithm in issue #218. We might just adapt this to identify the spike and label this as "failed." This is the waveform, processed with the new code that uses output="VEL" and then differentiates the result.
Also, note that WI.DHS.HH (the other suspicious one) didn't pass the SNR test.
Also, even though WY.YUF isn't sensitive to the water level, it does have a suspiciously large range in PGA across components, so I checked it at it also didn't pass the SNR test and looks like almost all noise.