Known Problems with the netCDF 2.4.3 Distribution

Unidata - To provide the data services, tools, and cyberinfrastructure leadership that advance Earth system science, enhance educational opportunities, and broaden participation.

DataToolsCommunityDownloadsSupportProjectsAbout Us

•

Known Problems with the netCDF 2.4.3 Distribution

This is where we document some reported problems with the current release (netCDF version 2.4.3) and their workarounds.

Documentation Inaccuracy for ncattinq() and ncattget()
Under IRIX 6.2, ncdump test fails
Problem Making Fortran Jackets on CRAY Platforms
Long strings and ncgen
Record strings and ncgen
HP-UX's f77 compiler causes make test to fail
nctest results in segmentation violation (signal 11) in file libsrc/xdrffio.c
Infinite _FillValue causes ncdump to print values as `_'
Error building C++ interface on CRAY Platforms

Documentation Inaccuracy for ncattinq() and ncattget()

In the NetCDF User's Guide for version 2.4, the documentation for the len parameter of the ncattinq function states:

len: Returned number of values currently stored in the attribute. If the attribute is of type NC_CHAR, this is one more than the string length (since the terminating zero byte is stored). ...

This is incorrect, since character string attributes created from FORTRAN programs and by the ncgen utility, for example, may not include a trailing zero byte. This should be corrected to read

len: Returned number of values currently stored in the attribute. For attributes of type NC_CHAR, you should not assume that this includes a trailing zero byte; it doesn't if the attribute was stored without a trailing zero byte, for example from a FORTRAN program. Before using the value as a C string, make sure it is null-terminated. ...

Similarly, the documentation for the value parameter of ncattget should be corrected by adding

: For attributes of type NC_CHAR, you should not assume that the returned values include a trailing zero byte; they won't if the attribute was stored without a trailing zero byte, for example from a FORTRAN program. Before using the value as a C string, make sure it is null-terminated.

This has been corrected in the on-line documentation and the PostScript version of the NetCDF User's Guides, available from http://www.unidata.ucar.edu/software/netcdf/docs.html.

Under IRIX 6.2, ncdump test fails

The "make test" for netCDF 2.4.3 under IRIX 6.2, will currently fail in testing the ncdump utility, with the symptoms:

making `test' in directory .../netcdf-2.4.3/src/ncdump

    ../ncgen/ncgen -o test0.nc -n test0.cdl
    ./ncdump test0.nc > test1.cdl
    ../ncgen/ncgen -o test1.nc -n test1.cdl
    ./ncdump -n test0 test1.nc > test2.cdl
test1.cdl test2.cdl differ: char 987, line 69
*** Error code 1 (bu21)

This failure is caused by a compiler bug in the IRIX 6.2 C compiler, which has been reported. A workaround is to interchange the order of lines 11 and 12 in ncgen/generic.h file, so that

union generic {         /* used to hold any kind of fill_value */
    double doublev;
    float floatv;
    nclong longv;
    short shortv;
    char charv;
};

is changed to

union generic {         /* used to hold any kind of fill_value */
    float floatv;
    double doublev;
    nclong longv;
    short shortv;
    char charv;
};

Then run "make all" in the ncgen directory to rebuild ncgen, after which a "make test" from the top-level should get through the ncdump and ncgen tests OK.

Alternatively, you can use the pre-release test version of netCDF-3 in which this workaround is already implemented.

Problem Making Fortran Jackets on CRAY Platforms

