Provide more precise definition of RH

[ryan-feeley]

I've come across a few definitions of RH in the literature, and I'm not certain if there even is a "standard".

It appears that this package is using mixing ratios. For example, if I do

import atmos
e = atmos.calculate('e',T=30, RH=25.0, p=101325, T_unit='degC')
es = atmos.calculate('es',T=30, RH=25.0, p=101325, T_unit='degC')
print(100* e/es)

I get a result of 25.63, which is quite a bit different from the input RH = 25.0

In many fields, I see RH defined in terms of the partial water vapor pressure in relation to the saturation pressure. Given the 25.0 versus 25.63 discrepancy above, I think it would be helpful to provide a note in the section of the documentation where RH is defined indicating that different interpretations of RH can give different results when, for example, you use RH to compute AH.

[ryan-feeley]

This might be a good paper to reference regarding errors/discrepancies that can occur when different RH definitions are intermingled. It appears that calculations of Td are particularly sensitive to how RH is defined.

The Relationship between Relative Humidity and the Dewpoint Temperature in Moist Air

For example, this NOAA calculator appears to be using RH = e/es.

[mcgibbon]

In writing atmos I decided to go with the World Meteorological Organization definition. This should probably be coded as an assumption (e.g. "assumes_rh_from_mixing_ratio" or "assumes_rh_from_vapor_pressure"). Then the section in documentation on assumptions would talk about this choice.

Alternatively, you can write your own FluidSolver to use whichever definitions or set of assumptions you like.

This is a bit of an unsolvable problem, though, in that most data sources (in my experience) write relative humidity as their variable (or RH, or relhum, etc.) without saying which of these definitions they're referring to. The taylor expansion of rv/rvs is e/es + e*(e-es)/(esp) + O((ees)^2), so this really is a small correction.

Is this package actually used by people? I stopped development a while back because there weren't really users, but I could clean this up if it would actually be useful. I would still keep the mixing ratio definition as default.

[mcgibbon]

If you would be comfortable with it, you could alternately write a pull request yourself with these changes. I could give you more details about what it is that needs to be changed, and the code changes should be fairly easy. The documentation and tests would also need to be updated (which is again fairly simple).

[ryan-feeley]

Thanks for the info! I'm just an N=1, so I can't really attest to # of users. I found it in a google search since I wanted to go from (T, RH, P) --> AH via python, and it seemed well documented. Then I saw some differences with other calculators I'd used, so I poked around a little more.

I like the "assumes_rh_from_mixing_ratio" approach. I agree about the "this is an unsolvable problem" part, since yes, the definition used in data collection is often not stated. I don't mind attempting a pull request. Is the documentation also in GitHub? If so, I'll try to change the code and fall-back to just changing the documentation.

One thing that would have saved me some time investigating would be if we just added an "assumes_rh_from_mixing_ratio" to the list of assumptions, even if an alternative wasn't supported. That way the distinction could be called out both in the glossary of terms, and in the code.

[mcgibbon]

If you want to attempt a PR, these would be the changes needed:

• On line 272 of equations.py, add the new assumptions and descriptions that could fit into the sentence "This function calculates X, assuming ."
• On lines 658, 671, 677, 721, and anywhere else appropriate that you can find, add the appropriate assumption string. I'll look over the file to see if you've missed any when you submit the PR.
• Add any new desired equations in the right position in alphabetical order. For any equation that assumes RH is rv/rvs, you may want to write a new equation assuming RH is e/es (in fact, you probably should). However, you may want to write a slightly different one. For instance, instead of rv_from_RH_rvs, you should probably right e_from_RH_es for the RH=e/es assumption. Remember to include the @assumes and @AutoDoc decorators, in the right order (autodoc on top).
• If you're wondering about the overridden_by_assumptions decorator, you can just ignore it - it's not necessary here. That decorator is for equations that don't actually assume anything, but might be overridden by less accurate equations that make assumptions. In the case here, there aren't any pure equations that make no assumptions.
• Modify the documentation as appropriate in docs/source.

You may find when you check out master that the package is broken because of some dependency on a Unidata units package. If that's the case, submit another issue for that and I'll look at fixing it. I just seem to remember the last time I tried to run the package it was broken (though hopefully the version on pypi is fine).

Thanks for taking this on!

[porterdf]

+1 as a current user (potential developer). In addition to fixing some errors in the docs, I'd be interesting in some enhancements. I'll start by adding issues via GH and then start to do PRs based off these.