This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>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.