cdo copy unexpectably modifies name of variables
Added by e ddc over 11 years ago
Hello
I am using cdo to copy from file aux26.nc to file lixo26.nc :
ariel
cdo copy aux26.nc lixo26.nc
cdo copy: Processed 24048 values from 1 variable over 6012 timesteps. ( 0.02s )ariel
The headers show that dimension loc was replaced by gsize and variables lat lon disappeared:
: ncdump -h aux26.nc ncdump -h lixo26.nc
netcdf aux26 { lixo26 {
dimensions: ons:
loc = 4 ; gsize = 4 ;
time = UNLIMITED ; // (6012 currently) time = UNLIMITED ; // (6012 currently)
nb2 = 2 ; nb2 = 2 ;
variables: es:
double loc(loc) ; double time(time) ;
loc:long_name = "location_index" ; time:bounds = "time_bnds" ;
double lon(loc) ; time:units = "days since 1-01-01 00:00:00" ;
lon:long_name = "longitude" ; time:calendar = "365_day" ;
lon:units = "degrees_east" ; double time_bnds(time, nb2) ;
lon:standard_name = "longitude" ; time_bnds:units = "days since 1-01-01 00:00:00" ;
lon:axis = "X" ; time_bnds:calendar = "365_day" ;
double lat(loc) ; float psl(time, gsize) ;
lat:long_name = "latitude" ; psl:long_name = "Sea Level Pressure Locations extraction " ;
lat:units = "degrees_north" ; psl:standard_name = "air_pressure_at_sea_level" ;
lat:standard_name = "latitude" ; psl:units = "Pa" ;
lat:axis = "Y" ; psl:_FillValue = 1.e+20f ;
double time(time) ; psl:comment = "not, in general, the same as surface pressure" ;
time:bounds = "time_bnds" ; psl:original_name = "PSL" ;
time:units = "days since 1-01-01 00:00:00" ; psl:cell_methods = "lat: locations lon: locations" ;
time:calendar = "365_day" ; psl:history = "2011-06-11T23:21:43Z altered by CMOR: replaced missing value flag (1
double time_bnds(time, nb2) ; psl:associated_files = "baseURL: http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation gri
time_bnds:units = "days since 1-01-01 00:00:00" ;
time_bnds:calendar = "365_day" ; al attributes:
float psl(time, loc) ; :CDI = "Climate Data Interface version 1.5.0 (http://code.zmaw.de/projects/cdi)" ;
psl:long_name = "Sea Level Pressure Locations extraction " ; :Conventions = "CF-1.4" ;
psl:standard_name = "air_pressure_at_sea_level" ; :history = "Thu Nov 15 15:50:04 2012: cdo copy aux26.nc lixo26.nc\n",
psl:units = "Pa" ; "Thu Nov 15 13:44:42 2012: cdo intpoint,-25.664893,37.749428 /disks/cmip5/o
psl:_FillValue = 1.e+20f ; "2011-06-11T23:21:44Z CMOR rewrote data to comply with CF standards and CMI
psl:comment = "not, in general, the same as surface pressure" ; :institution = "Norwegian Climate Centre" ;
psl:original_name = "PSL" ; :institute_id = "NCC" ;
psl:cell_methods = "lat: locations lon: locations" ; :experiment_id = "piControl" ;
psl:history = "2011-06-11T23:21:43Z altered by CMOR: replaced missing value flag :model_id = "NorESM1-M" ;
psl:associated_files = "baseURL: http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation g :forcing = "N/A" ;
:parent_experiment_id = "N/A" ;
// global attributes: :parent_experiment_rip = "N/A" ;ariel /home/
Can you reproduce this unexpected behaviour?
Any ideas how to make a real copy ?
Thanks a lot in advance.
Best regards,
E.
Replies (5)
RE: cdo copy unexpectably modifies name of variables - Added by Ralf Mueller over 11 years ago
Yes, I can reproduce it. The problem is, that your input variable psl does not have the coordinates attribute, that's why lon and lat are missing after the copy operator.
For a plain copy, you could of cause use the unix command cp.
hth
ralf
RE: cdo copy unexpectably modifies name of variables - Added by e ddc over 11 years ago
Thanks Ralf.
Are you saying that anywhere cdo sees lat and lon it assumes that they are coordinates? Are lat and lon special words for cdo? In other words, if I change the names for x,y it may work?
Also, cdo changed loc to gsize!
Yes, I can use unix "cp" to copy the files, however, I am actually using cdo to change time to absolute time (cdo -a copy). which I cannot do easily otherwise.
Any way, it is would be better that cdo -copy did exactly what is expected: to copy a netcdf file without constraints on the attributes!
This kind of behaviour is annoying and undermines the confidence one could have on cdo.
Kind rergards,
E.
RE: cdo copy unexpectably modifies name of variables - Added by Ralf Mueller over 11 years ago
e ddc wrote:
Thanks Ralf.
Are you saying that anywhere cdo sees lat and lon it assumes that they are coordinates? Are lat and lon special words for cdo? In other words, if I change the names for x,y it may work?
CDO ignores the lon/lat variables of your file, because they are coordinates (having the axis attribute) but aren't connected to any data variable (because psl does not have a CF-conform attribute, which indicates this)
Also, cdo changed loc to gsize!
CDO focuses on data variables, so it may change the dimension names. And that's why coordinates, which not used by data, are not taken into account. In this case, CDO assumes, that loc is some kind of lateral location index, which is true and uses it's default name for it.
Yes, I can use unix "cp" to copy the files, however, I am actually using cdo to change time to absolute time (cdo -a copy). which I cannot do easily otherwise.
Any way, it is would be better that cdo -copy did exactly what is expected: to copy a netcdf file without constraints on the attributes!
This kind of behaviour is annoying and undermines the confidence one could have on cdo.
Please note, that CDO is not a general netcdf editor. It supports the CF-convention for climate data, but not the whole netcdf standard - netcdf is very flexible. If you can a netcdf editor, nco might be a good choice.
hth
ralf
RE: cdo copy unexpectably modifies name of variables - Added by e ddc over 11 years ago
Thanks again. Useful and appreciated.
Best,
E.
RE: cdo copy unexpectably modifies name of variables - Added by e ddc over 11 years ago
May I add that aux1.nc (attached) is CF compliant (one cant test for compliance at http://titania.badc.rl.ac.uk/cgi-bin/cf-checker.pl?cfversion=1.0), and nevertheless "cdo -a copy aux1.nc aux2.nc" still removes variables (in this case int i & int j) and renames dimensions (see attached aux2.nc).
You explained to me why CDO behaves in the way documented above. The explanation is in all probability correct. But the point here is not only understand why it does that but more importantly if it should do that. In my opinion it should not.
If I have a legitimate CF cmip5 climate file and the behaviour of a command called copy is partially remove variables and rename dimensions I tend to see this as a bug that needs to be corrected. The behaviour of cdo copy undermines the whole point about respecting conventions and standards and predictability of the output.
Regards,
E.