[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20021119: Unidata gribdec.tar.Z bundle (cont.)

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