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

960329: netCDF 2.4.1 for Unicos 7.0.6

John,

>Date: Fri, 29 Mar 1996 10:10:18 -0500 (EST) 
>From: address@hidden (John Sheldon)
>Organization: NOAA/GFDL
>Subject: Re: 960328: netCDF 2.4.1 for Unicos 7.0.6 
>Keywords: 199603281505.AA27313

In the above message you wrote:

> > You should replace the `bufa:...' string in the xdrffio.c file with a
> > more reasonable default for UNICOS 7.
> 
> Hmmm...I went back to do just that (using 'cache:336:2') and noticed
> "make test" was not _entirely_ successful.  I'll paste the log at the
> end, but there was really only one failure:
> 
>    *** Testing ncsync ...          *** test_ncsync: second ncopen failed
>    FAILED! ***
> 
> I think the same thing happened yesterday, but between my excitement at
> the apparrent success and my weariness at having been at it for so
> long, I guess I overlooked it.
> 
> I also went back and checked "make test" on the C90 and verified that
> it had the same "failure".  
> 
> This "failure" did *not* occur on my SGI.
> 
> Is this serious?

Whether or not the above is serious depends on how you use the netCDF
package.  The test of ncsync() writes some data to a netCDF file, calls
ncsync() on the file, and then attempts to open the file for reading.
The failure is on the second opening of the file for reading.  I suspect
that there's some pretty severe cacheing going on, and the file doesn't
yet exist at the time of the second opening -- even though ffflush() was
called on it by ncsync().  It seems likely that anyone using CRAY vector
writes to an open file would know better than to assume the data has hit
the disk, so my guess is that your programs are (probably) safe.  You
should, however, check the I/O assumptions make by any netCDF-using
program.

I suspect that a FFIO specification exists that will not cause this
problem.

--------
Steve Emmerson   <address@hidden>