-
Notifications
You must be signed in to change notification settings - Fork 416
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standardize RH calcs on WMO8 #3242
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dcamron
added
Type: Maintenance
Updates and clean ups (but not wrong)
Area: Calc
Pertains to calculations
Type: API Change
Changes to how existing functionality works
Subarea: Thermo
Pertains to thermodynamic calculations and their physical correctness
labels
Oct 25, 2023
dcamron
force-pushed
the
rh-vapor-pressure
branch
2 times, most recently
from
October 25, 2023 18:20
ce93311
to
1fb9905
Compare
dcamron
force-pushed
the
rh-vapor-pressure
branch
from
October 26, 2023 21:07
1fb9905
to
9f5df67
Compare
Base all RH calculations on WMO8 standard using vapor partial pressure ratio. This includes calculations previously "directly" calculating from ratio of mixing ratios. Corrections cited. See Unidata#2951 for more info.
Beyond standardizing this calc on WMO8, dewpoint_from_specific_humidity can be simplified to not require temperature as an argument. Add an internal implementation to support this and preserve API compatibility.
Also, config ruff to support "preview" includes, or E226 check will not run on future versions.
Nothing fancy. Offer double-check suggestion for all number of versionchanged in docstring, and present them all.
dcamron
force-pushed
the
rh-vapor-pressure
branch
from
November 1, 2023 19:48
55f8e73
to
a418f4d
Compare
dopplershift
requested changes
Nov 1, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one subtle problem with the dynamic argument handling.
Test dewpoint_from_specific_humidity handling with 1 arg, 1 kwarg.
Update dewpoint_from_specific_humidity backwards compatibility layer to more completely handle mixed parameters in old function signature. Fixes array inputs and ordering of signature.
and test xarray inputs.
dopplershift
approved these changes
Nov 2, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Area: Calc
Pertains to calculations
Subarea: Thermo
Pertains to thermodynamic calculations and their physical correctness
Type: API Change
Changes to how existing functionality works
Type: Maintenance
Updates and clean ups (but not wrong)
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Standardize RH calculations on WMO8 definition of relative humidity as
(eq 4.A.15)
such that any RH calculation with input of mixing ratio is made consistent with above as
(eq 4.A.16)
As part of this process, we can also simplify
dewpoint_from_specific_humidity
to not require a temperature input. I've tried to do this in a way that allows arg and/or kwarg specification in a backwards compatible way. @dopplershift let me know your thoughts on the verbage here and how to best document this change and alert to an eventual deprecation. This does break our "check for versionchanged 1.0 and provide helpful error" handling in_check_units_inner_helper
.I'm glad to change/remove that test or look into changing that handling.Handling slightly generalized and now issue a relatively quietPendingDeprecationWarning
.I've yet to update the test values so folks can see how much changed.A few existing tests pass within tolerance but do have slightly changed values.Checklist