 |
Known Problems with the netCDF 3.6.0 Distribution
|
Known Problems with netCDF 3.6.0
It has been reported (by Atro Tossavainen) that nctest fails on
some Irix builds. (We cannot duplicate this problem at netCDF World
HQ).
The nctest fails when comparing the test-generated out with a saved
copy of the output.
To fix this problem get the latest
3.6.1 beta release.
On Irix systems without a recent version of the C++ compiler, the
C++ API won't build. The solution is to set CXXFLAGS to -LANG:std.
Kevin Thomas of the University of Oklahoma has reported a
potentially serious bug in using the new large file support in netCDF
3.6.0. Users of the new large file facilities are cautioned to either
apply this one-line patch to netCDF 3.6.0 or to upgrade from version
3.6.0 to the current release version 3.6.0-p1, available from netcdf.tar.Z or netcdf.tar.gz. Until you can upgrade, avoid rewriting in place
any large (> 2 GiB) netCDF files that use the new 64-bit offset format
under the conditions described below.
The bug occurs following this sequence of steps:
- A large netCDF file is created using the new 64-bit offset format
variant (also known as the version 2 format) and the file is
closed.
- Later the file is opened for writing, followed by either of the
following operations:
- enter define mode (calling nc_redef(), nf_redef(), or
nf90_redef(), in C, Fortran-77, or Fortran-90 interface, for
example) to add a new dimension, variable, or attribute; or
-
write a new value for an existing attribute (either a global or a
variable-specific attribute).
Under these conditions, after you leave define mode or close the
file, the file header is written out in the "classic" (version 1)
netCDF format, chopping the leading bits off any variable offsets that
were large enough to require more than 32 bits. If there were no such
huge variable offsets, the file is undamaged and remains readable as a
classic netCDF file. If there were any huge variable offsets (> 2
GiB), data for the first such variable and all subsequent variables
will not be accessed correctly. It is possible to restore the header
for such a file to the correct 64-bit offset form so that the data can
subsequently be accessed correctly, if no data values have been
overwritten since the file header was changed to classic format. Feel
free to contact
us for help restoring the file headers if this applies to you. If
you have any large 64-bit offset format netCDF files that might have
mistakenly been rewritten with classic format headers, please be
careful not to write any more data into them, as it could overwrite
data that could not subsequently be recovered.
If you want to know how to tell if a 64-bit offset file has been
converted by this bug into a classic format file, see the answer to
the FAQ How can I tell if a netCDF file
uses the classic format or new 64-bit offset format?.
To build on Cygwin, you must get the latest
3.6.1 beta release.
The netCDF windows DLL doesn't include the Fortran API. We are
working on this problem for the next release. Meanwhile, if you need
the fortran API in your DLL, you'll have to use the netCDF
3.5.1 DLL.
On some versions of the Portland Group F90 compiler, the F90 tests
fail, looking something like this:
*** Failure ***
*** example_good.cdl 2000-04-05 21:33:14.000000000 +0200
--- example.cdl 2005-01-11 10:21:31.624884000 +0100
***************
*** 34,43 ****
953, 954, 955,
956, 957, 958,
959, 960, 961,
! 962, 963, 964,
! 965, 966, 967,
! 968, 969, 970,
! 971, 972, 973 ;
lat = -90, -87.5, -85, -82.5 ;
--- 34,43 ----
953, 954, 955,
956, 957, 958,
959, 960, 961,
! 950, 951, 952,
! 953, 954, 955,
! 956, 957, 958,
! 959, 960, 961 ;
This problem is caused by a bug in the Portland F90
compiler. Upgrade to the latest version of the compiler or get the
free patch from Portland Group to fix this.
On AIX systems, the configure step can't find either the F90 or the
F77 compiler. On AIX system, you must set the environment variables FC
and F90 to xlf and xlf95.
On AIX systems, the F90 option -qsuffix=f=f90 is required in
F90FLAGS. Configure should automatically detect and add this to
F90FLAGS if it's not already there, but it doesn't.
FIX: Make sure that -qsuffix=f=f90 is set in the F90FLAGS before
running configure.
This will be fixed in the next beta release.
On AIX systems, the F90 functions may not be added to the
library. This is due to a quirk of AIX make.
Before doing "make install", change to the Fortran90 directory
(src/f90) and do "make". Then proceed to "make install".
With some fortran compilers, such as Absoft, the configure script
stupidly adds a -Df2cFortran to the C preprocessor flags, which causes
the fortran tests in nf_test to fail to link.
This problem is fixed in the 3.6.1 beta release. Get the 3.6.1
beta release.
On some platforms (HP-UX 11.00, maybe others), make fails with an
error message like:
Warning: ncgenyy.c is out-of-date with respect to ncgen.l
Warning: It should be recreated via flex on a SunOS 5 system
and then fails if the "flex" command is not found.
The problem is that the modification time on the source file
src/ncgen/ncgenyy.c is being interpreted as earlier than the
modification time on the source file src/ncgen/ncgen.l, even though
ncgenyy.c was actually created after ncgen.l was modified. To workaround this
problem on a Unix system, run the following command from the netCDF
src/ directory to update the modification time of the derived file:
touch ncgen/ncgenyy.c
Then rerun the make command.
If you run "configure --help", it suggests setting "FCFLAGS" for the
fortran compiler flags, but "FFLAGS" is actually used for the Fortran
compiler flags. "FCFLAGS" is ignored when compiling.
This problem will be is fixed in the next beta release. Until then,
use FFLAGS, not FCFLAGS.
For access to array sections, strided access, or mapped access,
you need to specify both a start index vector and a count vector,
where the count vector specifies the number of slices along each edge
to access. If the start index vector specifies the maximum dimension
size and the corresponding count vector is zero, the library should
just return no data, but instead it returns an error status indicating
"Index exceeds dimension bound". This problem has been present in all
versions of netCDF, and the test programs even verify that in this
case an error is returned rather than gracefully accessing no data.
This will be fixed in the next minor version.
Running configure on Cygwin fails to find GNU C++ compiler, even if it
is present on the platform. As a result, the C++ interface is never
built.
This problem is fixed in the 3.6.1 beta release. Cygwin users
interested in the C++ interface should get the 3.6.1
beta release.
The use of large files, and an 8-byte off_t type, is not handled
correctly in the 3.6.0 release of the code and project files needed to
compile the netCDF library with Visual C++.NET.
This problem is fixed in the 3.6.1 beta release. Users interested in
building their own DLL should get the 3.6.1
beta release. The DLL offered on the binary release page is 3.6.1
beta.
When using the environment variable TEMP_LARGE during the netCDF 3.6.0
make extra_test phase, the directory name must be followed by a slash
to work. For example, use 'setenv TEMP_LARGE /tmp/' instead of 'setenv
TEMP_LARGE /tmp', as one would usually expect, and as the
documentation describes.
This problem is fixed in the 3.6.1
beta release. Users of 3.6.0 should specify the trailing slash to
use the TEMP_LARGE environment variable in make extra_test.
