Multiple pole/zero response elements result in discarded stages, which is incorrect

[metempleton]

When combining a SeismoWave MB3a and SARA SL0632 datalogger, the combined response has two consecutive analog pole/zero stages, resulting in the following message:

"yasmine-backend | /usr/local/lib/python3.12/site-packages/obspy/core/inventory/response.py:1935: UserWarning: More than one PolesZerosResponseStage encountered. Returning first one found."

This response is incorrect without both paz stages (1. sensor, 2. analog anti-alias filter) and it must be allowed. Below is the NRL ws call for the two instruments that generated this Yasmine message:

https://service.iris.edu/irisws/nrl/1/combine?instconfig=sensor_SeismoWave_MB3a_LP100_HF27_SG0.02_STairPressure:datalogger_SARA_SL0632_FTactive_FV40Vpp_AB30_FR100&format=resp&nodata=404

[rcasey-earthscope]

Hi Mary. To clarify, we should pull both PAZ stages from the sensor, is that correct? Would a datalogger ever have a PAZ stage, thereby simplifying the logic?

[metempleton]

No. Dataloggers do sometimes have analog PAZ stages. That's what broke Yasmine in this case.

Yasmine should not include logic regarding how many paz elements to require or disallow. It should assume the user and NRL are returning what is actually needed.

The new NRL is flexible enough to let users cascade a sensor (1 PAZ), amplifier (>= 1PAZ) and datalogger with analog filters (>=1 PAZ) - and that's just for seismology. Imposing random restrictions runs the risk of biting us in the future as we add more non-seismic instrumentation.

[rcasey-earthscope]

Thanks. So in the bundled .zip file provided by NRL v2, we not only allow all PAZ stages that appear in the RESP files, but we combine both the sensor and the datalogger stages *without cutting anything out* except for stage 0? Is stage 0 then completely reconstituted in Yasmine for the final combination?

…

On Mar 13, 2024, at 7:27 AM, Mary Templeton ***@***.***> wrote: No. Dataloggers do sometimes have analog PAZ stages. That's what broke Yasmine in this case. Yasmine should not include logic regarding how many paz elements to require or disallow. It should assume the user and NRL are returning what is actually needed. The new NRL is flexible enough to let users cascade a sensor (1 PAZ), amplifier (>= 1PAZ) and datalogger with analog filters (>=1 PAZ) - and that's just for seismology. Imposing random restrictions runs the risk of biting us in the future as we add more non-seismic instrumentation. — Reply to this email directly, view it on GitHub <#48 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFL4VN2MTEROC2PE6OZMFRTYYBO5FAVCNFSM6AAAAABEHXOYOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJUGUZTANBUGY>. You are receiving this because you commented.

[metempleton]

That's right - we still need to remove stage 0 if using RESP, but nothing else. When yasmine combines the sensor and datalogger RESPs (removing both stage 0s), it needs to create a new stage 0 or <InstrumentSensitivity> by recalculating at the frequency of this stage/element. From the examples I've seen, it appears to carry this out correctly. I'll put eyes on more examples.