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

Re: 970108: Bug in netCDF 2.4.3

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: 970108: Bug in netCDF 2.4.3
  • Date: Wed, 08 Jan 1997 11:19:30 -0700
>To: address@hidden
>From: Konrad Hinsen <address@hidden>
>Subject: Bug in netCDF 2.4.3
>Organization: Laboratoire de Dynamique Moleculaire, Institut de Biologie 
>Structurale
>Keywords: 199701081017.DAA11848

Hi Konrad,

> first of all, thanks for netCDF. It's just what I need for my daily
> work in computational chemistry.

Thanks for letting us know that it's useful to you.

> I think I found a bug in the current version. I was trying to create a
> file with one variable for a 3x3 matrix representing a tensor. The
> file had just one dimension, xyz = 3, and the variable was to be defined
> as polarizability(xyz, xyz). But ncvardef() didn't like that definition
> and claimed "Invalid Argument". Looking at the source code in var.c
> I found the following test:
> 
>       if(ndims > 0 )
>       {
>               if(handle->dims == NULL || ndims > handle->dims->count )
>               {
>                       NCadvise(NC_EINVAL, "Invalid number of dimensions %d > 
> %d",
>                               ndims, (handle->dims != NULL) ? 
> handle->dims->count : 0) ;
>                       return(-1) ;
>               }
>       }
> 
> This means I can't create a variable whose rank is higher than the
> number of dimensions defined in the file. It doesn't take into account
> the possibility of using one dimension more than once in a variable
> definition.
> 
> I suspect the second part of this test (ndims > handle->dims->count)
> can be removed without causing any harm, since the dimension ids
> will be checked for validity later on anyway.

Yes, this is a bug in netcdf-2.4.3, but it's fixed in the current alpha
release of the netCDF-3 C interface, available as

   ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-3.1a.tar.Z

Thanks for reporting the problem.  One inelegant workaround, if you
don't want to recompile the source or try alpha pre-release, would be to
add another dimension of size 1 but not use it.

--Russ

_____________________________________________________________________

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