[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 951210: netCDF irrational behavior?

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 951210: netCDF irrational behavior?
  • Date: Mon, 11 Dec 1995 09:59:40 -0700
>From: address@hidden (Nan Rosenbloom)
>Organization: NCAR/CGD
>Keywords: 199512102050.AA27283 netCDF

Hi Nan,

> I need some help with what looks to be irrational netcdf behavior - 
> hopefully I just missed some fine print, but I can't find any 
> answer in the documentation.
> 
> I have been changing the names of dimensions within Netcdf files. 
> I use NCDID (when using FORTRAN) and can change it once, and even twice, 
> but when I try a third time, using the same code it fails.  
> In fact, the failure is reproduceable.  I can produce the same
> problem with several dimension names within a single file.
> (NOTE:  when going from 3 to 4 character string I use define mode;  
> when going from 4 to 3 I do not).
> 
> Here is the sequence of events:
> 
> 'row' -> 'rows'               successful
> 'rows' -> 'row'       successful
> 'row' -> 'rows'       FAILURE (it says 'row' can not be found)
> 
> Any ideas?  

It's a bug.  I've just verified that the problem can be reproduced in the C
interface.  I'll put it on the list to be fixed before the general release
of netCDF 2.4.  I can't work on it today, but I'll let you know when there's
a beta version with the fix available for testing.

In the meantime, the only workaround I can suggest is that you use define
mode even when redefining a dimension name to a shorter length.  That seems
to work, but I realize it can be expensive for large files.

Thanks for reporting the problem!

______________________________________________________________________________

Russ Rew                                           UCAR Unidata Program
address@hidden                              http://www.unidata.ucar.edu