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

Re: Odd behaviour -v3.4 3.3 DEC Alpha

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: Odd behaviour -v3.4 3.3 DEC Alpha
  • Date: Thu, 4 Mar 1999 19:35:20 -0700
On Mar 5,  2:47pm, Jeff Copeland wrote:
> Subject: Odd behaviour -v3.4 3.3 DEC Alpha
> I've noticed an odd behaviour with the netCDF libraries v3.3 & v3.4
> compiled for DEC Alpha.
>
> When creating a file from scratch the resulting netCDF file is fine.  If I
> subsequently add an additional variable to the file, other (pre-existing)
> variables will get scrambled.  This only occurs to some variables at some
> 2-D slices.  Visually it looks like a 2-D slice has been subdivided into
> several rectangular areas then randomly put back together.  I'm guessing
> that some internal directory header is getting corrupted when the new
> variable is getting defined.  This was not a problem pre-v3.  Current libs
> work fine on the SGI.
>
> Anyone else see this and have a fix?  I haven't tested the effect of file
> size but the ones we use are typically >100mb .
>
> Cheers -- Jeff
>
> +--------------------------------------------------------------------+
> Jeffrey H. Copeland Ph.D.           \_          address@hidden
> NIWA Wellington                     </          Ph:   (64)(4) 386-0466
> PO Box 14901, Kilbirnie,           /)           Fax:  (64)(4) 386-2153
> Wellington, NEW ZEALAND.          (/`
> National Institute of Water & Atmospheric Research - Taihoro Nukurangi
> +--------------------------------------------------------------------+
>-- End of excerpt from Jeff Copeland

We have an open bug report of  similar problem on other systems.
You can work around this in specific cases.
Use the nc__open() or nc__create() interface and set the
by changing the 'chunksize' parameter to a value that works for your file.
In your case, the default value for the SGI works.

Consider avoiding the use of nc_redef.
It may not be supported in all circumstances.
(For example, it crushes parallel performance.)
There are very few instances where
one can't know what the variables are before sticking in data.

-glenn