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.
Brent, I'll download a file and take a look. The GB error is from the GEMPAK routine that is likely creating the parameter name from the parameter number and time information. It could either be that the etc/ table just needs to be updated, or the GEMPAK routine needs a tweak. The code is in GEMPAK for ensemble, so it is probably something minor.....I'll determine and let you and Paula know. Thanks, Steve On Mon, 2006-09-11 at 13:05 -0400, Brent A. Gordon wrote: > Steve, > > I gave this a shot just now, but I am getting some errors from > gribinsert. Here is stdout/stderr: > > ssh ldm2 -l ldm > ncep_bin/gribinsert.sh > /mnt/disk2/data/nccf/com/gens/prod/gefs.20060911/12/pgrb2a/gep09.t12z.pgrb2af54 > NMC2 > gribinsert NOTE: open and memorymap > data/nccf/com/gens/prod/gefs.20060911/12/pgrb2a/gep09.t12z.pgrb2af54 > gribinsert NOTE: 1569407 bytes memory mapped > gribinsert ERROR: [GB 1] > gribinsert ERROR: [GB 1] > . > . > . > gribinsert ERROR: [GB 1] > gribinsert ERROR: [GB 1] > gribinsert NOTE: munmap > gribinsert NOTE: stats_size 4859 43 > + result= Opening WMO Originating Center Table wmocenter.tbl... > Opening WMO GRIB2 Parameter Table g2varswmo2.tbl... > Opening Local GRIB2 Parameter Table g2varsncep1.tbl... > + ret=0 > + echo Opening WMO Originating Center Table wmocenter.tbl... Opening > WMO GRIB2 Parameter Table g2varswmo2.tbl... Opening Local GRIB2 > Parameter Table g2varsncep1.tbl... > Opening WMO Originating Center Table wmocenter.tbl... Opening WMO > GRIB2 Parameter Table g2varswmo2.tbl... Opening Local GRIB2 Parameter > Table g2varsncep1.tbl... > > > Looks like gribinsert does not like GRIB2 ensemble data??? > > Brent > > Steve Chiswell wrote: > > Good morning Brent, > > Great timing as I'm back from Ocean City, MD this morning! > > > > Yes, go ahead and point the WOC ensembles to GRIB2 rather than GRIB1. > > > > All CONDUIT ensemble data is still being sent from the TGSV32 server. > > Once the WOC is inserting GRIB2, I will create a transition time > > schedule for the top level > > relays to switch their feeds of ensembles from tgsv32 to WOC. > > > > One note is that the NCAR TIGGE group has a direct feed to the WOC, so > > they > > will start getting those GRIB2 products immediately via that route > > (which is good I assume). > > > > Once we have the CONDUIT feed transitioned to the GRIB2, we can schedule > > a removal of the ensemble posting to tgsv32 (widdling our way off of > > tgsv32). > > > > Thanks, > > > > Steve > > > > > > On Mon, 2006-09-11 at 07:13 -0400, Brent A. Gordon wrote: > > > > > Hi Steve, > > > > > > We have the GRIB2 version of the ensemble data at the WOC now. I was > > > wondering if I could point CONDUIT to those data now instead of the > > > GRIB1 versions? Is anyone pulling the ensembles from the WOC system? > > > > > > Thanks, > > > > > > Brent > > > -- Steve Chiswell <address@hidden> Unidata