[netCDF #ELT-595336]: Possible NC_MAX_DIMS vs NC_MAX_VAR_DIMS mixup in nc4internal.h

Hi Greg,

> Both netcdf-4.2.1.1 and netcdf-4.3.0 have the following in nc4internal.h:
> 
> /* This is the metadata we need to keep track of for each
> netcdf-4/HDF5 file. */
> typedef struct  NC_HDF5_FILE_INFO
> {
> NC* controller;
> hid_t hdfid;
> int flags;
> int cmode;
> int nvars;
> int ndims;
> int natts;
> int parallel;  /* true if file is open for parallel access */
> int redef;
> int fill_mode;
> int no_write; /* true if nc_open has mode NC_NOWRITE. */
> NC_GRP_INFO_T *root_grp;
> short next_nc_grpid;
> NC_TYPE_INFO_T *type;
> int next_typeid;
> int next_dimid;
> int ignore_creationorder;
> int hdf4;
> int sdid;
> 
> #ifdef USE_PNETCDF
> /* pnetcdf_file will be true if the file is created/opened with the
> * parallel-netcdf library. pnetcdf_access_mode keeps track of
> * whether independpent or collective mode is
> * desired. pnetcdf_ndims keeps track of how many dims each var
> * has, which I need to know to convert start, count, and stride
> * arrays from size_t to MPI_Offset. (I can't use an inq function
> * to find out the number of dims, because these are collective in
> * pnetcdf.) */
> int pnetcdf_file;
> int pnetcdf_access_mode;
> int pnetcdf_ndims[NC_MAX_VARS];
> #endif /* USE_PNETCDF */
> 
> } NC_HDF5_FILE_INFO_T;
> 
> Note the definition of "pnetcdf_ndims[NC_MAX_VARS]" with the description
> "pnetcdf_ndims keeps track of how many dims each var has..."
> 
> Should the NC_MAX_VARS instead be NC_MAX_VAR_DIMS since it it referring
> to the dims per var?  I know that these defined as the same in the
> distributed version of netcdf; however, we greatly increase NC_MAX_VARS
> and decrease NC_MAX_VAR_DIMS, which results in a difference of
> dimensioning the array of 524,888 vs 8 which is a big savings for each
> file_info struct.

No, sorry, that really should be NC_MAX_VARS, because pnetcdf_ndims[varid] holds
the rank of the variable identified by varid.  It might be possible to just 
inquire what the rank is whenver it's needed and get rid of that large 
allocation
of usually unneeded space in the structure.

I'll put this in a Jira ticket.

--Russ

> --Greg
> 
> 

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



Ticket Details
===================
Ticket ID: ELT-595336
Department: Support netCDF
Priority: Normal
Status: Closed