-
Notifications
You must be signed in to change notification settings - Fork 529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SACPZ format output is not in radians per second convention #3334
Comments
Sorry this got overlooked somehow.. nice catch and this should be an easy fix. I'm just confused right now with |
I believe it's because the conversion to radians/sec is done prior to converting from velocity to displacement (by adding a zero). The original response in In [1]: 100.295 * (2*3.14159)**(4-2)
Out[1]: 3959.4812047591577 Now, I do not readily have a good answer why that order of operations is correct. For what it's worth, reviewing the rdseed source code, it's done in that order, and likely why the service is following suit. |
Ah, I overlooked that it's also changed to displacement.. 👍 |
Well the sac convention is that data are in nanometers / displacement, although I think it's common for folks to work in meters also and just skip converting to nanometers. A quick search of the source code and it does not appear that sac reads the
but really, following the use of any SACPZ file for deconvolution, the data are in whatever units the SACPZ describe. At the DMC we convert the time dimension to displacement and leave the length dimension as it is, but it is very commonly meters and so that becomes presumed unit. |
Should be fixed now, hope the simple fix covers all scenarios |
Avoid duplicates
Bug Summary
Poles and zeros are expected to be in radians per second by the sac program, and likely other programs that read these files. Furthermore, there is no annotation or indication in the format that would indicate any other units.
A simple conversion of StationXML, which allows the units to be either rad/s or Hertz, to "SACPZ" does not convert to rad/s. An example of such a conversion using a StationXML response with a PZ (Laplace) response stage in Hertz is as follows:
G_CAN__LHZ.xml.gz
Never mind the multiple PZ error, the initial set is what we need.
The first PZs are converted to "SACPZ" format, but with the PZs, A0 and CONSTANT in Hertz. There is no indication of units. Even if there were units noted, the sac program would not recognize them. Using this "SACPZ" file with sac, and possibly other programs, will result in completely incorrect transform with the user having no indication that anything is wrong.
I suggest that when writing "SACPZ" format that the units are consistently in radians per second to avoid confusion and quiet data corruption. A correct conversion from the test StationXML to SAC PZ (by irisws-sacpz) to rad/s would look like:
There does appear to be some code to convert to rad/s, but only when attaching responses to traces. In that case the caller must know the units a priori to know if a conversion is needed. This is the case even when attaching PZs from RESP, which is weird as the RESP specifies the units.
Code to Reproduce
No response
Error Traceback
No response
ObsPy Version?
1.4.0
Operating System?
macOS
Python Version?
3.11.4
Installation Method?
None
The text was updated successfully, but these errors were encountered: