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
precip units temporary replacement #143
precip units temporary replacement #143
Conversation
… before qdm and qplad calls in services
…s.train-* calls in cli in the precip case
…-units-temporary-replacement
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.
I think this is a good start @emileten. I have a couple suggestions and required changes.
-
First and most important change. We need to test this new behavior to ensure we're getting what we want both now and into the future -- I think this is especially important here because we're depending heavily on the behavior in an upstream package (
xclim
andpint
), so if they change things in their code, we want our tests to detect whether the behavior in our services changes. I think we're are going to want tests for each of thesedodola.services.train-*
anddodola.services.apply-*
. We need to show that the services run successfully with the behavior described in update precip units in cmip6 cleanup to be pint-compatible #125 with the changes from this PR. I'd use data with units"mm day -1 "
in the test case. The data can be made up synthetic data, or derived from the existing service tests. But the test should fail before this PR's changes and then pass after this PR's changes. -
In dodola.cli, you set the
units_replacement
without user input. I think I see what you're going for, but, the logic doesn't really involve the CLI -- this is about how we're handling data and downscaling biascorrecting stuff so it needs to go to thedodola.services
we're using or a new function or object indodola.core
. The logic definitely needs to get moved out of dodola.cli. The second thing is that I'm a little nervous about doing this unit replacement automatically because it feels very magical, rather than explicit. If you want to keep the magic, I'd check that the input units are what we assume they are before they get replaced. Maybe log a message saying that the replacement is happening.
@brews thanks for the thorough review 👍 have it first on my to-do list. |
@dgergel in what context did you encounter the bug that made you file this issue in the first place ? I addressed brewster's requests with a much safer approach, that is using Thanks ! |
@emileten it was that recent xclim updates included an update in the QDM and QPLAD base class that now checks units to make sure that units for ref and hist in the training step are the same. This step uses My guess is that we may not have checked what you tried, but @brews has been following this more closely than I have. |
Oh sorry, that actually is a question for me. @emileten it was the training step in QDM and AIQPD. Anyway I think it's fine to keep as is. Looks like this just needs a |
Sure @dgergel, will do that in a bit. |
Yeah. I saw the xclim changelog on this but I have not seen this fail "in the wild" with precip because of |
I think we can do away with all these log messages in dodola.services with this current setup but this merged before I could get a re-review in. Suggestion is now in #148. |
This solves #125, (precip units incompatible with the
xclim
pint
registry)added an
units_replacement
parameter to eachservices.apply-*
andservices.train-*
function, to (optionally) temporarily swap thevariable
units
attribute for a chosen string, during bias correction and downscaling.this option is used in each upstream
cli
function ifvariable=='pr'
to temporarily swap units with"mm/day"
.@brews (1) is general (variable agnostic) in case we want to make use of that in other cases, but (2) doesn't give an option and uses it for precip -- so that we don't need to change workflow templates now. I didn't write a unit test, it sounded like a lot of code to me for what it is. I am not fully aware of our test coverage ambitions though. Let me know.