Re: TIGGE data sets

Steve,

I updated these tables and have switched back to the GRIB2 ensemble data.  The 06Z data are going out now and so far everything looks good.

Thanks!

Brent

Steve Chiswell wrote:

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