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

20021206: 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,

re: GB_MAX_MSG_LEN and MAXGRIDPT

>Actually I think you did think about the ramifications, you just may not
>remember?

This is likely.

>Awhile back, I had actually increased GB_MAX_MSG_LEN in grib.h
>and I ended up having to increase MAXGRIDPT in gridparm.inc

Right.  GB_MAX_MSG_LEN will control the maximum size of the grid that
will be decoded.  If this is larger than MAXGRIDPT, gribdec.k will
decode grids that McIDAS GRD* routines can not use.

>also and I asked
>you what the ramifications were and you said that "as you increase
>MAXGRIDPT, the size of GRID McIDAS analysis routines grow proportionately"

Right.  This is because of the fact that McIDAS routines that deal with
grids are written in Fortran, so arrays are declared to be of some size.
The program executables will grow because of the larger MAXGRIDPT values.
Since the largest grids contained in NOAAPORT right now are less than
400 Kpts, this will essentially be overkill for the great majority of
sites.

>(see attached email).   Is increasing the GRID McIDAS analysis routines a
>really bad thing?

Not for individual use.  There gets to be a problem when changing the
maximum grid size, however.  ADDE remote servers could be attempting
to serve grids that are bigger than clients can handle.  This is no
big deal for folks who know what they are doing, but it is a big deal
for novices/students/infrequent users.

>I wasn't sure, which is why I ended up going with the
>"other solution" of editing Mcgribdecoder.c.

The result is the same.  You may end up decoding grids that are larger
than your McIDAS-X build is able to deal with.  For you this is no
problem, since you will know that you will need to modify your
gridparm.inc file and rebuild your -X distribution.

re: what is GFS

>GFS is the new name for the AVN/MRF model, sorry to confuse you.

I will know from now on (I am not a big grid user; I guess you can
tell that).

>I'm
>talking about the same 1x1 degree AVN GRIB product that we've been
>discussing recently (Example product for today located at
>ftp://tgftp.nws.noaa.gov/SL.us008001/ST.opnl/MT.avn_CY.06/RD.20021206/PT.gri
>d_DF.gr1/fh.0015_tl.press_gr.onedeg)

Got it.

re: GRDDISP can plot the 1 deg AVN grids OK if it is allowed to draw
the MAP

>This is pretty much true.  When I do a GRDDISP RTNEW/GFS TIME=6 FHOUR=15
>PAR=WINDB LEV=10[M] LSIZE=10 UNIT=KTS PINT=6, I get the following result:
>http://www.srh.noaa.gov/smg/images/GFS06FHR15.GIF
>It looks "correct", although the winds in Canada and Russia look pretty
>strong for 10 meter winds?

This is the problem I told you about in my previous email.  The request
to the GRID server is correctly asking for the U wind component, but
not the V component.  Here are the comments I sent previously:

From address@hidden Wed Nov 27 08: 09:35 2002

Here is what I got for the 0Z run, 15 hour forecast from yesterday:

GRDLIST MYDATA/GRIDS.6010 TIME=0 FHOUR=15 PAR=WINDB LEV=10[M] NUM=ALL
Dataset position 6010   Directory Title=
PAR    LEVEL       DAY        TIME    SRC FHOUR     FDAY       FTIME  GRID  PRO
---- --------- ------------ -------- ---- ----- ------------ -------- ----- ----
U      10 M    26 NOV 02330 00:00:00  AVN    15 26 NOV 02330 15:00:00   293 MERC
V      10 MB   26 NOV 02330 00:00:00  AVN    15 26 NOV 02330 15:00:00   200 MERC
Number of grids listed = 2
GRDLIST - done

Notice how the 10 m U component was found, but the V component is for
10 mb.  This is probably where the problem lies.  GRDDISP may correctly
setup the search conditions for the first component, but not the
second.  This would then give us very strange winds indeed.

To test if that was, in fact, the problem, I did the following:

DSSERVE ADD G/G GRID 1 9999 TYPE=GRID "ALL LOCAL GRID FILES
Adding the group G as a local dataset

Group/Descriptor         Type  Format & Range     RT Comment
------------------------ ----- ------------------ -- --------------------
G/G                      GRID  GRID 1-9999           ALL LOCAL GRID FILES
DSSERVE: done
 
