CDO

Hi Marga,

I have the feeling that problem is related with the calendar. I think cmcc uses leap calendar, and it seems cdo is using by default the gregorian. Did you try to convert it to netcdf and see if the problem persists?

Kind regards

Estanislao

Hi Estanislao,

Thank you very much for your prompt response. I've converted the file to netCDF and I see that the calendar is proleptic_gregorian:

ncdump -h tas_20140101.nc
netcdf tas_20140101 {
dimensions:
    time = UNLIMITED ; // (240 currently)
    lon = 360 ;
    lat = 180 ;
variables:
    double time(time) ;
        time:standard_name = "time" ;
        time:units = "hours since 2014-1-1 00:00:00" ;
        time:calendar = "proleptic_gregorian" ;
        time:axis = "T" ;
    double lon(lon) ;
        lon:standard_name = "longitude" ;
        lon:long_name = "longitude" ;
        lon:units = "degrees_east" ;
        lon:axis = "X" ;
    double lat(lat) ;
        lat:standard_name = "latitude" ;
        lat:long_name = "latitude" ;
        lat:units = "degrees_north" ;
        lat:axis = "Y" ;
    float T2M(time, lat, lon) ;
        T2M:long_name = "2 metre temperature" ;
        T2M:units = "K" ;
        T2M:code = 167 ;
        T2M:table = 128 ;
        T2M:institution = "ECMWF" ;

// global attributes:
        :CDI = "Climate Data Interface version 1.9.8 (https://mpimet.mpg.de/cdi)" ;
        :Conventions = "CF-1.6" ;
        :history = "Mon Jan 02 10:07:56 2023: cdo -O -R -r -t ecmwf -f nc4c -z zip_4 -copy tas_20140101.grb tas_20140101.nc" ;
        :institution = "European Centre for Medium-Range Weather Forecasts" ;
        :CDO = "Climate Data Operators version 1.9.8 (https://mpimet.mpg.de/cdo)" ;
}

Then with cdo info the dates are shifted too:

cdo info tas_20140101.nc | head
    -1 :       Date     Time   Level Gridsize    Miss :     Minimum        Mean     Maximum : Parameter ID
     1 : 2014-02-01 00:00:00       0    64800       0 :      227.36      277.71      308.00 : 167.128       
     2 : 2014-02-01 00:00:00       0    64800       0 :      227.94      277.62      307.47 : 167.128       
     3 : 2014-02-01 00:00:00       0    64800       0 :      230.83      278.01      309.03 : 167.128       
     4 : 2014-02-01 00:00:00       0    64800       0 :      229.80      277.99      309.89 : 167.128       
     5 : 2014-02-01 00:00:00       0    64800       0 :      229.76      277.55      308.23 : 167.128       
     6 : 2014-02-01 00:00:00       0    64800       0 :      229.37      277.77      308.94 : 167.128       
     7 : 2014-02-01 00:00:00       0    64800       0 :      231.14      277.91      309.12 : 167.128       
     8 : 2014-02-01 00:00:00       0    64800       0 :      231.56      277.76      308.88 : 167.128       
     9 : 2014-02-01 00:00:00       0    64800       0 :      228.14      277.84      308.70 : 167.128     

I attach the converted file in case it is useful for you.
Kind regards,
Marga

Hi Marga,

Is it possible to output the time attributes from the grib file? Lets double check that the grib file has all the information.

Kind regards,

Estanislao

Hi Estanislao,

Yes, the time attributes can be read in Python with xarray and cfgrib, for example:

>>> import xarray as xr
>>> from cfgrib.xarray_to_grib import to_grib
>>> ds = xr.open_dataset('tas_20140101.grb', engine='cfgrib').sel(number=0)
>>> sorted(ds.variables)
['latitude', 'longitude', 'number', 'step', 'surface', 't2m', 'time', 'valid_time']
>>> ds.variables['time']
<xarray.Variable ()>
array('2014-01-01T00:00:00.000000000', dtype='datetime64[ns]')
Attributes:
    long_name:      initial time of forecast
    standard_name:  forecast_reference_time

The attributes of the dataset are the next ones, in case you would like to take a look:

>>> print(ds)
<xarray.Dataset>
Dimensions:     (step: 6, latitude: 180, longitude: 360)
Coordinates:
    number      int64 0
    time        datetime64[ns] 2014-01-01
  * step        (step) timedelta64[ns] 31 days 59 days ... 151 days 181 days
    surface     float64 ...
  * latitude    (latitude) float64 89.5 88.5 87.5 86.5 ... -87.5 -88.5 -89.5
  * longitude   (longitude) float64 0.5 1.5 2.5 3.5 ... 356.5 357.5 358.5 359.5
    valid_time  (step) datetime64[ns] ...
Data variables:
    t2m         (step, latitude, longitude) float32 ...
Attributes:
    GRIB_edition:            1
    GRIB_centre:             cnmc
    GRIB_centreDescription:  Rome 
    GRIB_subCentre:          98
    Conventions:             CF-1.7
    institution:             Rome 
    history:                 2023-01-03T16:44 GRIB to CDM+CF via cfgrib-0.9.1...

Please, if you need more information don't hesitate to ask.
Best,
Marga

Hi Marga,

I have just taken a small look to the file using python. I think the datetime is correct. If you check the variable valid_time, you will see that the timeserie starts in February. The variable time (or dataDate in your script) is the reference time, you need to add the variable step to obtain the real time (valid_time=time + step). Take a careful look by yourself. You might have incorrectly downloaded your file. You can always go back to the data source, and make sure that you have correctly selected the time.

Kind regards,

Estanislao

Hi Estanislao,

Thank you very much for the information. I'll take a deeper look into the files and I'll contact you if I find any inconsistency. Thank you very much for your help, I really appreciate it

Kind regards,
Marga

Hi Marga,

if you have a look at the steps variable you can see that the first value is
2678400000000000 this is 31*24*60*60*100000000 ns .
This leads to the first time step 2014-01-01 + 31 days = 2014-02-01

Hi Estanislao,

Sorry for the late answer. Thank you very much for the information, now I see where the step value comes from, so the valid time results by adding 31 days to 2014-01-01 + 31 days(2678400000000000):

>>> ds.variables['step'][0]
<xarray.Variable ()>
array(2678400000000000, dtype='timedelta64[ns]')
Attributes:
    long_name:      time since forecast_reference_time
    standard_name:  forecast_period

Thanks a lot!
Best regards,
Marga