>From: "HOETH, BRIAN R. (JSC-ZS) (LM)" <address@hidden> >Organization: JSFC >Keywords: 200211192250.gAJMoQ427093 Hi Brian, I will not have time to look into the 2.5 degree AVN for awhile. I can say, however, that I am suprised by this since the mods I made in the gribdec.tar.Z bundle got folded back into the McIDAS-XCD v2002 release, and XCD is decoding the 2.5 degree AVN stuff in NOAAPORT with seemingly no problems. Tom >OK, I ran it with the original gribdec and had the same problem ... > >(sorry, I forgot to CC Unidata Support on the first email, read below if you >are Unidata Support and you are not Tom ...) > >-----Original Message----- >From: HOETH, BRIAN R. (JSC-ZS) (LM) >Sent: Tuesday, November 19, 2002 4:39 PM >To: Tom Yoksas (E-mail) >Subject: RE: 20020506: Unidata gribdec.tar.Z bundle (cont.) > > >Tom, > >We're finally getting around to implementing the GRIBDEC stuff here and I've >run into yet another roadblock? The decoder seems to have a problem >handling the forecast times for the 2.5 degree GFS (aka AVN) GRIB files? I >grabbed the 384 fcst file from today's 00Z run from: > >ftp://tgftp.nws.noaa.gov/SL.us008001/ST.opnl/MT.avn_CY.00/RD.20021119/PT.gri >d_DF.gr1 > >(Note: Depending on when you try this link, it may not work. You'll have >to use the appropriate subdirectory for the current day after the "RD." part >of the directory string) >(Note2: The 2.5 degree file I'm interested in is called >"fh.0384_tl.press_gr.2p5deg") > >When I run GRIBDEC on the GRIB file and then do a GRDLIST, only 39 of the >GRIB records have the correct FHOUR=384? > >Any thoughts? > >Thanks, >--------------- >Brian Hoeth >Spaceflight Meteorology Group >Johnson Space Center >Ph: 281-483-3246 >Ops: 281-483-1051 > >P.S. - I've made some minor mods to the original code that is in >gribdec.tar.Z in order to get the code to decode larger GRIB messages and I >added a bunch of levels in Mcmkmcgrid.c, but I really don't think that these >mods would affect the forecast times? I guess I'll try using the original >code though and see what happens just to make sure that my mods didn't screw >something up. > > >-----Original Message----- >From: Unidata Support [mailto:address@hidden >Sent: Monday, May 06, 2002 11:52 AM >To: Hoeth, Brian >Cc: 'Unidata Support'; Batson, Bryan; 'Wahner Paul Contr CSR4500'; >address@hidden; address@hidden >Subject: 20020506: Unidata gribdec.tar.Z bundle (cont.) > > >>From: "Hoeth, Brian" <address@hidden> >>Organization: JSFC >>Keywords: 200205011845.g41IjMa25331 McIDAS gribdec.tar.Z > >Brian, > >>Thanks for all your help!! I have picked up the new software and it seems >>to be decoding the 8km data just fine. > >Sounds promising :-) > >>Now it's choking on a few messages in some of the ETA 12km data I've been >>experimenting with. I've been debugging through the code and I've found >>where the decoder is choking. It seems to be in the grib_dec_is routine. > >Do you have an example file I can use for debugging. A URL to a dataset >would also work. > >>The return value is -2 which means that the IS length appears too long. I >>noticed that the grib.h file has the GB_MAX_MSG_LEN parameter that is being >>used to compare the length of the IS with. I diff'd your version of grib.h >>with what's currently in xcd7.8/src and I see that you increased this >>parameter from 200000 to 400000. Is there any reason why you chose 400000 >>other than it was "bigger"? > >No, not really. The code was written by a Fortran programmer programming >in C. There should not be any hardwired lengths of arrays, only checks >for reasonableness of the size of the sections of grib messages. This >is a major change that needs to be made in the grib decoding in McIDAS. > >>Anyways, I went ahead and increased the length of this parameter (and >>GB_MAX_DATA_PTS while I was at it) to 600000 and the grib decoder still >>didn't work? > >Interesting. > >>So, I did some more digging and found that I needed to >>increase the MAXGRIDPT value in gridparm.inc also. So, I increased this >>value to 600000 also and everything worked out great! > >Hmm... gridparm.inc is mainly used in McIDAS display/analysis routines, >not in any XCD routine. I would not have expected that a change in >gridparm.inc would result in the decoder working for larger grib messages. >Now, I would have expected a change in grib.h to make a difference. > >>Will increasing GB_MAX_MSG_LEN, GB_MAX_DATA_PTS, and MAXGRIDPT to 600000 >>have any ill affects to any of the McIDAS code? Seems to display fine with >>GRDDISP? >Just remember that as you increase MAXGRIDPT, the size of GRID McIDAS >analysis >routines grow proportionately.
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.