Convert [length] into [length]/[time] when cell_methods and/or standard_name allows it

[bzah]

Generic Issue

• xclim version: 0.38

Description

There are precipitation datasets, such as E-OBS, that bear a [length] units (usually "mm") that could be interpreted as a [length]/[time] (usually "mm/day") when computing climate indices.

I think xclim.units.convert_units_to could handle such cases when the input is a DataArray.

Two parameters would help us find if this conversion would be safe:

• if cell_methods contains "time: sum", it means it's an accumulation over time.
• if the variable standard_name is the CF thickness_of_rainfall_amount:

"Amount" means mass per unit area. The construction thickness_of_[X_]rainfall_amount means the accumulated "depth" of rainfall i.e. the thickness of a layer of liquid water having the same mass per unit area as the rainfall amount.

Note that "cell_methods" seems to be missing from e-obs datasets, so it might not be the best idea to use that.

---

What do you think about that ?
If you are okay with adding this feature, I can implement it.

ref:

• icclim issue: icclim cannot deal with precipitation unit (and variable name) from E-OBS dataset cerfacs-globc/icclim#195 (comment)
• e-obs: https://surfobs.climate.copernicus.eu/dataaccess/access_eobs_months.php
• cf: https://cfconventions.org/Data/cf-standard-names/current/build/cf-standard-name-table.html

Code of Conduct

• I agree to follow this project's Code of Conduct

[aulemahal]

The conversion should be done with xc.core.units.amount2rate I think.

But indeed, an automatic conversion for some specific variables could be interesting. We already do automatic conversion between precipitation rate in [length]/[time] and [mass]/([area][time]).

EDIT: I am indeed doubtful that using cell_methods is a good idea. In my experience, this field is often missing or simply wrong.