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

Re: 960329: netCDF 2.4.1 ncsync/ffflush

John,

>Date: Fri, 29 Mar 1996 11:00:55 -0500 (EST) 
>From: address@hidden (John Sheldon)
>Organization: NOAA/GFDL
>Subject: Re: 960329: netCDF 2.4.1 ncsync/ffflush 
>Keywords: 199603281505.AA27313

In the above message you wrote:

> Hmmm...does this imply a problem in ffflush()?  Should Cray look into
> this?  It seems unreasonable that netCDF can't count on being able to
> flush the data to the file, or that a subsequent read can't find the
> data that was already sent out, whether it actually went to disk or is
> still in the cache.

Well, I suppose reasonableness is in the eye of the beholder.  I just
checked your FFIO specification (cache:336:2) on our UNICOS 8 Y-MP and
it caused ncsync() to fail.  The UNICOS 8 default specification
(bufa:336:2) however, allowed ncsync() to succeed.  I suspect it's a
case of Cray trying to prevent programmers from shooting themselves in
the foot, but not being able to stop a really determined one.  ;-)

I suggest that you try to find another default UNICOS 7 FFIO
specification -- one that doesn't cause ncsync() to fail.  The following
URL might help

    http://www.unidata.ucar.edu/packages/netcdf/guide_11.html#SEC88

It's the section in the netCDF User's Guide dealing with UNICOS
optimization.  Unfortunately, most of the candidate FFIO specifications
have `cache' in their strings (a bad omen?).

Maybe a `crayon' could help?

Please let me know if you find a more suitable specification.

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