[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NETCDF 3.3 incompatibility

> My name is Per Nyberg.  I believe that we crossed paths a few months ago
> when you were porting netcdf to the SX-4 in Houston.

> We have come across some problems using the latest version of netcdf-3.3a.
> Essentialy the runs when compiled withe latest version abort with the
> following message:

Per:

Sorry it has taken so long to get back to you.
I've been on vacation and the like. The message was not in
our support tracking system since it was sent to me
directly rather than to address@hidden.
Otherwise, other staff people would have responded, or
at least beaten on me to respond :-).

> We have come across some problems using the latest version of netcdf-3.3a.
> Essentialy the runs when compiled withe latest version abort with the
> following message:
>
> ncclose: ncid 0: Not a netCDF id

In the absence of some internal netcdf problem (a definite possibility
on the SX4 platform), this error would indicates that the netcdf id (0?)
does not represent a netcdf id.

Several user programs have been stung by assumming that the netcdf id's
start at zero for the first netcdf open'ed, one for the next, and so
on. This happens to be the way it used to work, but the documentation
makes no promise. The documentation simply says "(a netcdf id) is a small
non-negativeinteger ... much like a file descriptor in C or logical unit
number in fortran". In netcdf-3, the netcdf id _is_ the file descriptor.
In a simple program, file descriptors 0, 1, and 2 are in use at program startup
as standard input, standard output and standard error, so, the ncid returned
from the first call to nc_open() would be 3. In general, the ncid has to
be stored in a variable and the value of that variable used.

You might also see the above error if the netcdf file had already been closed
in another module.

>
> Below is one of our analysts description of the work-around.
>
> What are your thoughts ?  Could you provide some advice ?

I don't see how the modifications below relate to the problem you report.

> Forwarded message:
> > So far BOM has apparently not used any version of
> > NETCDF beyond NETCDF 2.4.
> > I wonder if you could check with NCAR what they think about the
incompatibilty,
> > perhaps they have found it themselves too and added some compatibility
feature ?
> >
> > Here is what I did to get BENCH04 with NETCDF 3.3a operational.
> >
> > #1 - fully recompile BENCH04 with the header file "netcdf.inc" for NETCDF
3.3a.

Good. Must be done.

> > #2 - Modify 4 calls to NCVDEF in NETINI:
> >   example:
> >   SEGid = NCVDEF (NCHISTFid, SEGname, NCLONG, 0, 0, IRET)
> >                                               |  |
> >                                               |  array of ndims dimensions
IDs
> >                                               number of dimensions of
variable
> >   into:
> >   SEGid = NCVDEF (NCHISTFid, SEGname, NCLONG, 1, 1, IRET)
> >
> >   Same applies to the calls:
> >   BDATEid = NCVDEF (NCHISTFid, BDATEname, NCLONG, 0, 0, IRET)
> >   BHOURSid = NCVDEF (NCHISTFid, BHOURSname, NCLONG, 0, 0, IRET)
> >   IHDELTid = NCVDEF (NCHISTFid, IHDELTname, NCLONG, 0, 0, IRET)

This is probably wrong.
You are changing a "scalar" variable into a vector.
The fifth argument (VDIMS) needs to be an array (or the constant 0 is
acceptable when NVDIMS is 0). The constant 1 is incorrect.

> > #3 - Introduce a dirty fix in routine ncvarinq in file v2i.c of NETCDF:
> >      After:
> >      const int status = nc_inq_var(ncid, varid, name, datatype, &nd, dim,
&na);
> >      Insert:
> >      if ( nd == 0 ) nd=1;
> >
> >      This fix appears to be necessary when reading variables from file
> >      which have been written under NETCDF 2.3.2 or older with the
> >      NCVDEF call pattern as described under #2.

This "fix" is very wrong. I guess the guy had to do that because of the
misunderstanding in #2.

-glenn