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

Re: 980302: netCDF dimension name problem

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: 980302: netCDF dimension name problem
  • Date: Mon, 02 Mar 1998 14:15:14 -0700
>From: Carl Dierking <address@hidden>
>Subject: netCDF dimension name problem
>Organization: WSFO Juneau, AK
>Keywords: 199803021949.MAA06663 netCDF name

Hi Carl,

>      We recently ran into a problem with netCDF version 3.x when we tried 
>      update code which created a file with a variable dimension named 
>      "ident string".  The 2.x and earlier versions didn't seem to have a 
>      problem with a space as part of the name but the 3.x version did.  
>      (The old function "ncdimdef" failed with an error)
>      
>       
>      I haven't been able to find anything in the documentation stating that 
>      space separted dimension names were illegal. Is that naming convention 
>      not supported in the latest netCDF version?  

We did change the characters permitted in names for netCDF variables,
dimensions, and attributes, because of complaints from users that the
unrestricted names permitted by the library were inconsistent with the
alphanumeric restrictions for names enforced by the ncgen and ncdump
utilities and the CDL language they support.  The new netCDF 3.x
restriction is in the netCDF-3 User's Guide, but it may not be obvious
where to look.  It's in "Appendix D, NetCDF 2 Transition Guide" in both
the Fortran and C User's Guides:

    ... In the previous library, there was no checking that the
    characters used in the name of a netCDF object were compatible with
    CDL restrictions.  The ncdump and ncgen utilities that use CDL
    permit only alphanumeric characters, "_" and "-" in names.  Now this
    restriction is also enforced by the library for creation of new
    dimensions, variables, and attributes.  Previously existing
    components with less restrictive names will still work OK.

(See, for example,
<http://www.unidata.ucar.edu/packages/netcdf/guidec/guidec-20.html>).

So if you have existing netCDF files with blanks in names, the 3.x
library will read them OK, but it will not permit creating new names
with blanks in them.  It turns out that this restriction also makes
other language interfaces to netCDF simpler, but if you need to
circumvent the restriction, it is possible to just take the name test
out of the library source code and recompile it without harm, except
that ncgen users or users of other language interfaces may eventually
have trouble reading with your files.

With version 3.4, available soon, we have relaxed the name restriction
slightly to permit periods in names of netCDF components, a feature
requested for some time that does not cause CDL parsing problems.
However, I'm afraid there is no way to parse CDL if blanks are allowed
in component names.

--Russ

_____________________________________________________________________

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