Re: differences between GFS 703 and GFS 003 files

David,

I sent a message to gembud a while back in response to Patrick Francis'
observation of the 2 fewer decoded grids:

http://www.unidata.ucar.edu/mailing_lists/archives/gembud/2007-October/000613.html

The problem was that in using meters as the integer number rather than
centimeters when decoding the grib2 data, the precision was causing 2
grids to have the same  rounded level values as others. The solution
here is to change the scaling of coordinate 106:106 to "2" so that the
DPTH layer is in centimeters:

106 106 Layer btwn 2 dpths below lnd sfc  m                    DPTH
2

Since GRIB2 specifies 2 coordinates, rather than a single coordinate,
this
was an entry that I originally created from documentation before the
practical
use exhibited the problem, as it was not a direct table copy from
version 1 to version 2.

That fixes one of the differences you describe for the DPTH units.
The other coordinate differences and parameter names are based on table
entries for the specified values which have been compiled both from the
old tables
as well as from the posted GRIB2 documentation, so we can reconcile
those to 
minimize the differences. Thanks for providing the comparison.

The other general problem that would occur if the 703 number is used is
that the gribkey.tbl file has a maximum number of 10,000 grids as the
default for the GFS
entries, and I have 19,904 in today's decoded, so we definitely want to
avoid the
703/003 conflict. I did the search on the nav table last in first out,
so found
the 703 entry for the name before 003 which was inadventent since I
didn't expect there to be multiple matches for the navigation
information.

As always, your insights are most helpful!

Steve



On Wed, 2007-11-28 at 14:24 -0800, David Ovens wrote:
> Steve,
> 
> I assume the GRIB1 1-degree GFS files (gfs003) will not be returning
> to CONDUIT and that we should make the transition to the GRIB2 version
> (gfs703).
> 
> I went ahead and ran gdinfo on the 2007112706_gfs003.gem and
> 2007112706_gfs703.gem files we got on the last day when the GRIB1 and
> GRIB2 data came in on the CONDUIT feed.  I then wrote a perl script to
> compare the fields in the files and found a few differences which are
> summarized for hour 0 below.  Almost all of the differences I think
> must be due to discrepancies between the $GEMTBL/grid/ files that are
> used for GRIB1 and GRIB2 files.  Do you agree?
> 
> Are the files used by dcgrib2 for GRIB2 decoding named g2v*tbl?
> Are the files used by dcgrib2 for GRIB1 decoding named vcr*tbl?
> 
> Here are the differences for hour 0 on the 2007112706 GFS 1-degree
> data (all of the fields for which the LEVEL1 LEVEL2 VCORD PARM do not
> match between the 2 files).  Note, there are 22 fields listed for
> gfs703 and 24 for gfs003, so there are 2 fewer fields, for some reason
> other than level and coordinate mismatch, in the gfs703 file:
> 
> gfs003   071127/0600F000    0    0 CCLY     TCLD
> gfs003   071127/0600F000    0    0 EATM     CWTR
> gfs003   071127/0600F000    0    0 EATM     PWTR
> gfs003   071127/0600F000    0    0 EATM     RELH
> gfs003   071127/0600F000    0    0 EATM     TOZO
> gfs003   071127/0600F000    0   10 DPTH     SOIM
> gfs003   071127/0600F000    0   10 DPTH     TMPK
> gfs003   071127/0600F000    2    0 HAGL     RELH
> gfs003   071127/0600F000    2    0 HAGL     SPFH
> gfs003   071127/0600F000    2    0 HAGL     TMPK
> gfs003   071127/0600F000   10    0 HAGL     UREL
> gfs003   071127/0600F000   10    0 HAGL     VREL
> gfs003   071127/0600F000   10   40 DPTH     SOIM
> gfs003   071127/0600F000   10   40 DPTH     TMPK
> gfs003   071127/0600F000   40  100 DPTH     SOIM
> gfs003   071127/0600F000   40  100 DPTH     TMPK
> gfs003   071127/0600F000  100  200 DPTH     SOIM
> gfs003   071127/0600F000  100  200 DPTH     TMPK
> gfs003   071127/0600F000 2000    0 POTV     HGHT
> gfs003   071127/0600F000 2000    0 POTV     PRES
> gfs003   071127/0600F000 2000    0 POTV     TMPK
> gfs003   071127/0600F000 2000    0 POTV     UREL
> gfs003   071127/0600F000 2000    0 POTV     VREL
> gfs003   071127/0600F000 2000    0 POTV     VWSH
> gfs703   071127/0600F000    0    0 CCLY      CLD
> gfs703   071127/0600F000    0    0 DPTH     SOIM
> gfs703   071127/0600F000    0    0 DPTH     TMPK
> gfs703   071127/0600F000    0    0 NONE     CWTR
> gfs703   071127/0600F000    0    0 NONE     PWTR
> gfs703   071127/0600F000    0    0 NONE     RELH
> gfs703   071127/0600F000    0    0 NONE     TOZO
> gfs703   071127/0600F000    0    1 DPTH     SOIM
> gfs703   071127/0600F000    0    1 DPTH     TMPK
> gfs703   071127/0600F000    1    2 DPTH     SOIM
> gfs703   071127/0600F000    1    2 DPTH     TMPK
> gfs703   071127/0600F000    2    0 HGHT     RELH
> gfs703   071127/0600F000    2    0 HGHT     SPFH
> gfs703   071127/0600F000    2    0 HGHT     TMPK
> gfs703   071127/0600F000    2    0 POTV     HGHT
> gfs703   071127/0600F000    2    0 POTV     PRES
> gfs703   071127/0600F000    2    0 POTV     TMPK
> gfs703   071127/0600F000    2    0 POTV     UREL
> gfs703   071127/0600F000    2    0 POTV     VREL
> gfs703   071127/0600F000    2    0 POTV     VWSH
> gfs703   071127/0600F000   10    0 HGHT     UREL
> gfs703   071127/0600F000   10    0 HGHT     VREL
> 
> 
> -- 
> David Ovens            e-mail: address@hidden
> Research Meteorologist    phone: (206) 685-8108
> Dept of Atm. Sciences      plan: Real-time MM5 forecasting for the
> Box 351640                        Pacific Northwest
> University of Washington          http://www.atmos.washington.edu/mm5rt
> Seattle, WA  98195               Weather Graphics and Loops
>                                   http://www.atmos.washington.edu/~ovens/loops
> 
> 
> ----- Forwarded message from Steve Chiswell <address@hidden> -----
> 
> X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on
>       uni1.unidata.ucar.edu
> X-Spam-Level: 
> X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00
>       autolearn=unavailable version=3.2.3
> Keywords: 200711281825.lASIPeAh150674
> From: Steve Chiswell <address@hidden>
> To: address@hidden
> Organization: Unidata
> Cc: address@hidden,
>       GEMPAK support <address@hidden>
> Subject: [gembud] Modification to grdnav.tbl for dcgrib2
> 
> 
> GEMPAK users,
> 
> There is an extra entry in the $GEMTBL/grid/grdnav.tbl for grid number
> 703, which is identical in navigation to grid number 3 at the top of the
> file. When using dcgrib2
> in GEMPAK 5.10.4 to automatically name the GFS grib2 file using the grid
> number template, the 703 grid number may be used. To avoid this, comment
> out  the line (eg insert a "!" at the beginning of the line 10 up from
> the bottom) in grdnav.tbl that  starts with: GG01 703.
> 
> Steve Chiswell
> Unidata User Support
> 
> 
> 
-- 
Steve Chiswell <address@hidden>
Unidata