Re: 19990810: NCSNC problem with netCDF v3.4

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

Hi Carlie,

> Is NCSNC for netCDF version 3.4 working correctly?
> 
> I have the following situation which leads me to believe that either
> it is not or else there is a serious error in IRIX6.5:
> 
> I have two programs (call them P and Q; actually, there are quite a
> few more also going usually, spread across several machines, but not
> relevant to the problem at hand), both running on the same IRIX6.5 
> machine (2-processor Octane) which have the following sequences of 
> behavior embedded in their codes:
> 
>    P:  Open netCDF file "foo" for output with NV=37 variables,
>        each on a 53x67x30x"unlimited" grid 
> 
>        for each hour T (0...48)
> 
>            for each variable V in "foo"
> 
>                write V to time-slice T in "foo"
> 
>                call NCSNC on "foo"
> 
>            write a PVM mailbox "bar:T"

From the indentation above, I assume your NCSNC call is inside the
variable loop, so that you are calling it once for each variable.  It
seems to me that you might just want to call it once for each hour T,
as you do for writing the PVM mailbox, since it's use here is to make
sure the number of records in the file header is correct.  And the
number of records only changes once for each hour T, assuming T is
associated with the unlimited dimension.  But that doesn't have much
to do with the problem you report, it's just doing some extra work ...

>     Q:  Open netCDF file "foo" for input
> 
>         get time-to-be-processed from the user:  T=8
> 
>         PVM-request mailbox "bar:T" (sleeps until this
>         mailbox becomes available)
> 
>            call NCSNC on "foo"
> 
>            for each variable V in "foo"
> 
>                read V from time-slice T in "foo" and process it
> 
> Note that the writer P writes to netCDF, calls NCSNC, and *then* 
> writes to PVM, whereas the reader Q does things in exactly the
> reverse order, so that when PVM wakes up Q, the data should be
> available.

I agree that this should work as you have described.

> When I build Q with netCDF 3.3.1, it works exactly the way you would
> expect:  Q sleeps until PVM indicates the data is available, then it
> wakes up, does the NCSNC and the NCVGT's to read the data successfully
> (and then process it...)
> 
> When I build Q with netCDF 3.4, it fails:  I get a netCDF error -40 
> for the very first variable -- indicating that the current run-time 
> in Q doesn't think T=8 is available yet.

This certainly would appear to be a bug.  Would it be too much trouble
for you to get a copy of the netCDF-3.5-beta library and build with
that, just to test if the bug still exists in netCDF 3.5?  If it does,
I would be very interested in trying to duplicate the problem here
and fixing it before netCDF 3.5 is released.  The netcdf-3.5-beta
release is available from

  ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-3.5-beta1.tar.Z

I'm afraid I don't have a good record of all the fixes that were made
from 3.4 to 3.5, so it's possible this was something that was fixed
before I started making changes.

Otherwise, it will take us some time to try to generate a small test
case that reproduces the behavior you are seeing and figure out what
is causing it (unless you already have such a test case that we could
use) ...

Thanks for the very clear problem report.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu