Errors in landcoverFrac in CESM2 and CESM2-WACCM CMIP6 data

[bascrezee]

While working on ESMValGroup/ESMValTool#1370 I ran into the following CMORCheckErrors:

esmvalcore.cmor.check.CMORCheckError: There were errors in variable grassFrac:
typenatgr: does not exist

esmvalcore.cmor.check.CMORCheckError: There were errors in variable treeFrac:
typetree: does not exist

I can confirm that typenatgr and typetree are not on the files. Why are they expected? How to deal with this discrepancy?

[valeriupredoi]

see ESMValGroup/ESMValTool#1272 (comment)

[zklaus]

It would be really good to have an example of a file that files.
@bascrezee, could you perhaps paste the offending {dataset:...} line here?

[bascrezee]

It would be really good to have an example of a file that files.

    - {dataset: CESM2, project: CMIP6, grid: gn, exp: historical, ensemble: r1i1p1f1}


Variables: treeFrac; grassFrac; shrubFrac; cropFrac

[zklaus]

Thanks, @bascrezee !

[zklaus]

Ok this actually seems to be simply a bug in the CESM2(-WACCM) data. Could you try with one of the other models that provide the data, ie

• UKESM1-0-LL
• HadGEM3-GC31-LL
• MPI-ESM1-2-HR

?
If that works, we just have to write the fix for CESM2.

[bascrezee]

Yes, I can confirm, that it works fine for the following:

    - {dataset: UKESM1-0-LL, project: CMIP6, grid: gn, exp: historical, ensemble: r1i1p1f2}
    - {dataset: HadGEM3-GC31-LL, project: CMIP6, grid: gn, exp: historical, ensemble: r1i1p1f3}
    - {dataset: MPI-ESM1-2-HR, project: CMIP6, grid: gn, exp: historical, ensemble: r10i1p1f1}

[zklaus]

Great! Could you prepare a PR for the CESM2(-WACCM) fix?
I'd like to see the add_scalar_typeland_coord refactored into a add_scalar_area_type_coord function that takes both the value and the long_name.

Then this can be applied to the model in question with the information from CMIP6_coordinate.json and similar blocks in the same file.

[bascrezee]

Great! Could you prepare a PR for the CESM2(-WACCM) fix?
I'd like to see the add_scalar_typeland_coord refactored into a add_scalar_area_type_coord function that takes both the value and the long_name.

Then this can be applied to the model in question with the information from CMIP6_coordinate.json and similar blocks in the same file.

This does not have a too high priority for me, also I prefer to wait until we have a broader overview of the problem. I would like to push forward the new functionality suggested by @valeriupredoi in #307, this would be very helpful for me.