Variable information from recipes overwritten by cmor table info when deriving custom variables

[remi-kazeroni]

Describe the bug
In #2396, it was found out that variable information (e.g. frequency) specified in a recipe to derive a custom variable can be overwritten by reading cmor tables and this can lead to inconsistencies like in the case of ERA5 hourly data. It is not clear if this issue only affects ERA5 variable derivation for hourly data or other datasets/variable derivations as well.

Below is an example where the 1hr frequency used for ERA5 hourly variable is overwritten to 1hrPt when deriving custom variables. Consequently, input variables needed for the derivation are not found and the recipe fails.

Please attach

• The recipe that you are trying to run, you can find a copy in the run directory in the output directory:
  recipe_check_era5_hourly_derive.yml.txt
• The main_log_debug.txt file, this can also be found in the run directory in the output directory
  main_log_debug.txt

[schlunma]

Moving this to v2.6 since there is not open PR yet.

[bouweandela]

Background information: the recipes fails for variables:

• rlus: derived from rlds (surface_thermal_radiation_downwards) and rlns (surface_net_thermal_radiation)
• rsus: derived from rsds (surface_solar_radiation_downwards) and rsns (surface_net_solar_radiation)

All of these from Table 3: surface and single level parameters: accumulations shown here so have frequency 1hr.

Since there is no entry for these variables in the CMIP6 E1hr table, the most frequent frequency in that table is used which is 1hrPt.