I would like to analyse ambient noise from different instruments (Geophone, BroadBand, accelerometer…) by using ObsPy’s PPSD. It is therefore necessary for me to have the same unit for the PSD estimation in order to compare them (from different instruments).
For example if my raw data are in velocity (geophone sensor), does ppsd estimation automatically convert it into acceleration, as it shows [(m/s²)²/Hz] [db] when we plot ? Then what if raw data are in acceleration (accelerometer sensor)?
Basically, no matter what units your input data, the metadata should
correctly specify how to get to physical units from that starting point.
Usually raw data are in counts and the metadata specifies how to get
from counts to velocity in m/s or to acceleration in m/s**2 in case of
accelerometers.
If your data already is in e.g. velocity in m/s, you ideally should set
up a proper response, basically stating input and output units are both
m/s and that nothing has to be done, e.g. have a look at this ticket, to
get an idea what i mean: https://github.com/obspy/obspy/issues/2408
Thanks for your response, I understand this particular case, when the response is already corrected in the data.
The reason why I was wondering about the output value of PPSD is that, in the source code you multiply the PSD value by (2PIf)² (= Omega²) when removing instrument response for special_hanging = none.
When you do this multiplication by Omega, does that convert into acceleration? Since on the PPSD plot, it is marked [(m/s²)²/Hz] (when we don’t specify special_hanging).
Sorry if this is a stupid question, the reason is I’m learning by myself, so I don’t have plenty notions on it.
In all cases, we request response correction to velocity from underlying
evalresp, and then go to acceleration in frequency domin like you
mentioned. If the station metadata you provide (e.g. StationXML) states
how to convert e.g. counts to acceleration, evalresp should account for
us requesting velocity.
So, it should be alright. However personally I do not use accelerometer
data, so double checking can never hurt and being cautious is always a
good idea. Although I would imagine that we have quite a few users
working with accelerometer data. So if there was a drastic problem like
that it should have surfaced by now, I would think, as it would produce
values that are off by a mile or two.
Another double check you could do with a publicly available
accelerometer is e.g. requesting the PQLX plot from IRIS' mustang and
comparing with an obspy calculated version. That would be comparing to
completely separate codes.
Like stated before, such tinkering should not be needed in most cases like "Stream.remove_response()" or in PPSD processing. Evalresp can take care of it, based on the station metadata in an Inventory object, coming from StationXML, via FDSNWS or dataless SEED etc.
For remove_response you can specify the output units (DISP, VEL, ACC, see docs) and evalresp will take care of it.
Tinkering with poles/zeros should only ever be needed if you really only use a plain poles and zeros dictionary, which should always be the last resort.