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

Re: 19990810: NCSNC problem with netCDF v3.4 -- re 3.5beta

>To: address@hidden
>From: Carlie Coats <address@hidden>
>Subject: NCSNC problem with netCDF v3.4
>Organization: MCNC/NCSC Environmental Programs
>Keywords: 199908101517.JAA21345

Carlie,

> The bug repeats with "netcdf-3.5-beta1".

I was afraid of that.  It sounds like we should delay further plans
for the 3.5 release until we determine the cause of this problem and
fix it.  No one else has reported this sort of problem with NCSNC,
NF_SYNC, or nc_sync, though, so it may still be a problem with the
fact that you're mixing 3.3.1 and 3.4 objects ...

> Further info -- I'm calling everything through a library that itself
> calls the NetCDF2 interface (the "NC*()" instead of the "NF*()"'s);
> the library is Fortran, and is compiled using the 3.3.1 version of
> "netcdf.inc".  Upon further examination, I see differences in 
> "implementatinon" among the various versions of "netcdf.inc", but
> it looks to me as though the _values_ they define should be the same
> across all of them.

The values of the error codes in the Fortran interface actually
changed between 3.3.1 and 3.4, as noted by this excerpt from the 3.4
release notes Bug Fixes section at
http://www.unidata.ucar.edu/packages/netcdf/announce-3.4.html

  The values of the version 2 Fortran error codes have been modified to
  make the version 2 Fortran interface more backward compatible at the
  source level.
 
This shouldn't make any difference if you are just checking whether an
error return is non-zero, but if you are checking against Fortran
parameters for error code values, it could make a lot of difference.
Would it be too inconvenient to rebuild the library you are using to
use the 3.4 or 3.5 (they should be the same) version of netcdf.inc
instead, just to eliminate this as a possible source of the problem?

> My setup that demonstrates the problem presently has quite a bit
> of 'scaffolding" involved (a set of wrappers that wraps simultaneously
> around both the netCDF and the PVM, as well as the data files and (in
> the simplest case) a "pseudo-model" for P and the program for Q).
> Are you interested in a copy of that?

I'd prefer if we could come up with a small program that demonstrated
the bug.  Then we could even include it with our test suite so that
this kind of bug doesn't get reintroduced in a future version, as it
may have between 3.3.1 and 3.4.  We don't even have PVM installed here
(or MPI for that matter), so it would be some amount of work to even
get to the point that we could use your infrastructure to demonstrate
the problem and see whether it's platform-dependent (which might
involve installing PVM on lots of platforms).  We will need something
like PVM's mailboxes to communicate between the writer and reader of
the same netCDF file, but we might be able to just use signals or some
portable mechanism that would work in our test cases, without
requiring that PVM be installed to test a netCDF release ...

--Russ