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

[netCDF #CLE-157193]: broken url for netcdf 4.1 source code



Hi John,

> from the url http://www.unidata.ucar.edu/downloads/netcdf/netcdf-4_1/index.jsp
> 
> The following link appears to be broken for downloading the source code for 
> netcdf 4.1:
> 
> http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.1.tar.gz

Yes, 4.1 was temporarily withdrawn when a bug was discovered that had to be 
fixed in a new 4.1.1 release, which will be available early next week.  I've 
appended the text from the netcdfgroup mailing list that was posted about this 
earlier today.

--Russ

> Jeff Whitaker wrote:
>>
>> Ed et al:  Here's a simple C program that produces an incorrect
>> netcdf file with netcdf-4.1
>
> Can anyone confirm or deny that this is a real bug?  I noticed that
> netcdf-4.1 was pulled from the ftp site, so I guess that means someone
> is working on it ....
>
> -Jeff

Howdy Jeff!

Yes, indeed, this is a real bug. I have taken down 4.1 as a result, and
we are preparing a release with a fix.

The bug itself manifests itself under the following circumstances: if
you define dimensions, then you define a coordinate variable, and write
to it, and then another coordinate variable, and if the coordinate
variables are in a different order than the dimensions, on re-reading
the file, netcdf-4.1 will be confused.

A key part of activating the bug is that you write some of the
coordinate variable data before defining all the coordinate
variables. That is, if you call all the nc_def_var calls for the
coordinate variables before writing any of their data, things will work
fine. You must also be writing the dimensions and the coordinate
variables in different orders to see this bug. If you defined the
coordinate variables in the same order as you defined the dimensions,
writing them before defining all of them would not be a problem.

The way to check for this problem is to do an ncdump -h of the file and
see if the dimension information in the ncdump is correct. In C it can
be detected by closing the file, re-opening it, and checking the
dimension ids of the variables.

And as for your reference to "working on it," well, aren't we always?
;-)

I will announce when we have a new release. The data files produced with
4.1 will be readable after I get the fix in place - the problem is in
reading the file, it is written out just fine.

Unfortunately this happens at a time when I have scheduled a short trip
to see some family. However you can be sure this is my top programming
priority.

My apologies for any problems or inconvenience this may cause to any
users. With extensive automated testing we hope to ensure that each
release of netCDF is bug-free, but sometimes one slips through the
net...

Thanks,

Ed
-- 
Ed Hartnett  -- address@hidden

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



Ticket Details
===================
Ticket ID: CLE-157193
Department: Support netCDF
Priority: Normal
Status: Closed