computation of relative humidity not sensible for upper troposphere

[joernu76]

What went wrong?

Computing relative humidity with metpy and comparing the results with our old code following the lines of
https://www.ecmwf.int/sites/default/files/elibrary/2016/17117-part-iv-physical-processes.pdf
Section 7.4.2 showed strong discrepancies at high altitudes (e.g. 8km and above). Particularly in ice clouds, relative humidity was not close (or above) 100%, which limits its usefulness quire a bit.

The current code only computes relative humidity in relation to saturation pressure above liquids. At higher altitudes, ice is more prevalent and thus saturation pressure over ice should be used.

See also here
Open-MSS/MSS#1341

This could also be seen as a Feature request; but from the perspective of analysing rel. hum at 10km for situations where ice clouds may form, this is a bug.

I can provide a MR for fixing this, the question is whether the current function should be updated or a new one created.

Operating System

Linux

Version

1.1.0

Python Version

3.9

Code to Reproduce

import metpy.calc as mc
import metpy.units as munits
mu = munits.units

pres = 10000
temp = 250
q = 0.005
print(100 * mc.relative_humidity_from_specific_humidity(pres * mu.Pa, temp * mu.K, q * mu.dimensionless).m, "%")
print("should be ~106%")

Errors, Traceback, and Logs

No response

[joernu76]

@gisi90

[dopplershift]

Well, it's not a bug (unless you count it not being clearly documented), but a limitation of the current approach (which is working completely as intended). Your desired use case is just outside the bounds of those limitations. 😉

I'm open to trying to expand to cover your use case. I'd love to avoid having all _ice variants for all of our things that rely on saturation_vapor_pressure, but that instead means having to wire some argument into the calls for all those functions (which is do-able).

~I suppose there's no really good way to do this automatically...~This is going to depend on users' applications, so we have to just provide the right hooks/api.

I'm open to a PR giving an implementation a go, but until I see what it does in terms of adding complexity to the code, I really don't know how I'm going to feel about what the right approach is.

[jthielen]

Also, tagging related issues #142 and #508.

[joernu76]

As I mentioned, I was torn how to classify this.

What about adding an (optional) parameter phase with options "liquid", "ice", "temperature-dependent"?
Obviously this adds some complexity and would also require some means to compute the saturation pressure over ice (which could again be implemented using said phase parameter, albeit with only the first two options).

I will prepare a rough draft for a PR (without doc+tests) for discussing the implementation.

[joernu76]

Added a draft. The impact seems to be reasonable. I added the "phase" parameter, where it seemed sensible. this needs to be documented, obviously.

If this approach is fine, I'd update the documentation, provide better reference and add test cases.