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

>From: "HOETH, BRIAN R. (JSC-ZS) (LM)" <address@hidden>
>Organization: JSFC
>Keywords: 200211192250.gAJMoQ427093 McIDAS gribdec gbtbpds001.bv1

Brian,

>Well, I'm heading out for the holidays.

Slacker ;-)  Have a good one...

>I've attached the Mcmkmcgrid.c code that I modified.

OK, thanks.  I had already jumped on Mcmkmcgrid.c before getting this
note.  I incorporated your changes with mine in the ConvertLevel
routine.  I also made a modification in the ConvertForecast routine to
correct the cause of forecast hours > 256 not being decoded correctly
(as per your earlier note).

>I'll try to mess around with your other suggestions when I
>return next week.

I put a new gribdec.tar.Z file out in the unix/gribdec directory of
passworded FTP (for user 'umcidas') on our FTP server,
ftp.unidata.ucar.edu.  This has all of your and my changes, so it
should be set to grab, build, and use.

>Take care!

Later...

Tom

>From address@hidden Wed Nov 20 13:40:08 2002

Tom,

The strange part is, it actually doesn't appear to incorrectly decode ALL of
the 2.5 degree GRIB data.  It's just decoding improperly for forecast hours
beyond 252 hours (i.e. fcst hrs 264-384)?  For these hours, the majority of
the GRIB messages put a FHOUR that is exactly 256 hours less than what it's
supposed to be?  (Examples:  (1) for 384 hr fcst, the majority of the FHOURs
are 128, (2) for 264 hr fcst, the majority of the FHOURs are 8)

I will probably look into why this is happening when I have a chance to come
up for air and I will share with you what I find.  I just wanted to check
with you first in case you were aware of something.

How would I set up XCD to decode the 2.5 degree AVN stuff?  I assume I just
add an entry into RTMODELS.CFG?

Thanks,
Brian   

-----Original Message-----
From: Unidata Support [mailto:address@hidden]
Sent: Wednesday, November 20, 2002 1:28 PM
To: HOETH, BRIAN R. (JSC-ZS) (LM)
Cc: address@hidden
Subject: 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.gr
i
>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.


****************************************************************************
<
Unidata User Support                                    UCAR Unidata Program
<
(303)497-8643                                                  P.O. Box 3000
<
address@hidden                                   Boulder, CO 80307
<
----------------------------------------------------------------------------
<
Unidata WWW Service                        http://www.unidata.ucar.edu/
<
****************************************************************************
<