[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GEMPAK #YNA-805788]: Ensemble data lost



> Steve,
> 

> > If you had error lines in your dcgrib2 log file about parameter numbers not 
> > being found,
> > then the data was arriving, but table updates are needed.
> 
> I see errors like:
> 
> [16531] 060928/1342[DECODE_GRIB2 -34] Could not determine parameter name 0 2 
> 3 1 [-1073766896]
> [10239] 060928/1342[GB 1]
> 
> Is this what you are referring to?


Yes. That 4 number, eg "1" or "11" requires a separate parameter entry in the
GRIB tables aven though "0 2 3 0" already exists.


> 
> > If you didn't see "prod/gefs"
> > strings, then check your pattern.
> >
> > For dcgrib2, the pattern above will create separate files for each 
> > perturbation.
> > In datatype.tbl, I have:
> > ! NCEP Global ensemble members
> > GEFS         $MODEL/ens                gep*_YYYYMMDDHHfFFF.gem        ... 
> > etc....
> >
> > ! NCEP Global ensemble control runs
> > GEFC         $MODEL/ens                gec*_YYYYMMDDHHfFFF.gem        ... 
> > etc....
> 
> Is there any way to have dcgrib2 decode/file the data as was done
> previously, all perturbations in one file per forecast time?  We need some
> spin-up time to transition to the new scheme.  I think the new scheme
> probably breaks all our scripts that deal with ensemble data.

I can add that to dcgrib2. The nagrib2 decoder (which has the common GEMPAK 
library decoding routines)
has the C001, P001, etc extensions turned off, so I need to add a flag to 
dcgrib2 to ad dthose
extensions back to save in a single file. The downside is that those new ens_ 
functions that ncep
is developing won't work, but to maintain compatibility you probably weren't 
using them anyway.
I'll post an update to dcgrib2 tomorrow.

In the larger view, trying to store all 51 members of the ecmwf tigge ensemble 
into a single file
will too large, so a single file solution won't work for everything.

Steve Chiswell
Unidata User Support

> 
> Thanks.
> 
> Art
> 
> > Using those patterns, you can use the ENS_ functions in GEMPAK like:
> >
> > GDFILE = {GEFS}
> > GVCORD = NONE
> > GLEVEL = 0
> > GDPFUN = ens_savg(pmsl) ! ens_ssprd(pmsl)
> >
> > or another example:
> > GDPFUN = ens_prob(AND(GT(p06i,.01),LT(tmpc@2%hght,0)))
> >
> > The {} in GDFILE allows the grid library to open each of the member files 
> > that match the "*" in
> > the template. You can plot the individual members line:
> >
> > GDFILE = GEFS:01 ! GEFS:02 !....! GEFS:10
> > GDPFUN = pmsl
> > TYPE = c
> > LINE = 30/1/1 ! 29/1/1 !.....! 21/1/1
> > CINT = 4
> >
> > I'm currently working on adding some standard restore files for 
> > NMAP2/GDPLOT2
> > for the 5.9.4 release if you need some other examples.
> >
> > Steve Chiswell
> > Unidata User Support
> >
> >
> >> Hi...
> >>
> >> Seems as though we either configured something wrong for the ensemble
> >> header change or else the ensemble data didn't arrive today as nothing got
> >> decoded this morning.  Do you know if the data was sent, and if so, what
> >> changes or what pqact line do I need to make it get decoded in dcgrib2?
> >>
> >> Thanks.
> >>
> >> Art
> >>
> >> Arthur A. Person
> >> Research Assistant, System Administrator
> >> Penn State Department of Meteorology
> >> email:  address@hidden, phone:  814-863-1563
> >>
> >>
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: YNA-805788
> > Department: Support GEMPAK
> > Priority: Normal
> > Status: Closed
> 
> Arthur A. Person
> Research Assistant, System Administrator
> Penn State Department of Meteorology
> email:  address@hidden, phone:  814-863-1563
> 
> 


Ticket Details
===================
Ticket ID: YNA-805788
Department: Support GEMPAK
Priority: Normal
Status: Closed