GRDCOPY MYDATA/GRIDS.6010 G/G.1 PAR=U LEV=10[M]
Total grids copied=1
GRDCOPY - done
 
GRDCOPY MYDATA/GRIDS.6010 G/G.1 PAR=V LEV=10[M]
Total grids copied=1
GRDCOPY - done

GRDLIST G/G.1 NUM=ALL
Dataset position 1      Directory Title=
PAR    LEVEL       DAY        TIME    SRC FHOUR     FDAY       FTIME  GRID  PRO
---- --------- ------------ -------- ---- ----- ------------ -------- ----- ----
U      10 M    26 NOV 02330 00:00:00  AVN    15 26 NOV 02330 15:00:00     1 MERC
V      10 M    26 NOV 02330 00:00:00  AVN    15 26 NOV 02330 15:00:00     2 MERC
Number of grids listed = 2
GRDLIST - done

GRDDISP G/G.1 PAR=WINDB LEV=10[M] NAV=C PINT=2
GRDDISP: Done with graphic frame 11

Sure enough, the plot matched what I expected for near surface level winds.
So, I would venture to say that the problem is the mis-selection of the
V grid component when sepecifying a particular level by the GRD* programs.

re: GRDDISP for the 1 deg AVN grids can not overlay on top of most user
selected maps.  It does a better job on top of satellite imagery, but
these are not foolproof either.

>This is true.  When I do a EG;MAP WORL;GRDDISP RTNEW/GFS TIME=6 FHOUR=15
>PAR=WINDB LEV=10[M] LSIZE=10 UNIT=KTS PINT=6 NAV=C, I get the following
>result:
>http://www.srh.noaa.gov/smg/images/GFS06WORL.GIF
>Wind barbs only plot along International Date Line for some reason?

This is the bug I am talking about.  The comment in my email yesterday
was in regards to just this:

>> The question of
>> what is wrong boils down to the McIDAS notion of the Longitude extent
>> possibilities for grids.  The last thing I sent you was a suggestion to
>> set the UL and LR Lat,Lon points for grids 2, 3, and 4 so that the
>> lower right point is at -360.  This may fly in the face of preconceived
>> notions in McIDAS for possible grid Lat,Lon extents.  I will have to
>> touch base with Dave Santek on this one.  The one thing that I really
>> don't want to do is have to reformat the grid so that its Lat,Lon
>> extents lie between 90,180 and -90,-180.  This would be a lot of work
>> for the grib decoder especially if it is to be used in XCD.  This may,
>> however, be the "real" solution to the problems we are seeing with
>> gribdec.k.
>
>Why is this more work for the decoder?

The decoder would need to move the grid rows and columns that extend
past the dateline eastward to the other side of the grid.  Here is
my feeble attempt to show what I mean (hopefully, your email reader
uses a fixed width font)

  Grid extents as currently defined in gbtbpds001.bv1:

          (90,0)                (90,180)
             +----------+----------+----------+----------+
             |                      #####################|
             |                      #####################|
             |                      #####################|
             |                      #####################|
             |                      #####################|
             |                      #####################|
             |                      #####################|
             |                      #####################|
             +----------+----------+----------+----------+
                                                   (-90,-360)


What they may need to look like:

          (90,180)              (90,0)
             +----------+----------+----------+----------+
             |#####################                      |
             |#####################                      |
             |#####################                      |
             |#####################                      |
             |#####################                      |
             |#####################                      |
             |#####################                      |
             |#####################                      |
             +----------+----------+----------+----------+
                                                   (-90,-180)

In order to get the second grid, the points indicated with the '#' marks
would need to be moved in the grid.  This is not a huge job, but it is
additional work that the decoder would have to do.  Also, since the
Lat,Lon extents are defined in gbtbpds001.bv1, there would have to
be hard coded exceptions in the decoding routines that recognized that
when the Lat,Lon grid extents are specified in ways that McIDAS may
not "like", the grid will need to be reassembled.  This kind of stuff
is brittle to say the least.

re: call to Dave Santek.

>Cool, let me and Brice know what he says.

I will as soon as I hear anything.

Tom