add pressure (PA) to response unit_map

[filefolder]

minor idea, but I do run into this sometimes working with hydrophone responses, particularly when trying to recalculate_overall_sensitivity. the label isn't relevant to the code and just seems to act as a safety.

any harm in simply adding "PA" to line ~993 of core/inventory/response.py?

e.g.

        unit_map = {
            "DISP": ["M"],
            "VEL": ["M/S", "M/SEC"],
            "ACC": ["M/S**2", "M/(S**2)", "M/SEC**2", "M/(SEC**2)",
                    "M/S/S", "PA"]}

any other instances I'm forgetting? unfortunately my master branch is still tied up in another PR so can't make this myself.

[megies]

These unit mappings do have implications during response removal (controlling whether additional integrations/differentiations are done), so this would need real thorough looking in to.

[megies]

I don't really think we want to add non DISP/VEL/ACC units in there as this might have weird side effects when passing into remove_response / evalresp, compare #2945

Closing this for now, feel free to reopen if needed

[filefolder]

I am still hoping to resolve this as there doesn't seem to be a way to create non-standard responses in obspy (e.g. PA).

reading this section you highlighted from the evalresp manual

(6) The units argument is one of the following: DIS (displacement), VEL (velocity), ACC
(acceleration), DEF (default units), and represents the units for which the output response
should be calculated (regardless of the units that are used to represent the response in the
RESP file). If Default Units are chosen, the response is calculated in output units/input units,
where these units are exactly the input units of the first stage of the response and the output
units of the last stage of the response. This is a useful alternative if the units for a particular
type of sensor (e.g. a pressure sensor) are not in units that can be converted to displacement,
velocity, or acceleration. The default value for this argument is VEL.

could we do something like...

        unit_map = {
            "DISP": ["M"],
            "VEL": ["M/S", "M/SEC"],
            "ACC": ["M/S**2", "M/(S**2)", "M/SEC**2", "M/(SEC**2)",
                    "M/S/S"],
            "DEF": ["PA", "SEC", "CELSIUS", "C", "A", "PERCENT"]}

where SEC is seconds, C is also celsius, A is colomb/sec, percent I guess would be battery or something. just browsing a random TA network station.

[megies]

as there doesn't seem to be a way to create non-standard responses in obspy (e.g. PA).

What exactly is not working? You should be able to still use these responses, the only thing that will not work should be telling evalresp to integrate/differentiate during response removal (with the output="..." kwarg). The rest should work, or am I missing something @filefolder

[megies]

Ah I see, there might be an issue with calculating overall sensitivity in that case? I think it would be best if you set up a real world example showing what is not working and what is supposed to be the expected result.

[filefolder]

yes... we have a very rare breed of Guralp OBS here and as far as I can tell they have an actual laplace transform response with poles and zeros etc, and not a simple linear counts/pressure value which appears to be more standard.

so when using the "recalculate overall sensitivity" helper I get this

~/.local/lib/python3.8/site-packages/obspy/core/inventory/response.py in recalculate_overall_sensitivity(self, frequency)
   1001                    "displacement, velocity, or acceleration - overall "
   1002                    "sensitivity will not be recalculated.") % i_u
-> 1003             raise ValueError(msg)
   1004 
   1005         # Determine frequency if not given.

ValueError: ObsPy does not know how to map unit 'PA' to displacement, velocity, or acceleration - overall sensitivity will not be recalculated.

the solution seems easy enough (recalculate it manually) but I am just wondering how unusual my circumstance is, and if there are other rare (?) units such as temperature that may trigger this, and if there isn't some catch that could be implemented to let them through.

edit attached is the HDH hydrophone channel of one station. so, I guess what my expected result would be for it to multiply all the stages and give a correct overall sensitivity as normal example_hydrophone_response.xml.txt

[megies]

@filefolder I added a minimalistic fix, seems to work as intended. I'm not sure if/what benefits it would bring to define PA as PRESSURE in there.. seems to work with just DEF (default units). Let me know what you think

[filefolder]

Thanks! Seems perfectly reasonable and I don't think any extra elaboration is really needed.

Now that I understand what the underlying issue was a bit better I could have easily avoided this in several ways, but hopefully helpful for anyone else in the future.