Phase out convert_calendar and some units processing #1010
Comments
Zeitsperre
added a commit
that referenced
this issue
Oct 25, 2022
### What kind of change does this PR introduce? * Changes how the `UnitRegistry` is declared, by copying the one from `cf-xarray`. * I also copied the declaration of the % unit from `cf-xarray` * This removed the need to import things that were refactored in `pint`0.20, so it fixes this. * It also allowed to remove the string processing stuff from `units2pint`, this is now directly in the registry's `preprocessors`. * I removed the `force_ndarray_like=True` option that `cf-xarray` uses because it made our tests fail. I haven't looked further, this is to be done in #1010. ### Does this PR introduce a breaking change? It shouldn't!
5 tasks
Zeitsperre
added a commit
that referenced
this issue
Mar 23, 2023
### What kind of change does this PR introduce? * Fixes a bug in the logic of two indices (`snowfall_approximation` with `method="brown"`, `effective_growing_degree_days`) that was emitting usage warnings from valid calls. * prepends `v` to entries in CHANGES.rst to properly generate hyperlink entries. * Warnings from set ``_version_deprecated`` within Indicators now emit `FutureWarning` instead of `DeprecationWarning` for greater visibility. ### Does this PR introduce a breaking change? No. ### Other information: See also: #1010
aulemahal
added a commit
that referenced
this issue
Jan 11, 2024
<!--Please ensure the PR fulfills the following requirements! -->
<!-- If this is your first PR, make sure to add your details to the
AUTHORS.rst! -->
### Pull Request Checklist:
- [x] This PR addresses an already opened issue (for bug fixes /
features)
- This PR fulfills some goals of #1010.
- [x] Tests for the changes have been added (for bug fixes / features)
- [x] (If applicable) Documentation has been added / updated (for bug
fixes / features)
- [x] CHANGES.rst has been updated (with summary of main changes)
- [x] Link to issue (:issue:`number`) and pull request (:pull:`number`)
has been added
### What kind of change does this PR introduce?
* The units registry is copied from `cf_xarray` and extended with
xclim's specific shortcuts (`precipitation`, `discharge` and the `hydro`
context).
* The units formatting functions are simplified by using the work
alreadty done in `cf_xarray`. We still can't get rid of `pint2cfunits`
because of pint issue that makes it impossible to format dimensionless
units are "" using its formatter tools.
### Does this PR introduce a breaking change?
Yes. As seen in the tests changes, cf_xarray's cf formatter never adds
the "^" sign for exponentiation. This does not affect the accepted
units, only the output `units` attribute.
|
This is waiting on upstream changes in xarray. |
|
PR to make some methods removed from xclim public in xarray is here : pydata/xarray#9105. Updated top post, all tasks are done except this public method thing. |
|
@aulemahal Are we good to close this? |
|
Ah ! Yes. Public methods are in xarray 2024.09. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since xarray 0.20.0, some of xclim's calendar functionality has been implemented in xarray directly. Similarly,
cf_xarray0.7.0 now replicates (with minor differences and improvements) the units string processing machinery of xclim. Which means we could phase them out of xclim using these upstream methods instead.Functions concerned:
xc.core.calendar.convert_calendar->xr.Dataset.convert_calendar,xr.DataArray.convert_calendar,xr.coding.calendar_ops.convert_calendarThe main difference is that numpy's calendar dtype is the default for "standard" and cftime's one is use when
use_cftime=Trueis requested.xc.core.calendar.interp_calendar->xr.Dataset.interp_calendar,xr.DataArray.interp_calendar,xr.coding.calendar_ops.interp_calendarxc.core.calendar.date_range->xr.date_rangexc.core.calendar.date_range_like->xr.date_range_likexc.core.units.units(the pint registry) ->cf_xarray.units.unitsThey don't implement our special "hydro" context, and I don't think they ever will.
xc.core.units.str2pint->cf_xarray.units.units.UnitSome (most? all?) of the string parsing we do by hand as moved to pint's preprocessor, through cf_xarray's registry.
UPDATE: We still implement the possibility of passing a magnitude-less unit string OR a full quantity. Also, our
units2pintsupports for input types and has as some typo catching.xc.core.units.pint2cfunits->f"{u:~cf}"Again, some of things we did by hand were moved to pint's formatters.
UPDATE : In order to support more versions of pint (and numpy) then the latest one,
pint2cfunitswill remain, even though it is now quite thin.So what is our plan for the deprecation?
I suggest we first simply make use of the upstream methods within our own API and remove them once and for all in xclim 1.0. May be adding a warning now, or at least on the last 0.x version. And we document this in the notebooks and docstrings.
The text was updated successfully, but these errors were encountered: