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

Re: IDL 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: Re: IDL netCDF bug
  • Date: Fri, 29 Jul 1994 10:00:46 -0600
Hi Ken,

> I just got the new version of IDL (3.6), which includes netCDF support on
> the DEC Alpha OSF1 machines.  There is a bug when reading LONG arrays into
> IDL, i.e.,
> 
> Correct version (AIX)
> 
> IDL> id=NCDF_OPEN(myfile)
> IDL> NCDF_VARGET, id, 'ip',  iparams
> IDL> help, iparams
> IPARAMS         LONG      = Array(18)
> IDL> print, iparams
>         1980           1           1           1         458        1980
>            1          31          31         488           0          12
>           12          32          32         128         128       16384
> 
> 
> Incorrect version (OSF1)
> 
> IDL> id=NCDF_OPEN(myfile)
> IDL> NCDF_VARGET, id, 'ip',  iparams
> IDL> help, iparams
> IPARAMS         LONG      = Array(18)
> IDL> print, iparams
>         1980           0           1           0           1           0
>            1           0         458           0        1980           0
>            1           0          31           0          31           0
> 
> 
> As you can see, the correct values are interspersed with zeros, suggesting
> some kind of 32/64-bit conversion error.

Yes, apparently IDL is mapping netCDF `long's to C `int's rather than to the
type `nclong' (which is currently a C `long' on the Alpha but which will
eventually be changed to a C `int').  If they code such that the internal
type `nclong' is used to hold values of external type NC_LONG, then this
problem should disappear.  In an earlier note I sent to RSI, I recommended
this.

>>Unfortunately we have JUST released a new version (3.6.1). Your bug report
>>has been submitted to the development team and they will work on a fix
>>for the next release. However if the source of the problem is 
>>with the developers of the NETCDF code, as we have seen many times, this
>>takes some of the control out of our hands.

I've looked through our support archives and found exactly one netCDF bug
reported from RSI, and that was something we had already fixed and released
in netCDF 2.3.2.  RSI was apparently still using a much older version, more
than a year after the release of netCDF 2.3.2.

> Do you know of any such problems in the Alpha/OSF1 version of netCDF?

Our currently released version netCDF 2.3.2pl2 passes the stringent testing
in the nctest program on Alpha/OSF1.  We know of no outstanding problems.

--
Russ Rew                                                   UCAR Unidata Program
address@hidden                                             P.O. Box 3000
http://www.unidata.ucar.edu/                             Boulder, CO 80307-3000