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

20050805: gempak gfs > 84h has C001 attached to field names

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: 20050805: gempak gfs > 84h has C001 attached to field names
  • Date: 05 Aug 2005 15:49:05 -0600
Art,

I'm going to redo the ensemble files in gribkey.tbl for the next release
as the new capability to do ENS_ calculations within the GEMPAK grid
programs would be easier with each member set in a separate file and
using the "*" template in the field, and use the PDS_EXT FLAg such as
NAGRIB does.

I've made the defaults patterns to split up the decoding into separate
models in the pqact examples under $NAWIPS/ldm/etc/templates to enable
sites to pick and choose which they want, rather than use a single
dcgrib2 process for all grib data, which can be taxing for a single
process for lest robust hardware.

The entries as I have them can be generated by running
$NAWIPS/ldm/etc/gen_pqact.csh

Steve Chiswell
Unidata User Support


On Fri, 2005-08-05 at 15:21, Arthur A. Person wrote:
> Steve,
> 
> On Fri, 5 Aug 2005, Steve Chiswell wrote:
> 
> > Art,
> >
> > That would mean that the fields have the ensemble bits identifying the
> > grids from the control c001 run.
> >
> > It appears that the onedeg gfs fields were only posted through 84 hours
> > for the 12Z rather than through 180 as is normal.
> >
> > The patterns I am using are:
> >
> >
> > CONDUIT ST.opnl/MT.gfs
> >        PIPE    decoders/dcgrib2 -d
> > data/gempak/logs/dcgrib2_CONDUITgfs.log
> >        -e GEMTBL=/home/gempak/NAWIPS/gempak/tables
> >
> > and
> >
> > CONDUIT MT.ensg
> >        PIPE    decoders/dcgrib2 -d
> > data/gempak/logs/dcgrib2_CONDUITens.log
> >        -e GEMTBL=/home/gempak/NAWIPS/gempak/tables
> >        data/gempak/model/ens/YYYYMMDDHHfFFF_ens@@@.gem
> >
> > Note that I file to hourly ensemble files, while using the gribkey.tbl
> > file for the MT.gfs file to handle the gfs.
> 
> Hmmm... looks like I may have a more complicated plumbing issue on my 
> hands than I thought.  I'm currently just feeding everything from CONDUIT 
> into the dcgrib2 decoder and letting it do the filing work... will that 
> not work anymore?  Is there anything that can be done in gribkey.tbl to 
> avoid the confusion?
> 
>                                      Art.
> 
> > Steve Chiswell
> > Unidata User Support
> >
> > On Fri, 2005-08-05 at 13:47, Arthur A. Person wrote:
> >> Hi...
> >>
> >> Starting with this morning's (Aug 05, 2005) 12Z GFS on the 003 grid, it
> >> appears that all field names have a "C001" attached to the name (e.g. HGHT
> >> becomes HGHTC001, etc...) for all hours after the 84 hour forecast.  Is
> >> anyone else seeing this?  Is it a bug, or a new "feature"?  It's making it
> >> difficult to get to the fields by their former names.
> >>
> >>                                      Art.
> >>
> >> Arthur A. Person
> >> Research Assistant, System Administrator
> >> Penn State Department of Meteorology
> >> email:  address@hidden, phone:  814-863-1563
> >
> >
> 
> Arthur A. Person
> Research Assistant, System Administrator
> Penn State Department of Meteorology
> email:  address@hidden, phone:  814-863-1563