[netCDF #XIC-520836]: legal NetCDF variable names

> Hi,
>
> When we recently relinked our software products, NCL and PyNIO, with
> the newly released version of the NetCDF 4.0 library we discovered that
> there seems to have been a change in the actual, as opposed to the
> documented, rules for variable names. Specifically it appears that
> names that begin with a digit can no longer be written to NetCDF files.
> This change causes difficulties for our software, particularly with our
> conversion utility, ncl_convert2nc, when used to convert GRIB to
> NetCDF. Our GRIB reader uses GRIB parameter names, as published by NCEP
> and other sources such as ECMWF, as the initial characters of GRIB
> variable names. A number of these parameter names (e.g. "4LFTX",
> "5WAVH", and "5WAVA" from NCEP's operational table) begin with digits.
> Now suddenly with the new version of NetCDF file conversions that have
> worked for many years no longer complete successfully.
>
> Since first encountering this problem, I have discovered 2 additional
> points: (1) the new NetCDF 3.6.3 library has the same behavior as the
> 4.0 library and  (2) neither version of the library (fortunately) has a
> problem reading existing files that contain variable names that begin
> with digits.
>
> Admittedly, NCL and our file I/O library should have been coded to
> follow the documented behavior rather than the actual behavior of the
> NetCDF library. However, initial digits in variable names have worked
> for at least the last 10 years, and were working as recently as
> netcdf-4.0-beta1. Assuming the change was intentional, I wonder if the
> developers realized the serious backwards incompatibility that could
> result for client software. It seems to me that a user-visible change
> like this should have been announced for at least a few months. It
> should not have taken place without warning between a beta and a final
> release. However, perhaps the change was inadvertent. In any case is
> there a possibility of treating this as a bug and reverting to the
> older behavior at least for awhile? Actually I wonder what the need is
> to restrict names in this fashion other than just to satisfy the
> written documentation. Why not allow initial digits in names when they
> have worked just fine for many years?
>
> -Dave Brown
> NCL, PyNGL/PyNIO development team
>

Howdy Dave!

As mentioned on the mailing list, we will fix this in the snapshot releases and
notify everyone when it is ready. (Probably a week or so.)

Thanks for reporting this.

Ed

Ticket Details
===================
Ticket ID: XIC-520836
Department: Support netCDF
Priority: Normal
Status: Closed