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.
>To: address@hidden >From: Jason Thaxter <address@hidden> >Subject: Re: 20030715: perl interface problem, plus ncdump oddity >Organization: GoMOOS >Keywords: 200309161520.h8GFKSLd005087, ncdump, FreeBSD, gcc Jason, > Likewise, sorry for the delay in responding, but this isn't an old > freebsd system... if you test on older systems you may find no > problem at all. Nevertheless, I do have easy access to both current > FreeBSD branchesn- the 4.x branch, which is stabler but destined for > obsolescence, and the 5.x branch, which is the future, but still > less stable than other FreeBSD (and is still pretty darn stable). > > The only relevant differences I can see will be libc versions and > gcc versions... So from that, it sounds as if the problem is a bug in the older libc or gcc versions on the FreeBSD system, rather than a bug in ncdump or the netCDF library. Nevertheless, I just build netCDF 3.5.0 on a FreeBSD 4.7 system: % uname -a FreeBSD emo.unidata.ucar.edu 4.7-STABLE FreeBSD 4.7-STABLE #0: Fri Jan 24 15:53:42 MST 2003 address@hidden:/usr/obj/usr/src/sys/MYKERNEL i386 and tried the resulting ncdump on your netCDF file. It appears to work fine, with the correct time = 2452281, 2452281.04166667, 2452281.08333333, ... rather than the bug you were seeing with five other values between each correct time value: time = 2452281, 1345.53613472733, 4.16077581271464e-317, 4.16077581271464e-317, 6.4131214821086e+17, -0.0556587280591438, 2452281.04166667, 214.527954340916, 36700.1563112745, 1720.32031441483, 4.70626367892367e+16, 2.11248055210126e+25, 2452281.08333333, ... But I saw other differences in the netcdf-ncdump-questionable output you sent that might indicate the ncdump you are using on that system is not from netCDF 3.5.0, but from a considerably older version, perhaps netCDF 2.4.3. For example, in netcdf-ncdump-questionable, the following attributes values are printed using an older syntax: air_temperature_qc:_FillValue = '\200' ; air_temperature_qc:valid_range = '\0', '\177' ; air_temperature_qc:quality_good = '\0' ; air_temperature_qc:quality_bad = '\1' ; whereas in the ncdump output I see from netCDF 3.5.0 on FreeBSD 4.7 and all other platforms, these appear instead as: air_temperature_qc:_FillValue = -128b ; air_temperature_qc:valid_range = 0b, 127b ; air_temperature_qc:quality_good = 0b ; air_temperature_qc:quality_bad = 1b ; using the "b" suffix for byte constants that has been used in all netCDF 3.x versions of ncdump, as far as I know. Also in nettcdf-ncdump-questionable, there are commas before the constants in some data lists: air_temperature = 4.657 , 3.669 , 4.018 , which was a bug fixed a long time ago, so that ncdump output in 3.5.0 and subsequent versions is: air_temperature = 4.657, 3.669, 4.018, So could you please check where you are getting the ncdump used on your FreeBSD system, by using "which ncdump", for example. If you built but inadvertently didn't install the ncdump from version 3.5.0, you may be using a much older version that had bugs that have long since been fixed. If the output you sent me was actually from a 3.5.0 version of ncdump, I will be very surprised. --Russ