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

Re: possible gvar issue

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: possible gvar issue
  • Date: Mon, 29 Oct 2007 12:42:49 -0600
Patrick,
I  hit send too fast on the last post before I finished:

On Mon, 2007-10-29 at 10:45 -0600, Steve Chiswell wrote:
> Patrick,
> 
> There are 2 duplicate fields in the GFS data set. The nagrib2 output
> will
> show the [GD -10] message about grid already exists in output file.
> The result is 329 fields are read, but only 327 are written to the
> output file.
> 
> The dgrib2 verbose logiing output shows these duplicate fields are:
> SOIM [071029/0600F012] 0:0 DPTH
> TMPK [071029/0600F012] 0:0 DPTH

This is caused by the rounding of the DPTH vertical coordinate to whole
meters such that 0 to .1m and .1 to .4 meters are both stored
as glevel 0:0.

The $GEMTBL/grid/g2vcrdwmo1.tbl vertical coordinate table provides:

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

To avoid the confusion from rounding, you may want to change this to
store
the levels as centimeters (eg bumping the SCALE column to "2" such as
:
106 106 Layer btwn 2 dpths below lnd sfc  m                    DPTH
2

By making that change you will have levels of 0:10 and 10:40 and
no duplicate levels being overwritten.

Steve Chiswell
Unidata User Support



> 
> Steve Chiswell
> Unidata User Support
> 
> 
> On Fri, 2007-10-26 at 16:24 -0400, patrick wrote:
> > gembuds,
> > 
> > it appears that when using nagrib2 or running the dcgrib2 
> > decoder from the command line to convert ncep grib2 
> > files to gempak format a variable or two may be missing 
> > in the gvars.
> > 
> > for example the following is the index of the ncep grib2 
> > file tested:
> > 
> > http://sandy.homelinux.com/files/gembuds/gfs.t12z.pgrb2f12.idx
> > 
> > below is the gdlist of the grid file created by nagrib2:
> > 
> > http://sandy.homelinux.com/files/gembuds/gfs_ncep_nagrib2.txt
> > 
> > and below is the gdoutf from the nagrib2 run:
> > 
> > http://sandy.homelinux.com/files/gembuds/nagrib2.out
> > 
> > the gdoutf does state:
> > "329 GRIB messages were read or scanned "
> > and
> > "327 grids were written to the GEMPAK file"
> > 
> > of immediate notice is that weasd seems to be missing in the grid
> > created by nagrib2, but what seems odd about that is that in:
> > 
> > /home/gempak/GEMPAK5.10.4/gempak/tables/grid/g2varswmo2.tbl
> > 
> > which is called when running dcgrib2 manually from
> > the commandline is that weasd is listed ~ line 120 or so.
> > 
> > perhaps some gouls are having a little pre halloween fun =)
> > 
> > cheers,
> > 
> > --patrick
> > 
> > 
-- 
Steve Chiswell <address@hidden>
Unidata