Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Ed Hartnett wrote:
Jeff Whitaker <jswhit@xxxxxxxxxxx> writes:Jeff Whitaker wrote:Ed et al: Here's a simple C program that produces an incorrect netcdf file with netcdf-4.1Can 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 .... -JeffHowdy 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? ;-)
Thanks Ed - I had no doubts about that. I just wanted confirmation that the problem wasn't just me doing something stupid.
If I might be so presumptious as to offer a suggestion for avoiding this in the future (it also happened with the 4.0 release if I remember correctly).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...
Let the release candidate become the actual release after some period of the time with no bug reports (say 2 weeks?). A lot more people actually exercise the release candidates and beta versions than the snapshots In both 4.0 and 4.1 a bug was introduced in between the last release candidate and the final release, and could only be detected if you were running the snapshots. Real users will always do things that your automated testing won't.
-Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jeffrey.S.Whitaker@xxxxxxxx 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
netcdfgroup archives: