Dataset problem: Missing bounds for almost all CMIP6 models with hybrid pressure coordinate

[schlunma]

Describe the dataset issue
For almost all CMIP6 models with a hybrid pressure coordinate, the bounds for the auxiliary coordinates a (or ap) and b are not set correctly, e.g.

        double ap(lev) ;
                ap:long_name = "vertical coordinate formula term: ap(k)" ;
                ap:units = "Pa" ;
                ap:missing_value = 1.e+20 ;
                ap:_FillValue = 1.e+20 ;
                ap:cell_methods = "time: point" ;

with missing

                ap:bounds = "ap_bounds" ;

As a consequence, for all these models the bounds for the derived coordinate air_pressure is missing.

• Data file has been changed by you in any way
• Project (CMIP5/CMIP6/OBS/obs4mips/etc): CMIP6
• Full dataset description (fill out as many as you know, please):
  • dataset: BCC-CSM2-MR, BCC-ESM1, CAMS-CSM1-0, GISS-E2-1-G, GISS-E2-1-H, MIROC-ES2L, MPI-ESM1-2-HR, MRI-ESM2-0, NESM3, SAM0-UNICON
  • experiment: historical
  • mip: Amon
  • variable used: cl
• Other notes and mentions: The listed datasets are the ones where this is the only issue for cl. I will open further issues for other datasets which have this problem plus additional issues.

Paths on DKRZ
/mnt/lustre02/work/bd0854/DATA/ESMValTool2/CMIP6_DKRZ/CMIP/BCC/BCC-CSM2-MR/historical/r1i1p1f1/Amon/cl/gn/v20181126/cl_Amon_BCC-CSM2-MR_historical_r1i1p1f1_gn_200001-201412.nc
/mnt/lustre02/work/bd0854/DATA/ESMValTool2/CMIP6_DKRZ/CMIP/BCC/BCC-ESM1/historical/r1i1p1f1/Amon/cl/gn/v20181217/cl_Amon_BCC-ESM1_historical_r1i1p1f1_gn_185001-201412.nc
/mnt/lustre02/work/bd0854/DATA/ESMValTool2/CMIP6_DKRZ/CMIP/CAMS/CAMS-CSM1-0/historical/r1i1p1f1/Amon/cl/gn/v20190708/cl_Amon_CAMS-CSM1-0_historical_r1i1p1f1_gn_200001-201412.nc
/mnt/lustre02/work/bd0854/DATA/ESMValTool2/CMIP6_DKRZ/CMIP/NASA-GISS/GISS-E2-1-G/historical/r1i1p1f1/Amon/cl/gn/v20180827/cl_Amon_GISS-E2-1-G_historical_r1i1p1f1_gn_200101-201412.nc
/mnt/lustre02/work/bd0854/DATA/ESMValTool2/CMIP6_DKRZ/CMIP/NASA-GISS/GISS-E2-1-H/historical/r1i1p1f1/Amon/cl/gn/v20190403/cl_Amon_GISS-E2-1-H_historical_r1i1p1f1_gn_200101-201412.nc
/mnt/lustre02/work/bd0854/DATA/ESMValTool2/CMIP6_DKRZ/CMIP/MIROC/MIROC-ES2L/historical/r1i1p1f2/Amon/cl/gn/v20190823/cl_Amon_MIROC-ES2L_historical_r1i1p1f2_gn_185001-201412.nc
/mnt/lustre02/work/bd0854/DATA/ESMValTool2/CMIP6_DKRZ/CMIP/MPI-M/MPI-ESM1-2-HR/historical/r1i1p1f1/Amon/cl/gn/v20190710/cl_Amon_MPI-ESM1-2-HR_historical_r1i1p1f1_gn_200001-200412.nc
/mnt/lustre02/work/bd0854/DATA/ESMValTool2/CMIP6_DKRZ/CMIP/MRI/MRI-ESM2-0/historical/r1i1p1f1/Amon/cl/gn/v20190308/cl_Amon_MRI-ESM2-0_historical_r1i1p1f1_gn_200001-200912.nc
/mnt/lustre02/work/bd0854/DATA/ESMValTool2/CMIP6_DKRZ/CMIP/NUIST/NESM3/historical/r1i1p1f1/Amon/cl/gn/v20190705/cl_Amon_NESM3_historical_r1i1p1f1_gn_185001-201412.nc
/mnt/lustre02/work/bd0854/DATA/ESMValTool2/CMIP6_DKRZ/CMIP/SNU/SAM0-UNICON/historical/r1i1p1f1/Amon/cl/gn/v20190323/cl_Amon_SAM0-UNICON_historical_r1i1p1f1_gn_200001-200912.nc

Fix provided in #529.

[valeriupredoi]

@zklaus given how many models are affected by this it will be a complete nightmare to contact them individually - do you reckon we should just apply @schlunma 's fixes in #529 and mum's the word after?

[zklaus]

I think we should report the errors for CMIP6. After all, how do we expect any improvement otherwise?

I did set up a project and some workflow for this, and I would also like to have maybe a standardized form email to use. Maybe this is something we can discuss next week a bit?

[schlunma]

Apparently this is not a dataset issue: #543 (comment)

[schlunma]

(But the fix is still necessary, otherwise iris cannot read the bounds)

[zklaus]

Hm, I can't follow through completely now, but isn't the end of going through the rabbit hole started in the comment above that the bounds can not (or not easily) be computed? In that case I don't understand how the fix can produce correct bounds. What are these bounds needed for?

[schlunma]

Hm, I can't follow through completely now, but isn't the end of going through the rabbit hole started in the comment above that the bounds can not (or not easily) be computed? In that case I don't understand how the fix can produce correct bounds. What are these bounds needed for?

The bounds are present in the file (i.e. there are variables ap_bnds and b_bnds), but they are not referenced correctly (i.e. ap and b do not have their bounds=X_bnds attributes set). Thus, we do not need to calculate them manually, but only tell iris to use them. The bounds are necessary to calculate the vertical bounds of the (derived) air_pressure coordinate.

[zklaus]

Ah, ok. I'll need to have a closer look to have a proper opinion. For now I defer judgement.

[valeriupredoi]

not to me you're not 🤣 Have a look at this very useful comment #543 (comment)

[wachsylon]

Why should a have bounds? It is the
lev
coordinate that has bounds lev_bnds and in files from MPI-ESM1-2-HR this lev_bnds variable contains an attribute
formula_terms = "ap: ap_bnds b: b_bnds ps: ps
linking to the ap_bnds and b_bnds

[schlunma]

Why should a have bounds? It is the
lev
coordinate that has bounds lev_bnds and in files from MPI-ESM1-2-HR this lev_bnds variable contains an attribute
formula_terms = "ap: ap_bnds b: b_bnds ps: ps
linking to the ap_bnds and b_bnds

You are right, a/ap and b do not need the bounds attribute; it's enough to specify it in formula_terms of lev_bnds (see here). However, at the moment iris can't read these files without a fix.

[schlunma]

Fix for this exists. I am 99% sure that this data will not be fixed on ESGF (we are approaching CMIP7), so I am closing this now.