NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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:
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.
gembud archives: