How to get OBS data with different frequencies that are not hourly, daily or monthly?

[morobking]

I'm writing CMORisers that extend the CDS LAI and CCI LST to higher temporal frequencies.
CDS LAI is 10 day, and CCI LST will be twice daily at satellite overpass time.
Later this will extend to CCI LAI data which has a 5 day frequency.

For the CDS LAI, CMORising with monthly or daily frequency (Lmon and Eday) means that when a recipe loads these data you get errors from https://github.com/ESMValGroup/ESMValCore/blob/main/esmvalcore/cmor/check.py
saying 10day "is not recognised", day gives "mismatch between frequencies"
This happens when the data is CMORised as both Lmon and Eday.

How can 10 day time frequency be CMORised and then loaded by ESMValTool? And by extension 5 day data?
Similarly, I suspect the LST at twice daily at satellite overpass times will need a similar solution.

[bouweandela]

What would be the purpose of CMORizing to these frequencies?

As far as I'm aware, there are no climate models that produce data at these frequencies, at least not in CMIP or CORDEX, so comparing this data with climate model output wouldn't directly be possible and to me, that is the purpose of CMORization.

[morobking]

For LAI: With new CCI LAI V2 coming soon, this will have a 5 day frequency. In the interim, we would like to use the CDS LAI data which has 10 day frequency - with a current CMORizer only taking one value to give a monthly LAI value. Our work will look to use these higher frequency datasets. There is the possibility to compare to other observation datasets and to land surface models, as well as what we can do with the CMIP6 archive.

For LST: It would be possible to to CMORise (it is needed to correct/change a couple of things) each platform's ascending and descending files separately (similar to the previous work I have done with infrared LST CCI data with its day and night overpasses). Rather than making new CMOR tables like I did for ts_day and ts_night (see ESMValGroup/ESMValCore#2458) use only ts but have different file name for ascending and descending. @axel-lauer would this be an acceptable solution? In this case we would still need to do the same calculations/analysis but just with 4 loaded cubes rather than 2. I can't see that being a problem as I do that 'outside of ESMValTool' anyway with Iris.