I am a user of ITERDECON (from Dr. Ammon) and SACITERD (from Dr. Herrmann), and I realized that the RFs from both programs with a Gaussian parameter of 2.5 resemble the traces of the rf package when the Gaussian parameter is 0.5. Am I correct? Here is the line of code:

Thanks for the relevant question!
I remember I looked that up before. I had to look it up again

Short answer: The parameters are related like gauss_rf = 0.45 * gauss_id

Long answer:

The wiggles of the orange curve (rf) appear to have a longer period than the blue wiggles (id, iterdecon).

In the rf package the gauss parameter is defined as

gauss – Gauss parameter (standard deviation) of the Gaussian Low-pass filter, corresponds to cut-off frequency in Hz for a response value of exp(-0.5)=0.607.

You chose 0.5 for rf’s gauss, that is a 0.5 Hz lowpass → periods will be ~2s or larger → “rf peaks” will be >2s apart, which is what you observe in your plot (fist peak at 0.5s, 2nd at >2.5s).

Looking at the code, the definition of the filter response in frequency domain is

exp(-0.5 * (f/gauss_rf) ** 2)

I do not know the definition of the gauss parameter in iterdecon, but looking at the code of iterdeconvd.f, lines 518-566 the Gaussian filter response should be

gauss_id 2.5 would be equal to gauss_rf of 1.1. And indeed, higher frequencies are still present for the iterdecon curve, there is a small peak at ~1.5s in the blue curve.

TBH, I do not know why the two rfs look different. At least they show similar features. Could be that the two codes handle the iterative deconvolution slightly differently. @hfmark contributed the iterative deconvolution code to rf, maybe she knows more.

It’s been a while since I wrote the function so I don’t remember all of what I did to test it, but I think I was mostly checking that it gave similar results to the other decon methods in the package. I’m also not sure why the two look different, to be honest; in theory the method is all the same.

You might want to first check the sac vs obspy filters to make sure they’re doing similar things to your input data. You can also try using the private methods in rf that construct the gaussian filter to take a look at the pulse width you get for a given gauss parameter and see if it matches your expectations. I’ll note that normalization in Ammon’s codes is handled in particular way (the last section of this webpage: "Receiver Function Source Equalization") so perhaps that is part of it?