Hi David, > I have been working on a big netcdf 4 file with lots of groups, variables > and dimensions and have run into a problem where I believe the file is > correct as shown in netcdf java, but the ncdump result is wrong! > > From NetCDF Java NCDUMP: > float abg(abn=2, oxo=6); > :_FillValue = -999.99f; // float > :units = "Very long..."; > :long_name = "sed/abv/abi/abg is special sauce!"; > :scalar_grid_unit = "76412606.428"; > :coordinates = "abn rob"; > :maximum = -999.99; // double > :minimum = -999.99; // double > > From C ncdump: > float abg(abn, abn) ; > abg:_FillValue = -999.99f ; > abg:units = "Very long..." ; > abg:long_name = "sed/abv/abi/abg is special sauce!" ; > abg:scalar_grid_unit = "76412606.428" ; > abg:coordinates = "abn rob" ; > abg:maximum = -999.99 ; > abg:minimum = -999.99 ; > > The full path to the group containing the variable is: > /surface/sed/abv/abi > the variable name is abg. > > Unfortunately I had to obfuscate the names in the file to protect the > innocent. > > See the attached file... Thanks for this test file. It demonstrates what turned out to be a netCDF-4 library bug rather than an ncdump bug. Fortunately it's fixed in the latest release candidate netcdf-4.3.1-rc6, available from GitHub: https://github.com/Unidata/netcdf-c/releases/tag/v4.3.1-rc6 It's quite a coincidence that we got this fix from Quincey Koziol a couple of days before you reported the bug, and that the fix was for what appears to be an unrelated bug. I've attached the resulting ncdump output, using the above release, so you can verify whether it's now correct. --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: BCV-723604 Department: Support netCDF Priority: Normal Status: Closed
Attachment:
gtest-rc6.cdl
Description: Binary data