Searching in a catalog for xrfreq='YS' will not match the entries where that frequency is written as AS-JAN. Same thing for QS vs QS-APR vs QS-JUL vs QS-OCT (and the other 2 groups).
Potential Solution
I see three solutions:
In search, expand the requested list with all equivalent xrfreq.
Normalize all frequencies that come in the catalog.
Number 2 is my favorite, but the issue is that we don't control all the ways to add entries to the catalog. I guess the normalization could be run upon loading the catalog, as well as in update.
Additional context
xr.infer_freq always returns : AS-JAN, QS-OCT, QS-NOV or QS-DEC. compute_indicators will usually use infer_freq to find the frequency to use in the catalog. Thus, if one passes freq='YS', there's an inconsistency between the output catalog and the input yaml. Only fixing the annual case is easy, but it becomes inelegant when we want to fix the seasonal cases too.
Contribution
[X] I would be willing/able to open a Pull Request to contribute this feature.
Addressing a Problem?
Searching in a catalog for
xrfreq='YS'will not match the entries where that frequency is written asAS-JAN. Same thing forQSvsQS-APRvsQS-JULvsQS-OCT(and the other 2 groups).Potential Solution
I see three solutions:
search, expand the requested list with all equivalentxrfreq.Number 2 is my favorite, but the issue is that we don't control all the ways to add entries to the catalog. I guess the normalization could be run upon loading the catalog, as well as in
update.Additional context
xr.infer_freqalways returns :AS-JAN,QS-OCT,QS-NOVorQS-DEC.compute_indicatorswill usually useinfer_freqto find the frequency to use in the catalog. Thus, if one passesfreq='YS', there's an inconsistency between the output catalog and the input yaml. Only fixing the annual case is easy, but it becomes inelegant when we want to fix the seasonal cases too.Contribution