Brent, I downloaded the file you tried, and see that the ~ldm/etc/ tables for parameter names need to have the parameter names added for the type of generating process (code table 4.3 values 1 and 11). This is just the table that GEMPAK's library routines use to compose the parameter name based on discipline, category, type, generating process gribinsert does succeed in adding the data to the LDM queue without the table entries, but the GB -1 error means that the descriptive LDM product name has a blank. Gribinsert is happy enough with the GRIB2 ensemble data, otherwise. I also added the parameters per ECMWF's tigge list at: http://tigge.ecmwf.int/tigge/d/show_archive/table=parameters/ Attached is a tar file containing updates for the 4 tables in ~ldm/etc on your systems (g2varsncep0.tbl g2varsncep1.tbl g2varswmo1.tbl g2varswmo2.tbl) You can just place the tarfile in ~ldm/etc, and unpack there on ldm1.woc and ldm2.woc with: tar xvf diffs_1.tar This replaces those that were installed from the ~ldm/gribinsert-1.0/tables/ directory. I suspect there may be a parameter or 2 in the RUC that might be missing from the tables as well, so will watch for those. You should be OK in switching the ensembles over to GRIB2 for CONDUIT on WOC. 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
Attachment:
diffs_1.tar
Description: Binary data