Re: [Opengrads-devel] errors on sdfopen with hdf

[Arlindo da S. <da...@al...>]

On Feb 6, 2008 2:27 PM, Jennifer Adams <jm...@co...> wrote:

>
> On Feb 6, 2008, at 1:09 PM, Arlindo da Silva wrote:
>
> On Feb 6, 2008 10:44 AM, Jennifer Adams <jm...@co...> wrote:
>
> >
> > Arlindo,
> > I have put some print statments in gasdf.c to see why this is happening.
> > The HDF routine SDdiminfo returns the following information on
> > model.hdf:
> >
> > dim_id,name,dimsize,dtype,ndatts = 327680 time 0 6 1
> > dim_id,name,dimsize,dtype,ndatts = 327681 longitude 72 6 2
> > dim_id,name,dimsize,dtype,ndatts = 327682 latitude 46 6 2
> > dim_id,name,dimsize,dtype,ndatts = 327683 levels 7 6 5
> >
> > Looks like the file has a time dimension of size 0. I remember now
> > that when I discovered this during development, I put in the
> > following line:
> >        if (dimsize==0) dimsize=1; /* would you have a coordinate axis
> > with
> > size==0 */
> >
> > The interesting thing is that when I run ncdump (from the HDF4.2r2
> > library build) it gives me this:
> >
> > dimensions:
> >         time = UNLIMITED ; // (5 currently)
> >         longitude = 72 ;
> >         latitude = 46 ;
> >         levels = 7 ;
> >
>
> It is possible that this is a bug in the SD interface. Ncdump uses the
> "NC" interface which is sometimes a more basic, low level interface than
> SD.  (I say "sometimes" because the hdf-4 is not so cleanly layered). I
> suspect that your ctl/"DTYPE hdf" interface will have similar problems,
> correct?
>
> The 'dtype hdfsds' works fine because the required TDEF metadata is
> provided in the descriptor file -- is doesn't need to use SDdiminfo to
> discover the size of the time axis.
>

However, can it access variables for t>1? It is possible that the library
has checks for not allowing access beyond the dimension size.


>
> The file "model.hdf" was written with the "NC" interface through LATS. Leading
> to this version of hdf-4, I reported a couple of bugs to THG in the hrepack
> utility which  did not work properly with HDF files written by the "NC"
> interface (all GMAO files are written that way, although LATS is not
> involved).  It is very possible that this is another one of those bugs.
>
>
> We have 2 options, report the bug to the THG (we will need a small example
> demonstrating the problem), or try to dig in the hdf-4 sources and
> contribute a patch to them. They have usually being very responsive to my
> bug reports. What do you prefer?
>
>
> As I see it, there is a bug in the lats4d pathway that creates hdf files,
> not in the v2 code that reads them.
>

It is always possible, but I find it very unlikely. I am in the middle of a
day long meeting. I'll confirm later in day whether the same problem occurs
with the official GMAO files which do not involves LATS at all. I expect it
does.

    Arlindo.

-- 
Arlindo da Silva
da...@al...