search

usgs / groundmotion-processing

Parsing and processing ground motion data
Other
54 stars 42 forks source link

SAC unit conversion factor documentation #992

Closed gparker-usgs closed 1 year ago

gparker-usgs commented 2 years ago

Describe the bug Current guidance in the config file indicate that the supplied conversion factor for SAC units should be to cm/sec^2 or cm/sec. However, based on testing it seems that SAC input files should be converted to m/sec^2 or m/sec. See attached file with example -using a conversion factor to cm/sec^2 results in unrealistically large ground motions, and using a conversion factor to m/sec^2 results in ground motions with correct amplitudes.

The unit conversion guidance should be updated under the #Options for readers heading in the config file, and added to the formal documentation.

USGS feedback on SAC unit problem.pdf

ghost commented 1 year ago

Thanks for this, but I'm not sure if it is a bug. If the SAC input file is in units of g (and not counts), this implies the instrument response should have previously been removed and so the config file should not include the remove_response step (processing steps are left up to the user to define). The internal conversion from M to CM is only applied immediately after obspy's remove response is used on the data. So my interpretation is that the config file is describing the correct SAC conversion factors. Let me know if you think I'm wrong.

emthompson-usgs commented 1 year ago

@smithj382 Thanks for looking into this.

@gparker-usgs Is it possible the reason for thinking that the conversion is off by a factor of about 100 is because the units in the output tables was misunderstood? Note that the README files that are written out for each metric table indicate that the units for PGA and SA are %g, not g (and PGV is cm/s). This is unusual (and it is like that for legacy ShakeMap-related reasons) and I could imagine that might be unexpected for users.

emthompson-usgs commented 1 year ago

@gparker-usgs I finally figured out what is happening here. It is a bit difficult to explain the reason for it, but the issue is actually that we have a bug that is causing the conversion factor to be applied when the file is parsed (this was the original intent) but also when it is read back out of the HDF file (this was not intended). I will have a fix soon.

Based on the document that you attached, it seems like a conversion factor of about 9.81 was applied in the analysis (when the bug was present), meaning that a factor of 96.2361 was actually applied when a factor of 981 should have been applied. So I think that any previous results will either need to be re-run or adjusted by a factor of 10.19368.