search

cmip6dr / CMIP6_DataRequest_VariableDefinitions

Definitions of variables in the CMIP6 Data Request
7 stars 0 forks source link

Review of release 01.00.30beta1 #387

Closed martinjuckes closed 5 years ago

martinjuckes commented 5 years ago

I have reviewed the beta release of Data Request 01.00.30 with a focus on its potential impact on CMOR3 and other CMIP6 "infrastructure".

Most of the changes have been to the "comment" and "long_name" attributes and are mainly "clean-up" in nature, as opposed to substantive changes. I think these changes will have minimal impact on the infrastructure. There will be some impact of the following changes (but I think we should make them anyway):

  1. The standard names for zmlwaero and zmswaero in table E6hrZ were corrected. This means that someone retrieving data using the old standard names will get the wrong data sets.

  2. In table Emon, the label (table entry label) for the variable output as "sw18O" was corrected for consistency; it was "O18wv", and is now "sw18O". This means that those writing output fields will have to modify their codes to use the corrected table entry label.

  3. In table Emon, the label (table entry label) for the variable output as "lw18O" was corrected for consistency; it was "sw18O", and is now "sw17O". This means that those writing output fields will have to modify their codes to use the corrected table entry label.

  4. The modeling_realm for vegfrac in table Eyr was missing before, but now correctly is set to "land". This may affect those searching for data that was previously written with modeling_realm="".

  5. In table Ofx, the table entry label for "ugrido" was made consistent (changed from "ugrid" to "ugrido"). This means that those writing output fields will have to modify their codes to use the corrected table entry label.

There is an issue raised on the CMOR tables repository noting that dimension "olayer100m" should have the bounds (0., 100.), as correctly recorded in the boundsValues descriptor, but the "bounds" descriptor should be set be set to "yes", not "no". Can this be corrected before releasing 01.00.30?

In summary, I think we should go ahead with release 01.00.30 unless someone at the Hadley Centre or elsewhere identifies potential problems.

best regards, Karl

P.S. you might include some of the above info. in your release notes.

martinjuckes commented 5 years ago

The olayer100m issue has been resolved. I'll link to this issue from the release notes.