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

[netCDF #QHD-994079]: Strange Output From nc_inq_dim---Part 2

Tony,

> I think I see the progression.  Have a look:
> 
> From the second gdb snippet function nc_inq_dim (in
> netcdf-4.1.1/libsrc4/nc4dim.c) calls nc3_inq_dim on line 235-236.
> In netcdf-4.1.1/libsrc/nctonc3.h, line 40 says: #define nc_inq_dim
> nc3_inq_dim
> Function nc_inq_dim (nc3_inq_dim) in netcdf-4.1.1/libsrc/dim.c line 405
> starts, as noted in the second gdb snippet.
> In dim.c/nc_inq_dim, function NC_check_id is called (line 411).  A
> function with this name is in file netcdf-4.1.1/libsrc/nc.c line 71.  A
> function with the same name is in hdf-4.2r1/mfhdf/libsrc/file.c line
> 43.  The function in hdf-4.2r1/mfhdf/libsrc/file.c is executed...I'm not
> sure why.

Aha!  Because you're using shared libraries, there is no multiple
definition of the same function name at link time.  Instead, the
first function that's found with the right name at execution time is
loaded and called.  If you're going to use both HDF4 and netCDF in
the same application, I believe you have to build HDF4 with the 
-DHAVE_NETCDF compile flag, so that HDF4 functions with the same name
as netCDF functions get renamed to have an "SD_" prefix.

There is some discussion of this in the HDF4 INSTALL document:

   To use the HDF/MFHDF libraries(libdf.a, libmfhdf.a) with the
   original netCDF library(libnetcdf.a) the HDF/MFHDF distribution
   must be compiled with the option '-DHAVE_NETCDF'. This will rename
   the HDF version of the C-interface(ncxxx) of the netCDF API to
   sd_ncxxx to avoid clashing with the original netCDF API from
   libnetcdf.a. Currently there is no support for renaming the netCDF
   Fortran interface stubs. As such the HDF/MFHDF distribution must be
   compiled without fortran support. HDF Users can still access
   HDF/netCDF files through the SDxxx interface but not through the
   ncxxx interface unless the renamed interface is used(sd_ncxxx).

> On line 51 file.c prints on the screen "3 is not a valid cdfid".

So that error message did not come from the netCDF library, it came from
the HDF mfhdf library.

> Does this look to you like what is happening?  I don't know of a
> solution to this.  Is there one?

If you can rebuild the HDF4 library from source as instructed above, it
ought to work.

Also there was a note from the HDF Group help desk that may be relevant:

  http://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg02412.html

--Russ

> On 1/17/2011 8:29 PM, Unidata netCDF Support wrote:
> > Hi Tony,
> >
> > Sorry to have taken so long to respond to your question ...
> >> Has anyone had a chance to look at this problem? Do you need more
> >> information?
> > I looked at it briefly, but was unable to make any progress on it,
> > because there isn't enough information for us to reproduce the problem
> > here, so we can diagnose it.  It doesn't appear to ba a netCDF
> > problem, but rather a problem in the calling code.
> >
> >> What I am trying to do: Write a netCDF4 to hdfeos2 converter called
> >> netCDF2hdfeos.
> >>
> >> Status: Wrote at least 90% of the code. Compiled it. Receiving strange
> >> output from nc_inq_dim. After giving this output the program dies.
> >>
> >> The strange output: netcdf: 3 is not a valid cdfid
> > That is not output from the netCDF library.  The string "not a valid
> > cdfid" doesn't appear anywhere in the netCDF library source code, as
> > far as I can determine.  So whatever is producing that output must be
> > in your code that calls nc_inq_dim, but it's not in any of the program
> > sources you attached.
> >
> > A guess at what might be happening is that your code is assuming that
> > the dimension IDs in any group are just the consecutive integers from
> > 0 to the number of dimensions in the group.  That's true for netCDF-3
> > files but not for netCDF-4 files that use groups.  Instead, dimension
> > IDs are assigned globally within a netCDF-4 file in the order in
> > which they are defined, so the IDs in a particular group may not be
> > consecutive integers.  So if are trying to access a dimension name or
> > length corresponding to a dimension ID with the value 3, for example,
> > it may be in a different group than the group ID you supply to
> > nc_inq_dim (the first argument).  The way to determine the dimension
> > IDs in a group is to use the new function nc_inq_dimids.  Then you can
> > use nc_inq_dim on each of the dimids that are returned by
> > nc_inq_dimids.
> >
> >> Why I think it is strange: I briefly looked at the netCDF4 code and it
> >> looks to me like it is doing what it is suppose to. Why it is crashing
> >> is a mystery. Any help will be much appreciated!!!!!! I repeat MUCH
> >> APPRECIATED!!!!!!!!
> >>
> >> Attached are code snippets and debugger (gdb) snippets. Function main
> >> (netCDF2hdfeos.c) calls function get_schema (line 115). Function
> >> get_schema (get_schema.c) calls function inq_dims (line 74). Function
> >> inq_dims (inq_dims.c) calls nc_inq_dim (line 47). Function nc_inq_dim
> >> crashes.
> > Sorry, but we can't figure out much from the gdb snippets in this case.
> >
> > --Russ
> >
> > Russ Rew                                         UCAR Unidata Program
> > address@hidden                      http://www.unidata.ucar.edu
> >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: QHD-994079
> > Department: Support netCDF
> > Priority: High
> > Status: Closed
> >
> 
> 

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



Ticket Details
===================
Ticket ID: QHD-994079
Department: Support netCDF
Priority: High
Status: Closed