search

PCMDI / cmor

Climate Model Output Rewriter
BSD 3-Clause "New" or "Revised" License
53 stars 32 forks source link

time axis set from time_bnds not provided time axis values #61

Closed durack1 closed 8 years ago

durack1 commented 8 years ago

@dnadeau4 @doutriaux1 @taylor13 I've just come across a weird quirk with CMOR3.0.6 that I wasn't expecting. I am providing input data with the following time axis (for the last year of the full 1870-2015 period):

Note the input file doesn't have a time_bnds

netcdf amipbc_siconc_360x180_v1.1.0_187001-201512 {
dimensions:
    time = UNLIMITED ; // (1752 currently)
    lat = 180 ;
    bound = 2 ;
    lon = 360 ;
variables:
    double time(time) ;
        time:units = "days since 1870-1-1" ;
        time:long_name = "time" ;
        time:standard_name = "time" ;
        time:calendar = "gregorian" ;
        time:axis = "T" ;

    "2015-01-16 12", "2015-02-15", "2015-03-16 12", "2015-04-16", 
    "2015-05-16 12", "2015-06-16", "2015-07-16 12", "2015-08-16 12", 
    "2015-09-16", "2015-10-16 12", "2015-11-16", "2015-12-16 12" ;

[durack1@oceanonly 150219_AMIPForcingData]$ ncdump -v time 360x180_v1.1.0_san/amipbc_siconc_360x180_v1.1.0_187001-201512.nc

 time = 15.5, ...
    52975.5, 53005, 53034.5, 53065, 53095.5, 53126, 53156.5, 
    53187.5, 53218, 53248.5, 53279, 53309.5 ;

When I hand this dataset to CMOR3.0.6 I get the following time axis back in the output file (again this is just the last 12 months of the full 1870-2015 period):

netcdf siconcbcs_input4MIPs_AMIPForcing_PCMDI-AMIP-1-1-0_gs1x1_187001-201512 {
dimensions:
    time = UNLIMITED ; // (1752 currently)
    lat = 180 ;
    lon = 360 ;
    bnds = 2 ;
variables:
    double time(time) ;
        time:bounds = "time_bnds" ;
        time:units = "days since 1870-01-01" ;
        time:calendar = "gregorian" ;
        time:axis = "T" ;
        time:long_name = "time" ;
        time:standard_name = "time" ;
    double time_bnds(time, bnds) ;

    "2015-01-16 03", "2015-02-15", "2015-03-16 18", "2015-04-16", 
    "2015-05-16 12", "2015-06-16", "2015-07-16 15", "2015-08-16 09", 
    "2015-09-16", "2015-10-16 12", "2015-11-16", "2015-12-16 12" ;

[durack1@oceanonly 150219_AMIPForcingData]$ ncdump -v time CMIP6/input4MIPs/PCMDI/AMIPForcing/mon/ocean/PCMDI-AMIP-1-1-0/siconcbcs/gs1x1/v20160607/siconcbcs_input4MIPs_AMIPForcing_PCMDI-AMIP-1-1-0_gs1x1_187001-201512.nc

 time = 15.5, ...
52975.125, 53005, 
    53034.75, 53065, 53095.5, 53126, 53156.625, 53187.375, 53218, 53248.5, 
    53279, 53309.5 ;

[durack1@oceanonly 150219_AMIPForcingData]$ ncdump -v time_bnds CMIP6/input4MIPs/PCMDI/AMIPForcing/mon/ocean/PCMDI-AMIP-1-1-0/siconcbcs/gs1x1/v20160607/siconcbcs_input4MIPs_AMIPForcing_PCMDI-AMIP-1-1-0_gs1x1_187001-201512.nc

 time_bnds =
  0.75, 30.25, ...
  52960, 52990.25,
  52990.25, 53019.75,
  53019.75, 53049.75,
  53049.75, 53080.25,
  53080.25, 53110.75,
  53110.75, 53141.25,
  53141.25, 53172,
  53172, 53202.75,
  53202.75, 53233.25,
  53233.25, 53263.75,
  53263.75, 53294.25,
  53294.25, 53324.75 ;

This behavior is really not what I was expecting - I would assume that if I provide a time_axis those values are preserved, rather than CMOR recreating the time_axis from what would appear to be faulty time_bnds in the input file.

durack1 commented 8 years ago

@dnadeau4 this is the offending line:

cmor.write(varid,values,time_vals=d.getTime()[:],time_bnds=d.getTime().genGenericBounds())
durack1 commented 8 years ago

There are a couple of issues here:

durack1 commented 8 years ago

@dnadeau4 the issue has been resolved by providing more reasonable time_bnds to CMOR by using the following:

time    = d.getTime()
cmor.write(varid,values,time_vals=time[:],time_bnds=time.getBounds())

I would recommend however that in documentation the fact that CMOR uses time_bnds and ignores the provided time_axis values is highlighted - it is certainly an unusual logical decision to this user

doutriaux1 commented 8 years ago

@durack it IS documented in the manual. Did you read it :wink:

[coord_vals] = 1-d array (single precision float, double precision float, or, for
labels, character strings) containing coordinate values, ordered consistently
with the data array that will be passed by the user to CMOR through
function cmor_write (see documentation below). This argument is required
except if: 1) the axis is a simple “index axis” (i.e., an axis without
coordinate values), or 2) for a time coordinate, the user intends to pass the
coordinate values when the cmor_write function is called. Note that the
coordinate values must be ordered monotonically, so, for example, in the
case of longitudes that might have the values, 0., 10., 20, ... 170., 180., 190.,
200., ... 340., 350., passing the (equivalent) values, 0., 10., 20, ... 170.,
180., -170., -160., ... -20., -10. is forbidden. In the case of time-coordinate
values, if cell bounds are also passed, then CMOR will first check that each
coordinate value is not outside its associated cell bounds; subsequently,
however, the user-defined coordinate value will be replaced by the midpoint
of the interval defined by its bounds, and it is this value that will be
written to the netCDF file. In the case of character string coord_vals there
are no cell_bounds, but for the C version of the function, the argument
cell_bounds_ndim is used to specify the length of the strings in the
coord_vals array (i.e., the array will be dimensioned
[length][cell_bounds_ndim]).
type = type of the coord_vals/bnds passed,
durack1 commented 8 years ago

@doutriaux1 that would be a NO, my bad.. However, following your advice _where_ is the manual located?

I've found http://www-pcmdi.llnl.gov/software/cmor/cmor_users_guide.pdf and https://pcmdi.github.io/cmor-site/index.html which would seem to be out of sync - or have similar content.. Which is the most recent?

I think @dnadeau4 was planning on updating that to https://pcmdi.llnl.gov/cmor/ using the formatting provided on http://uvcdat.llnl.gov/documentation/cdms/cdms.html

durack1 commented 8 years ago

@dnadeau4 this is no longer a problem - I do think that the docs should _VERY CLEARLY_ state that this is the case (bounds are used not the time axis)