Known Problems with the netCDF 3.5.0 Distribution
This is where we document some reported problems with the current release (netCDF
version 3.5.0) and their workarounds. Another place to look for fixes to problems
installing netCDF on platforms not listed in the netCDF
installation document is Other Builds of the netCDF Package. Reported problems and workarounds
are also available for some previous releases: version
3.4, version 3.3.1, version 3.3, version 2.4.3, and version 2.4.2.
If, after building the libraries for Large File Support according to one of
the examples in the Installation Instructions, you
try to write a file larger than 2 Gbytes, and still get an error like the following:
posixio.c:277: failed assertion `offset < X_INT_MAX'
then you need to rebuild your netCDF library.
In addition to particular platform-specific compiler flags for enabling Large
File Support (see the Installation Instructions), in order to write netCDF files
larger than 2 Gbytes with netCDF 3.4 or 3.5.0, the
libsrc/posixio.c file in the C library should be compiled with the -DNDEBUG
flag, because of an incorrect assert() statement (left in for debugging) around
line 277 in netCDF 3.5.0 (line 273 in netCDF 3.4) of libsrc/posixio.c:
assert(offset < X_INT_MAX); /* sanity check */
Compiling with -DNDEBUG included in the CFLAGS turns off assertion checking and
allows large files to be written. Alternatively you can just delete the above
statement from libsrc/posixio.c and recompile the library.
This fix is incorporated in the latest beta version netCDF available from
ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-beta.tar.Z
To use the Intel IFC compiler with netCDF 3.5.0, see these notes.
First note that you must set the LD_LIBRARY_PATH environment variable properly
to get g++ to be recognized by the configure script as a working C++ compiler.
LD_LIBRARY_PATH must include the directory that contains the gcc 3.0 runtime
libraries.
Building netCDF 3.5.0 using g++ from gcc-3.0 as the C++ compiler results in
errors:
g++ -c -g -O2 -I../libsrc -I. -Df2cFortran ncvalues.cpp
ncvalues.cpp: In member function `virtual std::ostream&
NcValues_float::print(std::ostream&) const':
ncvalues.cpp:313: no matching function for call to
`std::basic_ostream >::flags(long int&)'
/usr/local/include/g++-v3/bits/ios_base.h:311: candidates are:
std::_Ios_Fmtflags std::ios_base::flags() const
/usr/local/include/g++-v3/bits/ios_base.h:315:
std::_Ios_Fmtflags std::ios_base::flags(std::_Ios_Fmtflags)
...
Mike Romberg (NOAA/FSL) has made available a patch for netCDF-3.5.0 that
... does the things you have listed on your known problems page.
And it also cleans up the C++ interface to work with the ISO C++ namespaces.
... Finally, it patches configure.in and aclocal.m4 to work with the newer autoconfig
packages which are in redhat linux 7.2. The autoconfig changes were needed since
netcdf will not build with the shipped configure script. The C++ tests in aclocal
needed to be modified and the old ones included by the older autoconfig will
not work with gcc-3.
These problems will be fixed in version 3.5.1.
Building netCDF 3.5 on a Cray J90 using the environment variable settings:
CC=/opt/ctl/bin/cc
CFLAGS=-O3
FC=/opt/ctl/bin/f90
FFLAGS="-g -F -dp"
CXX=/opt/ctl/bin/CC
seems to build everything OK, but results in a failure in the test of the Fortran-90
interface:
call check(nf90_put_var(ncFileID, lonVarId, (/ -180, -175, -170 /)))
^
cf90-389 f90: ERROR NETCDFTEST, File=netcdf_test.f90, Line=78, Column=14
No specific match can be found for the generic subprogram call "NF90_PUT_VAR"
This is a problem in the current implementation of the Fortran90 interface on
platforms whose default Fortran integer is eight bytes in size. A workaround for
using the Fortran90 interface is to cast 8-byte integers to 4-byte integers before
calling the generic Fortran90 interfaces such as NF90_PUT_VAR(). You can also
build netCDF specifying no Fortran90 interface by setting the environment variable
F90="" before running the configure script.
This problem is fixed in the current beta release of netCDF 3.5.1.
The Fortran-90 interface of the netCDF package doesn't support environments
where both real values and doubleprecision values are 8-bytes wide (e.g. the
Portland Group's Fortran-90 compiler with the "-r8" option).
Workarounds include the following:
- Not using the Fortran-90 interface (the Fortran-77 interface works OK in
this environment); and
- Modifying the netCDF-using code, replacing the use of real values with doubleprecision
values.
Two users have reported that in running "make test" after building netCDF
3.5.0 on Windows 98/Cygwin systems, the following error occurs in the first
test:
Making `test' in directory [build directory]
..
cmp test.nc test_nc.sav
test.nc test_nc.sav differ: char 1545, line 5
Another user has reported a Cygwin installation on Windows 2000 that did not
exhibit the above symptom.
The "make test" symptom is apparently a very small difference that is not
revealed by an ncdump of the two files, and all the other tests are passed.
So it appears that the libraries can be installed and used on cygwin systems
even with this apparent problem.
Also, "make install" does not correctly handle the ncdump.exe and ncgen.exe
executables created on Cygwin systems, so these must be manually copied to wherever
you want them installed.
Beginning with netCDF version 3, the netCDF library was made consistent with the
CDL notation for netCDF data in restricting names of new variables, dimensions,
and attributes to contain only alphanumeric characters and the characters `-',
`_', and `.'. To remove the name restriction, apply this patch to the netCDF 3.5.0 source distribution,
rebuild, and reinstall the library. The resulting library will permit any characters
in netCDF component names.
Note that the CDL produced by the "ncdump" utility for such files
(if names use characters not permitted in CDL) may not be work as input to programs
such as "ncgen", that require valid CDL. This may not be a serious
restriction, if you don't need to use ncgen for generating programs or files.
Also, data in files created after this patch has been applied may not be accessible
by other utilities or language interfaces that assume the more restrictive rules
for names.
When opening a netCDF file on a Cray computer that supports Flexible File
I/O (FFIO), the netCDF package assigns attributes to the pathname of the file
if the file doesn't already have any assign-attributes. These assign-attributes
are not removed when the file is closed. Consequently, a subsequent re-opening
of the file will obtain the assign-attributes given to it by the netCDF package.
If the file is a netCDF file, then this should be OK. If, however, the file
is not a netCDF file, then the second (re)opening might fail -- depending on
the details of how the file is opened.
The documentation on this function states that the dimension-ID vector must
be large enough to hold the number of dimensions of the variable. Due to a bug
in the function's implementation, however, it is possible for the function to
attempt to write beyond the end of the dimension-ID vector. Whether this is
actually done depends on the details of the compiler. The workaround is to always
use a dimension-ID vector of length NF90_MAX_VAR_DIMS or greater.
Alternatively, you can solve the problem by replacing the file "netcdf_variables.f90"
in directory "f90/" with this new netcdf_variables.f90 and rebuilding the netCDF
package.
This bug will be fixed in the next release.
Andreas Manschke has reported a problem with writing netCDF files on a FAT32
partition under Linux, apparently because the POSIX ftruncate() function cannot
be used to extend files on a Linux FAT32 file system. A workaround after you
have run configure is to delete or comment out the following line in src/libsrc/ncconfig.h
#define HAVE_FTRUNCATE 1
and rebuild the library.
Peter Gylling Jørgensen of the Royal Danish Administration of Navigation
and Hydrography has reported a portability problem with netCDF using True64Unix
on OSF1 V5.1 1885 Alpha platforms. His report and workaround is reproduced here:
- Problem:
-
IEEE compliance of different architectures
- Caused by:
-
Create netCDF file using Linux on Intel IX86 architecture. Read netCDF
file using True64Unix on OSF1 V5.1 1885 Alpha. IEEE defines a standardized
way to treat subnormal/denormal floating point numbers.
- Description:
-
When creating netCDF files on a Intel IX86 architecture the default behaviour
is to accept denormal numbers as described in the IEEE standard. This is
unfortunatly not the default behaviour on the Alpha architecture where the
IEEE standard is partly broken to achieve a greater excecution speed. Thus,
by default denormal numbers are not supported on the Alpha system.
If the netCDF library on both platforms isn't compiled to act equally it
may result in a floating exception and a core dump on the Alpha architecture.
This happens when the Alpha-compiled program reads a denormal number written
by an IEEE compliant version of netCDF (for instance an ix86-compiled version).
The reverse case will not cause any problems because the file generated
on the Alpha architecture will contain zeros instead of denormal numbers,
and the ix86 can (of course) read these zeros.
- Easy solution:
-
Force IEEE compliance when compiling the netCDF library and utillity programs
on the Alpha architecture. This is done by using the following compile time
flags depending on the compiler in use.
Standard C-compiler (Supplied by Compaq/HP)
cc -c -ieee *.c
CFLAGS Variable in macros.make add "-ieee"
Gnu gcc compiler
gcc -c -mieee-with-inexact *.c
CFLAGS Variable in macros.make add "-mieee_with_inexact"
Needed steps:
- Run configure as usual
- Edit macros.make and add the CFLAGS variable
- make
- make test
- make install
- Longterm solution:
- Make the configure script recognize the Alpha architecture and add the
appropriate flag to CFLAGS.
