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

951010: netcdf bug?

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: 951010: netcdf bug?
  • Date: Tue, 10 Oct 95 07:58:09 -0600
Jim,

> To:       address@hidden
> From: Jim Mansbridge <address@hidden>
> Organization: CSIRO
> Keywords: 199510101100.AA03287

In the above message you wrote:
 
> I have a problem with the creation of some netcdf files.  The behaviour
> is reproducible, but I have been unable to produce a small example of
> the problem.  I believe that my problem may be due to a netcdf bug
> because
> 
> 1) my code works fine on a Cray J90, but not on a sparc 20 running
> sunos4.1.3, and
> 
> 2) examination of the faulty netcdf file shows that the header
> information (about the dimensions, attributes, etc) is written twice.
> 
> I am using netcdf to produce restart files for a numerical model.  I
> produce the faulty file as follows.
> 
> 1) I run my numerical model and produce the restart file.  This file is
> fine and I make a copy of it called hist_09c_1.nc.
> 
> 2) I run the numerical model again and this time, instead of creating a
> new restart file, I overwrite the old one.  I now copy the restart file
> as hist_09c_2.nc.  I would expect the restart files to be identical,
> each containing one 'snapshot' of the model results.  (The time
> dimension is unlimited.)
> 
> However hist_09c_2.nc is 56 bytes longer than hist_09c_1.nc and the data
> is scrambled.  As mentioned earlier, the header information is written
> to hist_09c_2.nc twice.  The second writing is 8192 bytes into the
> file.  Likewise, the data is mostly offset by 8192 bytes although there
> must be some sort of wraparound since the file is only 56 bytes longer
> than the original.  It is hard to see where the wraparound occurs since
> most of the data are zeros.
> 
> I have put the 2 netcdf files in my anonymous ftp directory at
> ftp.ml.csiro.au/pub/mansbrid if you want to look at them.
> 
> Has this type of problem arisen before? Do you have any idea what the
> cause could be?

I have no idea what could be causing this problem.  We'll have a look at
the files and will probably have some questions for you.

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