Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dataset problem: Issues with hybrid height coordinate of UKESM1-0-LL (CMIP6) #543

Closed
schlunma opened this issue Mar 3, 2020 · 10 comments
Closed
Assignees

Comments

@schlunma
Copy link
Contributor

schlunma commented Mar 3, 2020

Describe the dataset issue
Bounds of b not set (see #536). Not sure if allowed: Does only provide altitude as vertical coordinate, not air_pressure.

  • 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: UKESM1-0-LL
    • experiment: historical
    • mip: Amon
    • grid: gn
    • version: v20190406
    • variable used: cl
  • Pointer to existing copy of data on ESGF node (it would be very useful if you could provide a physical fullpath to the file(s) that are causing the problem, e.g. on CEDA Jasmin or DKRZ):
    /mnt/lustre02/work/bd0854/DATA/ESMValTool2/CMIP6_DKRZ/CMIP/MOHC/UKESM1-0-LL/historical/r1i1p1f2/Amon/cl/gn/v20190406/cl_Amon_UKESM1-0-LL_historical_r1i1p1f2_gn_200001-201412.nc

ncdump (without global attributes):

netcdf cl_Amon_UKESM1-0-LL_historical_r1i1p1f2_gn_200001-201412 {
dimensions:
        time = UNLIMITED ; // (180 currently)
        bnds = 2 ;
        lev = 85 ;
        lat = 144 ;
        lon = 192 ;
variables:
        double time(time) ;
                time:bounds = "time_bnds" ;
                time:units = "days since 1850-01-01" ;
                time:calendar = "360_day" ;
                time:axis = "T" ;
                time:long_name = "time" ;
                time:standard_name = "time" ;
        double time_bnds(time, bnds) ;
        double lev(lev) ;
                lev:bounds = "lev_bnds" ;
                lev:units = "m" ;
                lev:axis = "Z" ;
                lev:positive = "up" ;
                lev:long_name = "hybrid height coordinate" ;
                lev:standard_name = "atmosphere_hybrid_height_coordinate" ;
                lev:formula = "z = a + b*orog" ;
                lev:formula_terms = "a: lev b: b orog: orog" ;
        double lev_bnds(lev, bnds) ;
                lev_bnds:formula = "z = a + b*orog" ;
                lev_bnds:standard_name = "atmosphere_hybrid_height_coordinate" ;
                lev_bnds:units = "m" ;
                lev_bnds:formula_terms = "a: lev_bnds b: b_bnds orog: orog" ;
        double b(lev) ;
                b:long_name = "vertical coordinate formula term: b(k)" ;
        float orog(lat, lon) ;
                orog:long_name = "Surface Altitude" ;
                orog:units = "m" ;
        double b_bnds(lev, bnds) ;
                b_bnds:long_name = "vertical coordinate formula term: b(k+1/2)" ;
        double lat(lat) ;
                lat:bounds = "lat_bnds" ;
                lat:units = "degrees_north" ;
                lat:axis = "Y" ;
                lat:long_name = "Latitude" ;
                lat:standard_name = "latitude" ;
        double lat_bnds(lat, bnds) ;
        double lon(lon) ;
                lon:bounds = "lon_bnds" ;
                lon:units = "degrees_east" ;
                lon:axis = "X" ;
                lon:long_name = "Longitude" ;
                lon:standard_name = "longitude" ;
        double lon_bnds(lon, bnds) ;
        float cl(time, lev, lat, lon) ;
                cl:standard_name = "cloud_area_fraction_in_atmosphere_layer" ;
                cl:long_name = "Percentage Cloud Cover" ;
                cl:comment = "Percentage cloud cover, including both large-scale and convective cloud." ;
                cl:units = "%" ;
                cl:original_name = "mo: (stash: m01s02i261, lbproc: 128)" ;
                cl:original_units = "1" ;
                cl:history = "2019-04-05T17:52:01Z altered by CMOR: Converted units from \'1\' to \'%\'. 2019-04-05T17:52:01Z altered by CMOR: replaced missing value flag (-1.07374e+09) with standard missing value (1e+20)." ;
                cl:cell_methods = "area: time: mean" ;
                cl:cell_measures = "area: areacella" ;
                cl:missing_value = 1.e+20f ;
                cl:_FillValue = 1.e+20f ;

Fix provided in #529.

@valeriupredoi
Copy link
Contributor

@matthew-mizielinski is this something that is already on your to-do list for future releases of CDDS? 🍺

@matthew-mizielinski
Copy link

@valeriupredoi , this is a feature of CMOR and has been discussed before, see PCMDI/cmor/issues/177 and discussions within the CF community linked to therein. I'd suggest having a chat with your local CF standards person (e.g. David Hassell) about this to get a full understanding of this one.

We can't change this without a corresponding change to CMOR and at the moment I don't see that happening on CMIP6 timescales.

@valeriupredoi
Copy link
Contributor

Brilliant! Cheers for the heads up, very helpful indeed!
I think we need to recruit @davidhassell hhere in ESMValTool land as soon as possible for such matters 🍺

@davidhassell
Copy link

Hello,

I think this file described by the CDL above is wholly CF-1.7 compliant. b(lev) does not have a bounds attribute because it is not an auxiliary coordinate variable; and it is not an auxiliary coordinate variable because it is not named by the coordinates attribute of cl. Even if b were to have such an attribute then it would have no standardised meaning.

There is, however, an alternative encoding that names b as an auxiliary coordinate variable and attaches b_bnds to b:

netcdf cl_Amon_UKESM1-0-LL_historical_r1i1p1f2_gn_200001-201412 {
dimensions:
        time = UNLIMITED ; // (180 currently)
        bnds = 2 ;
        lev = 85 ;
        lat = 144 ;
        lon = 192 ;
variables:
        double time(time) ;
        double time_bnds(time, bnds) ;
        double lev(lev) ;
                lev:bounds = "lev_bnds" ;
                lev:units = "m" ;
                lev:axis = "Z" ;
                lev:positive = "up" ;
                lev:long_name = "hybrid height coordinate" ;
                lev:standard_name = "atmosphere_hybrid_height_coordinate" ;
                lev:formula = "z = a + b*orog" ;
                lev:formula_terms = "a: lev b: b orog: orog" ;
        double lev_bnds(lev, bnds) ;
                lev_bnds:formula = "z = a + b*orog" ;
                lev_bnds:standard_name = "atmosphere_hybrid_height_coordinate" ;
                lev_bnds:units = "m" ;
                lev_bnds:formula_terms = "a: lev_bnds b: b_bnds orog: orog" ;
        double b(lev) ;
                b:long_name = "vertical coordinate formula term: b(k)" ;
                b:bounds = "b_bnds" ;   // 'bounds' attribute has meaning due to aux. coord. status
        float orog(lat, lon) ;
        double b_bnds(lev, bnds) ;
                b_bnds:long_name = "vertical coordinate formula term: b(k+1/2)" ;
        double lat(lat) ;
        double lat_bnds(lat, bnds) ;
        double lon(lon) ;
        double lon_bnds(lon, bnds) ;
        float cl(time, lev, lat, lon) ;
                cl:standard_name = "cloud_area_fraction_in_atmosphere_layer" ;
                cl:long_name = "Percentage Cloud Cover" ;
                cl:comment = "Percentage cloud cover, including both large-scale and convective cloud." ;
                cl:units = "%" ;
                cl:original_name = "mo: (stash: m01s02i261, lbproc: 128)" ;
                cl:original_units = "1" ;
                cl:cell_methods = "area: time: mean" ;
                cl:cell_measures = "area: areacella" ;
                cl:coordinates = "b";    // define b(lev) as an aux. coord. variable
                cl:missing_value = 1.e+20f ;
                cl:_FillValue = 1.e+20f ;

This encoding, or the one at the top of the page, are, from a CF perspective, equally valid.

I don't know if CMIP6/CMOR has a preference.

@valeriupredoi
Copy link
Contributor

cheers muchly @davidhassell - afraid these things are slowly getting above my paygrade and am getting more puzzlated by the interplay between CF and CMOR. Bottom lines: @matthew-mizielinski no chance we can fix this upstream in the data conversions? What do we do with the other models that behave the same way (bunch of them in the other issues) - do we contact the model providers? Ping @zklaus too
Cheers for the inputs guys 🍻

@matthew-mizielinski
Copy link

@valeriupredoi -- without changes to CMOR we cannot change this. Given that the CF community are happy with the current expression of this data (noting @davidhassell's comment and Karl Taylor's on the CMOR issue I posted above) I suggest that ESMVal should handle this case.

@valeriupredoi
Copy link
Contributor

@valeriupredoi -- without changes to CMOR we cannot change this. Given that the CF community are happy with the current expression of this data (noting @davidhassell's comment and Karl Taylor's on the CMOR issue I posted above) I suggest that ESMVal should handle this case.

cool! Cheers, Matt 🍺

@zklaus
Copy link

zklaus commented Mar 5, 2020

I agree that the original coding is actually correct when it comes to the connection between b and b_bnds. The alternative coding that @davidhassell brought up (thanks!) might work with iris, but following CF-1.7, Sect.7.1 this corresponds with "the second method" where the conventions say

[...] the formula terms may additionally be identified using a second method: [...]. Starting from version 1.7, however, the first method will be sufficient.

So long-term we have to be able to understand the first method.
Seems this should be reported upstream, just not to the modelers, but to iris. @schlunma, could you do that?

Having said that, shortcomings in software, even CMOR can not be excuses for bad data. Many groups have fixed data after CMOR (just look for cdo in the history attributes). When that's necessary, it's necessary.

@schlunma
Copy link
Contributor Author

schlunma commented Mar 5, 2020

So long-term we have to be able to understand the first method.
Seems this should be reported upstream, just not to the modelers, but to iris. @schlunma, could you do that?

Done, see SciTools/iris#3678.

@zklaus zklaus removed their assignment Feb 7, 2024
@schlunma
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

5 participants