Difference in Sa values

[diegoclaros]

Comparing the values of the response spectrum of pseudo-accelerations (Sa) obtained from gmprocess and other independent code, I find important differences for the small periods. for example in gmprocess for a period of 0.01 sec. the response may be 50% greater than the PGA, however, from a certain period onwards (0.5 sec. for records with a 20 Hz sample rate and 0.05 sec. for records with a 200 Hz sample rate), there is no differences between gmprocess and independent code.

https://drive.google.com/file/d/1_gCP6O6rwRlOxBPXaf7v22xaWq0ETOMS/view?usp=sharing

[emthompson-usgs]

@diegoclaros Can you provide additional information? It would be helpful if we can reproduce your results.

• What ground motion data did you use? Can you share it?
• What commands did you use to process the record?
• Did you get the output "report" from gmprocess?
• Can you include the the gmprocess config file?
• What processing steps did the independent code do? i.e., did it include bandpass filtering and a baseline correction?

There's a number of reasons that this difference could occur. My best guess is that it is related to the signal-to-noise ratio and the selection of the high-pass corner frequency.

[diegoclaros]

What ground motion data did you use? Below I attach 1 files that contain the raw data and processed using gmprocess. the first figure of the previous message corresponds to the event with id 19931105020706 c1993.zip

What commands did you use to process the record? gmprocess -o Processed --assemble --directory Catalog gmprocess -o Processed --process gmprocess -o Processed --report --export

Did you get the output "report" from gmprocess? yes, the report is also attached

Can you include the the gmprocess config file? In this case use the default configuration file, config_production.yml

What processing steps did the independent code do? i.e., did it include bandpass filtering and a baseline correction? for independent code use the processed record provided in the workspace.hdf file for each record.

[diegoclaros]

Hi @emthompson-usgs , I was doing some tests and I found that the file cfuncs.c on line 22, incorporates a variable "ns". This variable modifies the value of "dt" for the small periods that presented the difference, i.e., it takes a value other than 1 for those periods.

Later of reviewing the code of Dave Boore (icmpmx), i found that such variable was modified or incorporated on 05/05/2008, which purpose I ignored

So, I rebuild gmprocess redefining ns = 1 for all periods. As a result, now the gmprocess output is similar with the independent code.

At following you can see the same images from the first message, including the new gmprocess results with the modification.

May I have problems with the change proposed as solution? Thank you!

[emthompson-usgs]

@diegoclaros, thanks so much for this information and for identifying this bug. I think we hadn't noticed this before because most of our tests were using newer instruments that have higher sampling rates and we also don't tend to look at the very high frequency spectrals. This issue only expresses itself when the spectral frequency is higher than the sample rate, and it looks like the data you are using has a sample rate of 20 Hz, which is what makes it so obvious. @cbworden and I are working on a resolution that will resolve this issue while still doing the proper up-sampling, rather than setting ns=1 (which turns off the upsampling).

[diegoclaros]

@emthompson-usgs, thank you very much for your answer, I will be attentive to any changes

[emthompson-usgs]

@diegoclaros I believe that this PR has resolved this issue. Please update your code to the current master branch and try to re-run your tests. Note: there may be some minor differences at high frequencies because we are upsampling the record for the high frequency response spectra, but it should be in much closer agreement.

[emthompson-usgs]

Oops, I forgot to include a link to the PR I am referring to: https://github.com/usgs/groundmotion-processing/pull/536

[diegoclaros]

Thanks @emthompson-usgs for your update. I have incorporated a upsampling (as a function of "ns") into my matlab code, and now the results are very similar, thank you very much.