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

[Jennifer A. <jm...@co...>]

On Feb 6, 2008, at 3:36 PM, Arlindo da Silva wrote:

>
>
> 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.

Here's the descriptor:
dset ../../opengrads/pytests/data/model.hdf
dtype hdfsds
title test
undef -8888 missing_value
xdef 72 linear 0 5
ydef 46 linear -90 4
zdef 7 levels 1000 850 700 500 300 200 100
tdef 5 linear 00Z01JAN1987 1dy
vars 1
ua 7 t,z,y,x Eastward wind [m/s]
endvars

All 5 time steps are displayed.

>
>
>
>> 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.
By "lats4d pathway" I meant include the use of the HDF library to  
write out the files. It may not be in the LATS code proper, but it's  
somewhere along the line between the lats4d command at the GrADS  
command prompt and the output file model.hdf.
Jennifer

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

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...