[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: differences between GFS 703 and GFS 003 files
- Subject: Re: differences between GFS 703 and GFS 003 files
- Date: Wed, 28 Nov 2007 15:56:56 -0700
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