Expand the concept of "climatology" to include full temporal reductions

[chpolste]

Is your feature request related to a problem? Please describe.

To me, a "climatology" does not have to have a time component (like, dayofyear, month, etc.). I would also refer to a simple mean over all data as a "climatological mean".

Describe the solution you'd like

• The climatology module should recognise data without any time-like dimension as climatologies in the anomaly function.
• The frequency argument of earthkit.transforms.climatology.reduce should also accept a string like "total" (can't come up with a better name and None already does the auto-detection). When this special string is given, the function should reduce the full dataset like the equivalent function from the temporal module.

Describe alternatives you've considered

Anomalies can be computed just by subtracting the fully-reduced data from the data, but that introduces a need for branching in functions that have a broader understanding of climatologies. Same with just using the reduce function from temporal: it works, but I have to introduce an if-else or try-except to support it downstream.

Additional context

This extended understanding of "climatology" would eliminate an edge case in ecmwf/earthkit-meteo#89 and cover a use case related to percentile computations in ecmwf/earthkit-climate#34.

Organisation

ECMWF

[EddyCMWF]

Hi @chpolste ,
As we spoke on teams, some of this has already been added to the v1.0 release candidate branch. I am moving this to the develop branch at the moment as it is independant of the v1.0 dependancies.

Currently covered, the climatology.reduce,.mean, .median etc. methods will return what you describe as "total". This is similar in effect the same as temporal.reduce, .mean, .median etc, but I think it makes sense to also live in the climatology module. In addition there is a "climatology_range" argument which lets you do the sub-setting within ek-transforms.

The anomaly function can accept this, but as discussed I will modify the behaviour ahead of the version1.0 release. At the moment it will detect the frequency of the climatology and use that as the frequency of the anomaly, if no frequency is detected then it will use frequency="year". We do NOT want this. The frequency should be specified in the anomaly call, if not specified then it is returned on the time frequency of the input data array.

[EddyCMWF]

FYI, this PR (still in draft)
#90

Still working on the examples

[chpolste]

Thanks @EddyCMWF! I just ran my use cases with the changes in #90 and everything works perfectly 👍