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.
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