Some users have reported an error message from the m4 in building the Fortran netCDF interface on CRAY systems:

    making `all' in directory /home/ymp8/rts/netcdf/netcdf-232pl2/fortran

        ./fortc -L . -O unicos common.inc > netcdf.inc
        ./fortc -L . -O unicos jackets.src > jackets.c

    m4:-:529 can't open file

The problem is that, at least on some CRAY systems, the m4 utility has a bug in it. A workaround that CRAY sites have found successful is to build the necessary jackets.c, netcdf.inc, and ftest.f files in the netcdf/fortran directory for UNICOS on a different UNIX platform, using the commands

  ./fortc -L . -O unicos jackets.src > jackets.c
  ./fortc -L . -O unicos common.inc > netcdf.inc
  ./fortc -L . -O unicos ftest.src > ftest.f

then copy the resulting files back to the CRAY and run make again. Since the modification time on the files should be later than on the sources from which they are generated, the fortc that invokes the Cray m4 won't be used.

We suggest that you bug your UNICOS system administrator about the bug in m4. Hopefully, they'll pass it on to CRAY.

Long strings and ncgen

When reading a very long string in a CDL file, ncgen emits an error message about a "parse error" or "syntax error" (depending on which platform ncgen is invoked from).

This error comes from the lex utility used to generate ncgenyy.c from ncgen.l. The lex program builds parsers that can't handle lines longer than 1024 characters. This limit may be different for lex on different platforms. If you split the CDL data statement, e.g.:

   stringvar = "000...000" ;  // 1440 zeros

into something like the following instead:

   stringvar = "000...000",   // 1000 zeros
           "000...000" ;  //  440 zeros

then the lex limit will not be encountered. Since we can't change lex, it looks like fixing this will require making ncdump output substrings that don't exceed the built-in lex limit.

Record strings and ncgen

The following tiny CDL file demonstrates a bug with ncgen:

    netcdf bug {
    dimensions:
        time = UNLIMITED ;
    variables:
        char var(time) ;
    data:
        var = "abcd";
    }

Running ncgen on the above CDL file produces the error message:

    ncgen: var.cdl line 7: string won't fit in this variable, 4>1

The problem is with character variables that use only the record dimension, such as the variable var above. The above works fine with ncgen when the character string is separated into individual characters, as in:

    netcdf bug {
    dimensions:
        time = UNLIMITED ;
    variables:
        char var(time) ;
    data:
        var = "a", "b", "c", "d";
    }

The next release will fix the way ncdump outputs such variables as well as the way ncgen parses the old ncdump output.

In the meantime, ways to avoid this bug are to use NC_BYTE instead of NC_CHAR types for 8-bit values that vary only along the record dimension, or to separate the output of ncdump for such variables into individual characters for each record.

HP-UX's f77 compiler causes `make test` to fail

On an HP-UX system, the make test command can fail in the fortran/ subdirectory because the f77 FORTRAN compiler doesn't understand the -L../libsrc option. The solution is to use the fort77 compiler instead:

Go to the top-level source directory.
Unset the variable FC (in which case the configure script should decide to use the fort77 compiler) or set it to fort77 (either in the environment or in the file CUSTOMIZE depending on how you're customizing the installation.
Remove the file config.cache if it exists.
Re-execute the configure script.
Execute the command make fortran/clean.
Resume normal installation procedures beginning with make.

`nctest` results in segmentation violation (signal 11) in file `libsrc/xdrffio.c`

When executing the netCDF version 2.4.3 utility nctest in the nctest/ subdirectory on a UNICOS 8.0.4 (or later) system, the utility aborts due to a segmentation violation (signal 11) in the file libsrc/xdrffio.c:

        ./nctest
    *** Testing nccreate ...        Unable to open file: testfile.nc
    Error Explanation:%H?@**v+!@
    ok ***
    *** Testing ncopen ...          Unable to open file: tooth-fairy.nc
    Error Explanation:Make: "./nctest" terminated due to signal 11 (core dumped)

This is due to a change in the size of an array of pointers to error message strings in the new version of UNICOS. The fix is to apply this patch to the file libsrc/xdrffio.c.

This fix will be incorporated in the next release of the netCDF package.

Infinite `_FillValue` causes ncdump to print values as `_'

If you use an IEEE infinity as the value of the _FillValue attribute for a variable, the ncdump program will output _ for ordinary values of the variable, as if they had not been written.

Using an IEEE infinity or NaN for a fill value is not recommended, because the resulting file may not be interpreted correctly on platforms that don't use the IEEE 754 Standard for floating-point. If you use non-normal numbers for fill values, a fix is to apply this patch to the file ncdump/vardata.c and rebuild ncdump. If you don't have the IEEE finite() function used in this patch in libm, you can try compiling ncdump/vardata.c with a -DNO_FINITE flag and with compiler flags that support IEEE comparisons (e.g. NaN != NaN).

Error building C++ interface on CRAY Platforms

If you have the Cray C++ compiler installed and try to build the netCDF distribution, the Cray C++ compiler reports errors in compiling netcdf.cc:

CC -c  -I../libsrc   netcdf.cc
CC-403 CC: ERROR File = netcdf.hh, Line = 76
  Member function function "NcFile::add_att" has already been declared.

      NcBool add_att( NcToken attname, ncbyte );
             ^
   ...

To workaround this problem, you need to use the "-h char" option of the CRAY C++ compiler. To make sure this option is included, specify the CXXFLAGS variable as "-h char" either in the environment or in the CUSTOMIZE file before running the configure script.

				Unidata is a member of the UCAR Office of Programs, is managed by the University Corporation for Atmospheric Research, and is sponsored by the National Science Foundation.
				P.O. Box 3000 • Boulder, CO 80307-3000 USA • Tel: 303-497-8643 • Fax: 303-497-8690