Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Help! I'm having a problem writing out some data and can't seem to figure it out. It's probably something stupid. However, first let me vent some spleen. <rant on> First off, let me say that I'm getting pretty fed up with RSinc's handling of HDF. The documentation sucks, there's no description of how to go about reading and writing files except in as much as you may already know from reading and writing files using the fortran/c HDF API. If it weren't for Dave Fanning's web site, I'd still be beating my head against this. It seems to me that the reason RSI put together an IDL based interface for HDF files is so that we users can get at the data without having to know that much about HDF, but the information given in the help files seems to presuppose knowledge of the fortran/C interface usage and practice. For instance, the help for HDF_SD_START doesn't tell you what value it returns on failure. I've gathered, from looking at Dave Fannings 'hdfwrite,' that you should capture failures using the 'catch' routine. If that's so, why doesn't the help say so? In fact, why doesn't it mention that HDF_SD_START will fail if a second attempt to open an interface to the same file occurs when there is some HDF interaction ongoing? I'm able to crash IDL in this manner, see below. <rant off> In anycase, my specific problem is this. On the 1st call the routine given below fails at the call to HDF_SD_END, whereupon it is caught by the 'catch' statement at the top of the routine, which emits the message: % HDFPROB: HDF_SD_END: Unable to close the HDF-SD interface (SD_ID=268993044). Fileid= xxxxxxxx If I immediately call it a second time, it fails again, emitting the following message: % HDFPROB: HDF_SD_START: Unable to start the HDF-SD interface. Which make sense, since the previous attempt to end the interaction to the same file failed. The 3rd call causes a core dump from a segmentation violation. Can anyone tell me why the first call fails at HDF_SD_END? I don't really care about the 2nd and subsequent calls, I just did those to try and characterize the behaviour a little more. ;----------------- test routine -------------------- PRO hdfprob cd,'/tmp' catch,error IF error NE 0 THEN BEGIN print,'' Message,!error_state.msg,/cont IF n_elements(fileid) NE 0 THEN print,'Fileid= ',fileid return END u = fltarr(360,121) v = u longname = 'big_problem_with_hdf' shortname = 'hdfprob' lonpar = [0.,359,1] latpar = [-60.,60.,1] nlon = 360 nlat = 121 version = '' starttime = '' endtime = '' creationtime = '' region = [lonpar[0],latpar[0],lonpar[1],latpar[1]] caldata = {cal:1.0d, cal_err: 0.0d, offset:0.0d, offset_err:0.0d, Num_Type:0l } caldata.Num_type = 5 tfilename = 'hdfprob.hdf' fileid = HDF_SD_START(tfilename,/create) HDF_SD_ATTRSET ,fileid ,'LONGNAME',strtrim(LongName[0],2) HDF_SD_ATTRSET ,fileid ,'VERSION',strtrim(Version[0],2) HDF_SD_ATTRSET ,fileid ,'STARTTIME',strtrim(StartTime[0],2) HDF_SD_ATTRSET ,fileid ,'ENDTIME',strtrim(EndTime[0],2) HDF_SD_ATTRSET ,fileid ,'CREATIONTIME',strtrim(CreationTime[0],2) HDF_SD_ATTRSET ,fileid ,'SHORTNAME',ShortName HDF_SD_ATTRSET ,fileid ,'NLON',nlon,/short HDF_SD_ATTRSET ,fileid ,'NLAT',nlat,/short HDF_SD_ATTRSET ,fileid ,'REGION',region,/float HDF_SD_ATTRSET ,fileid ,'LONPAR',lonpar,/float HDF_SD_ATTRSET ,fileid ,'LATPAR',latpar,/float USdsId = HDF_SD_CREATE( fileid, "U",[nlon,nlat],/float) VSdsId = HDF_SD_CREATE( fileid, "V",[nlon,nlat],/float) HDF_SD_ADDDATA, USdsId, U HDF_SD_ADDDATA, VSdsId,V HDF_SD_SETINFO, UsdsId, caldata=caldata HDF_SD_SETINFO, VsdsId, caldata=caldata HDF_SD_ENDACCESS, USdsId HDF_SD_ENDACCESS, VSdsId HDF_SD_END, fileid end ;----------------- end test routine --------------------------- -- I don't speak for JPL, it doesn't speak for me. Well, not all the time, at least. William Daffer <vapuser@haifung.jpl.nasa.gov>
In article <36225DB1.4D5467C5@kraken.atmos.colostate.edu> "El-Kady, Mostafa" <mostafa@kraken.atmos.colostate.edu> writes: Hi; It's me (vapuser a.k.a. William Daffer) posting from another server. Thanks for responding. I did discover the problem was in the null values of these strings after I played around with it. However, this strikes me as a bug. Particularly since no error was thrown. Anybody else have a call on this? > I think the problem is with these null attributes: > > starttime = '' > starttime = '' > endtime = '' > creationtime = '' > > Putting a value (even a blank character) would run your program ok. > > Hope this helps > -- My mail address has been mangled by my mailer. Send replies to... daffer@primenet.com -- Outside of a dog, a book is man's best friend Inside of a dog, it's too dark to read. Groucho Marx.