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