All the netCDF "magic numbers" are defined
in the I/O API NETCDF.EXT
file (which
is the I/O API name for the file netCDF calls
src/fortran/netcdf.inc
. Errors defined
in netCDF 2.x have positive values in the range 1...32
(except for NCSYSERR
which is -1); errors
newly defined for netCDF 3.x are in the range -60...-1.
General methodology: find the error-number and then try
to figure out what's wrong from the name of the
corresponding PARAMETER
.
Note that UCAR re-defined some of these errors between
versions 3.3.1 and 3.4 of netCDF (while leaving the
various library versions link-compatible), so you may
have to look at the src/fortran/netcdf.inc
for the version of the netCDF libnetcdf.a
you are linking with, if this is different from the
version used to build your libioapi.a
This is NCSYSERR
, meaning the system wouldn't
give you permission for what you wanted to do. Most
probably it means you need to check permissions on either
the file you're trying to create or access, or on the
directories in its directory path.
"Not a netcdf id", which can happen both if the
file honestly isn't a netCDF file, and also if it
is a netCDF file, but wasn't shut correctly. (unless you've
declared a file "volatile" by
setenv <file> <path> -v
,
netCDF doesn't update the file header until you call
SHUT3()
or M3EXIT()
.)
"Invalid Argument", but almost certainly this means you're using netCDF library 2.x with an I/O API library built for netCDF version 3.x (NCAR accidentally changed one of the "magic numbers" used in opening files when they upgraded netCDF from 2.x to 3.x).
This is a variant of the system permission problem.
A directory spec of with an extra nonexistent
component, e.g., /foo/bar/qux/zorp
when
you really mean foo/bar/zorp
and the
/foo/bar/qux
doesn't exist seems to cause
Error -31. Can also happen by trying to open too many
netCDF files simultaneously (although the I/O API
has additional traps around this).
Or on a Cray vector machine, this may mean you're running up against your memory limit. (On Crays, netCDF v3.x dynamically-allocates a fairly large buffer to optimize I/O for each file; this allocation may well push you over your (interactive or queue) memory limit. For netCDF v3.4, there are tricks you can play with environment variables to manipulate these buffer sizes. This error also has turned up with some of the more obscure file-permission problems.
Probably means you tried to read data past the last date-and-time on the file (the I/O API runs netCDF in "verbose mode", so that netCDF will always print all error messages, including this one. Also can happen when the calling program is running in parallel, but a non-MP-enabled version of the I/O API library was linked in.
OPEN3()
with
status argument FSNEW3
)
FDESC3
header-components
VGTYP3D(<variable>)
in FDESC3
is not one of
M3INT
. M3REAL
, or
M3DBLE
NCOLS3D
, NROWS3D
,
NLAYS3D
, or NTHIK3D
(else would indicate a bug in I/O API internals).
SHUT3()
or
M3EXIT()
).
/usr/include/sys/errno.h
__mp_getlock
,
__mp_unlock
, or something else with
_mp
in it?"
This probably means that you are using a version of the
libioapi.a
that is enabled for
OpenMP parallel
usage, but have not activated the system parallel
librairies. On SGI, this means that you need to add a
directive -lmp
at the end of the library
list in the final compile command that links the
executable (and similarly for other compilers).
See the variable OMPLIBS
defined in
your machine/compiler's Makeinclude.${BIN}.
fort.<nn>
files come from?"
On some systems (notably Sun and SGI), there are
incompatibilities in run-time libraries between
f77
and f90
.
The upshot is that on these systems, you can link
together Fortran-77 and C using f77
,
or Fortran-90 and C using f90
, but
you can't link together Fortran-77 and Fortran-90.
The default I/O API distribution is built using
f77
and runs into this problem when your
model code is built using f90
. The
solution is to rebuild the I/O API using
f90
.
RH7 uses quite-nonstandard gcc v2.96 and glibc versions; there are patches available at URL http://www.redhat.com/support/errata/rh7-errata-bugfixes.html
RH7's gcc v2.96 does not work with the standard edition of the Portland Group F90 compiler; there is a version which does work; see URL http://www.pgroup.com/faq.htm: (UPDATE on: RED HAT 7.0 and 3.2 RELEASE COMPILERS!)
segmentation fault
on the OPEN3
call when I attempt to create a
new file!"
Probably the file description was not completely filled
in. This has been observed, for example, when one of
the variable names VNAME3D(I)
in
FDESC3.EXT
was not set correctly. (What
actually happens is that the FDESC3.EXT
data
structures are initialized to zero by the linker; then
the netCDF internals don't handle strings that contain
just ASCII zeros correctly).
ncdump
/PAVE
it now!"
Probably the file wasn't shut correctly. (Unless
you've declared a file "volatile" by
setenv <file> <path> -v
,
netCDF doesn't update the file header until you call
SHUT3()
or M3EXIT()
.)
This usually means that the script which ran your program failed to execute correctly the setenv to define the logical name for the file. Try using the env command in the script before you run the program, in order to get started debugging your script.
ncabor_
(etc.) is an undefined symbol?"
There are three probable causes we've been observing:
Probably, the command line that links your
program has -lnetcdf
before -lioapi
instead of after. (Most UNIX linkers only try
to resolve things in terms of libraries yet to
be defined, and don't go backwards. E.g., if
you have
!!! INCORRECT !!! f77 -o foo foo.o ...
-lnetcdf -lioapi
the linker
won't know where to go to find netCDF
functions that are called in the I/O API;
instead, if you use
!! CORRECT: f77 -o foo foo.o ... -lioapi -lnetcdf
then
the linker will scan "-lnetcdf" to
find functions called in "-lioapi"
Another possibility is that you are doing multilingual programming, and using maybe "cc" or "g++" or something else to do the link step. If so, you need to explicitly list the libraries that f77 would include. The list of these is vendor dependent but frequently looks something like
... -lf77 -lU77 -lm
One way to find out is to try to use
f77 in verbose mode
(f77 -v ...
on most UNIX
systems) to do the linking: it may not find
the needed C++ libraries, but it will tell
you what libraries it needed for the Fortran
part of the I/O API and you can then
modify your original link command to use them.
Compilers "mangle" the names of
Fortran COMMON
blocks, functions,
and subroutines in various ways (usually turn
them into lower case, and then prefix or
postfix them by one (or, for
gcc/g77, sometimes two)
underscores. The precise mangling behavior
depends upon the compiler, your system
defaults file for the compiler, and the
compile/link command lines themselves. (It can
also happen that netCDF was built
without the expected Fortran or C++ support
thay your model was expecting. A useful UNIX
utility for diagnosing these problems is
nm, which reports what linker
visible symbols are present in binary
executable, object (.o
), or
library (.so
and
.a
) files. So if you see a linker
error message like
symbol foo_ not found (referenced in bar.o)
then do the following sorts of things:
nm foo.o | grep -i foo
nm libnetcdf.a | grep -i foo
nm libioapi.a | grep -i foo
etc, and maybe
man -k foo
to try to find which program-component has the
differently-mangled symbol that the linker
needs. Then go back and review the compiler
flags used in the build-process for that
component.
Sometimes you'll find that the missing symbol was in a system routine that the compiler should have known about but somehow (maybe bad compiler-installation) didn't. That one happened to me earlier this week (as I write this May 3, 2002) on an HP system.
This is a PAVE bug, not an I/O API bug: the original person who wrote the file-reader for PAVE couldn't be bothered to use the I/O API, but instead used raw netCDF reads without proper data-structure and error checking. NetCDF fills in "holes" in its files with a particular fill-value that you are seeing, and this is an indication that the data for that variable and time step was never written to the file. This happens, for example, at the starting time for an MM5/MCPL run, for some of the variables which aren't calculated until after the run is in progress.
This is fixed in Pave Version 2 and later.
>>> WARNING in subroutine CHKFIL3 <<< Inconsistent file attribute NVARS for file FOO Value from file: 6 Value from caller: 9
This means that
FOO
already exists
FSTATUS=FSUNKN3
) in the call
to OPEN3
FOO
's header does not match the
file description you have supplied in the
FDESC3
COMMONs.
Send comments to
Carlie J. Coats, Jr.
coats@emc.mcnc.org