> Hello netCDFers, > > I may have asked this question before because it feels familiar to me. > If so, however, my leaky brain has lost the answer. This works when > the file ~/foo.nc is netCDF3 and fails when ~/foo.nc is netCDF4: > > ncks -O -4 -v lat_T42 ~/nco/data/in.nc ~/foo.nc > ncrename -O -D 2 -d lat_T42,lat -v lat_T42,lat ~/foo.nc ~/foo2.nc > > In other words, ncrename is unable to rename, at the same time > (i.e., sequentially in a single define mode), both a variable and a > dimension of the same name when the input file is netCDF4. > The failure occurs during the nc_enddef() call (output below). > All done with netCDF 4.1.2. > > Is this to be expected? If so, why? > Is there a workaround? > Apologies if I should already know the answers. > > Thanks, > Charlie > > Howdy Charlie! No need to be sorry - the ways of coordinate variables and dimensions in netcdf-4/HDF5 files are a major source of confusion for me as well. And bugs. Should this work? I don't know. It never occurred to me all the crazy things that people would try with my poor, innocent little software. :-( However, I guess I can muster some team spirit and say that I can't see why this should not work. I can even confess that if it works with classic files, then it must also work (or is supposed to work) with netCDF-4/HDF5 files. I have just fixed some bugs relating to this. I wonder if you would like to retry your example. If it still doesn't work I will set up a C test. The daily snapshot includes the fix: ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/netcdf-4-daily.tar.gz Thanks! Ed Ticket Details =================== Ticket ID: YQN-334036 Department: Support netCDF Priority: Critical Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.