Implement nemo odec and oclim variables for cmip6 cmorization

[treerink]

The ocean 'decadal' and 'climate' variables are not produced yet by ece2cmor3. This probably will be done in a post step by an additional script.

We also first need precise definitions for the time averaging for those periods.

[treerink]

@goord testing material for this issue available now here at the bull:

/lustre2/projects/model_testing/reerink/ec-earth-3.3.0/trunk/t264/output/

This piControl run now reached 235 years.

[goord]

Will not be able to do before release

[treerink]

In principle this should be in the release, but you mean that a post ece2cmor3 script has be made for this anyway, so when it is ready it is fast and light weight to run this in a later stage? This needs some broader communication then I guess.

Or do you mean we are going to drop these variables at all, due to time shortage?

[goord]

Yes it will have to be a post-release script to do the job. We don't have to drop the variables IMO

[treerink]

The clim-dec-vars branch will probably not be merged, currently it has conflicts #451. Most likely @goord will create a new branch.

[goord]

Implementation is not feasible, but we will add the climatological and multi-year means to the output control file generation scripts, with the 'promise' that they will be implemented in ece2cmor3 in a later stage

[treerink]

We checked that for both NEMO and IFS all high frequency output is already saved for the requested climate & decadal output. The implementation of the cmorisation of these fields is postponed to a later version. However, for instance for NEMO output, one could consider to save the monthly and yearly fields so these can be later used for climate & decadal cmorisation jobs with a future release, as this is not to costly in terms of storage.

[goord]

@treerink I have been working on this in the clim branch. In this branch, ece2cmor3 will save per year a netcdf file for all climatologies/multiyear means. These should be saved in the subfolder clim of the cmor-directory. It would be nice if someone can do a test for say 10 years. A simple varlist with a mix of climatologies and normal output is sufficient. After that I can work on building the correct climatlogies/decadal means out of the cached nc files.

[treerink]

Thanks Gijs. Ok I will test. First I will continue my recent EC-Earth test-all run for another 8 years. Thereafter test this on that 10 year output.

[treerink]

I have 10 years of tes-all output now. When cmorising with the test-all json data request file, I get a clim folder with with some cmorised NEMO files (all in this clim directory, no subdirs). From IFS no files seems to be really cmorised, I see errors like:

ERROR:ece2cmor3.postproc: Unsupported combination of frequency 1hrCM with time operators ['mean within days', 'mean over days'] encountered for variable rsut in table E1hrClimMon
ERROR:ece2cmor3.postproc: Unsupported combination of frequency 1hrCM with time operators ['mean within days', 'mean over days'] encountered for variable rlutcs in table E1hrClimMon
ERROR:ece2cmor3.postproc: Unsupported combination of frequency 1hrCM with time operators ['mean within days', 'mean over days'] encountered for variable rsdt in table E1hrClimMon
ERROR:ece2cmor3.postproc: Unsupported combination of frequency 1hrCM with time operators ['mean within days', 'mean over days'] encountered for variable rlut in table E1hrClimMon

See:
/lustre3/projects/CMIP6/reerink/cmorised-results/cmor-cmip-test-all-4/t002

[goord]

Hi @treerink I have only fixed the monC and dec frequencies, and it happens to be the case that all atmospheric climatology fields are model level variables. The 1hrCM frequency should be dismissed because the IFS output is at 3-hourly frequency