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.
> My name is Per Nyberg. I believe that we crossed paths a few months ago > when you were porting netcdf to the SX-4 in Houston. > We have come across some problems using the latest version of netcdf-3.3a. > Essentialy the runs when compiled withe latest version abort with the > following message: Per: Sorry it has taken so long to get back to you. I've been on vacation and the like. The message was not in our support tracking system since it was sent to me directly rather than to address@hidden. Otherwise, other staff people would have responded, or at least beaten on me to respond :-). > We have come across some problems using the latest version of netcdf-3.3a. > Essentialy the runs when compiled withe latest version abort with the > following message: > > ncclose: ncid 0: Not a netCDF id In the absence of some internal netcdf problem (a definite possibility on the SX4 platform), this error would indicates that the netcdf id (0?) does not represent a netcdf id. Several user programs have been stung by assumming that the netcdf id's start at zero for the first netcdf open'ed, one for the next, and so on. This happens to be the way it used to work, but the documentation makes no promise. The documentation simply says "(a netcdf id) is a small non-negativeinteger ... much like a file descriptor in C or logical unit number in fortran". In netcdf-3, the netcdf id _is_ the file descriptor. In a simple program, file descriptors 0, 1, and 2 are in use at program startup as standard input, standard output and standard error, so, the ncid returned from the first call to nc_open() would be 3. In general, the ncid has to be stored in a variable and the value of that variable used. You might also see the above error if the netcdf file had already been closed in another module. > > Below is one of our analysts description of the work-around. > > What are your thoughts ? Could you provide some advice ? I don't see how the modifications below relate to the problem you report. > Forwarded message: > > So far BOM has apparently not used any version of > > NETCDF beyond NETCDF 2.4. > > I wonder if you could check with NCAR what they think about the incompatibilty, > > perhaps they have found it themselves too and added some compatibility feature ? > > > > Here is what I did to get BENCH04 with NETCDF 3.3a operational. > > > > #1 - fully recompile BENCH04 with the header file "netcdf.inc" for NETCDF 3.3a. Good. Must be done. > > #2 - Modify 4 calls to NCVDEF in NETINI: > > example: > > SEGid = NCVDEF (NCHISTFid, SEGname, NCLONG, 0, 0, IRET) > > | | > > | array of ndims dimensions IDs > > number of dimensions of variable > > into: > > SEGid = NCVDEF (NCHISTFid, SEGname, NCLONG, 1, 1, IRET) > > > > Same applies to the calls: > > BDATEid = NCVDEF (NCHISTFid, BDATEname, NCLONG, 0, 0, IRET) > > BHOURSid = NCVDEF (NCHISTFid, BHOURSname, NCLONG, 0, 0, IRET) > > IHDELTid = NCVDEF (NCHISTFid, IHDELTname, NCLONG, 0, 0, IRET) This is probably wrong. You are changing a "scalar" variable into a vector. The fifth argument (VDIMS) needs to be an array (or the constant 0 is acceptable when NVDIMS is 0). The constant 1 is incorrect. > > #3 - Introduce a dirty fix in routine ncvarinq in file v2i.c of NETCDF: > > After: > > const int status = nc_inq_var(ncid, varid, name, datatype, &nd, dim, &na); > > Insert: > > if ( nd == 0 ) nd=1; > > > > This fix appears to be necessary when reading variables from file > > which have been written under NETCDF 2.3.2 or older with the > > NCVDEF call pattern as described under #2. This "fix" is very wrong. I guess the guy had to do that because of the misunderstanding in #2. -glenn