[CORDEX] Support 3hr ?

[aulemahal]

For CORDEX-CMIP6, I have some data that we only have at the 3hr frequency. I was under the understanding that it was appropriate to publish those to the ESGF even though there is no "3hr" table in the CORDEX-CMIP6 project.

However, the plugin defined here is not able to fully check my dataset as it can't find the reference metadata. The time checks also fail.

In my cmorization code, I pull the « higher resolution » table when this happens, so in the case of 3hr, I look into the 1hr table. Would this kind of relaxation be of interest here ? If so, I could try my hand at implementing it in wcrp_base.py. This part is shared, but I guess this change could be made be specific to CORDEX.

[sol1105]

For CMIP7 this is correct, here the CMOR tables do not include frequency and one can specify it as needed (though it is recommended to follow the data request in that regard).

For CORDEX-CMIP6 the CMOR tables prescribe the frequency and I am not aware of the prescribed frequencies not being mandatory. @jesusff @larsbuntemeyer Is it permitted to provide variables at different frequencies than the ones prescribed by the CORDEX-CMIP6 CMOR tables and data request?

[jesusff]

It is always better to have 3hr data than nothing at subdaily scale, so we decided in the last TTPI meeting to enabling this possibility by providing CMOR tables for 3hr data (replicating all attributes from the 1hr ones), even though they are not in the default request nor in any of the domains.

WCRP-CORDEX/data-request-table#102

These new tables should do the magic when considered by the checker, right? Or will it need some adjustment?

[aulemahal]

Now that the PRs are merged, I'll try to check if it all works smoothly for detecting the new variables.

However, there are a few checks in here that have hardcoded lists of supported frequencies, without 3hr.

I think one thing that could maybe need discussion is whether to assume 3hr data is an average or instantaneous. In the PR to the data table, I assumed 3hr data would have a cell method of time: point if the entry at 1hr had that. Meaning, 3hr is not to be used as a post-processed resampling of finer frequencies but as an alternative to 1hr directly at the model level.

[sol1105]

The tables are hardcoded in plugins/cordex_cmip6/cordex_cmip6.py, adding "3hr" there should do the trick for now. Alternatively the path with the tables can be provided as compliance checker input option when calling it via the command line (at least I think that should work).

Hopefully soon however, we can switch fully to having esgvoc do all the variable checking, then it should not matter any more.