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

20040909: 20040816: 20040816: New one for me . . .



Stonie,

I break out the dcgrib2 entries because our PC can't keep up with the file
IO for a single dcgrib2 process. Also, I think you can cut the 18,000 max grids
way down if you use separate files, and that will save header space too.
That may be a hidden file system offset problem depending on your OS.

For GDFILE, I am using a template, eg ETA_GRIB2 rather than
a specific file name. I believe that accumulation values
other than the 3 hour which are in the data set explicitly would have to
have access to multiple files, and therefore the alias is the easiest
was to go about that. The P03M display I did of course did not require a
conversion as your P03I would. No Ideas on the TMPK though.

Steve Chiswell
Unidata User Support


>From: Stonie Cooper <address@hidden>
>Organization: Planetary Data, Incorporated
>Keywords: 200409091324.i89DOpnJ017391

>Steve,
>
>I divided up the incoming Eta 218 into valid time hour files.  If I do a 
>gdinfo on one of the out files:
>
> GEMPAK-GDINFO>l
> GDFILE   = $MODEL/2004090906f084_eta218.gem
> LSTALL   = YES
> OUTPUT   = T
> GDATTIM  = all
> GLEVEL   = all
> GVCORD   = all
> GFUNC    = all
>
>I get:
>
> GEMPAK-GDINFO>r
>
> GRID FILE: $MODEL/2004090906f084_eta218.gem
>
> GRID NAVIGATION:
>     PROJECTION:          LCC
>     ANGLES:                25.0   -95.0    25.0
>     GRID SIZE:          614 428
>     LL CORNER:              12.19   -133.46
>     UR CORNER:              57.33    -49.42
>
> GRID ANALYSIS BLOCK:
>      UNKNOWN ANALYSIS TYPE
>
> Number of grids in file:    14
>
> Maximum number of grids in file:  18000
>
>  NUM       TIME1              TIME2           LEVL1 LEVL2  VCORD PARM
>    1     040909/0600F084                       3000  0      HGHT HLCY
>    2     040909/0600F084                         10         HGHT UREL
>    3     040909/0600F084                         10         HGHT VREL
>    4     040909/0600F084                          2         HGHT TMPK
>    5     040909/0600F084                          2         HGHT RELH
>    6     040909/0600F084                          0         NONE EMSL
>    7     040909/0600F084                          0         NONE PRES
>    8     040909/0600F084                          0         NONE CINS
>    9     040909/0600F084                          0         NONE PMSL
>   10     040909/0600F084                          0         NONE CAPE
>   11     040909/0600F084                          0         NONE PWTR
>   12     040909/0600F084                          0         NONE C03M
>   13     040909/0600F084                          0         NONE P03M
>   14     040909/0600F084                        180  0      PDLY LFT4
>
>Everything looks lovely.  But, if I attempt to do anything with any of the 
>grids:
>
>gdmap
>GDATTIM  = F084
> GLEVEL   = 2
> GVCORD   = hght
> GFUNC    = tmpk
> GDFILE   = $MODEL/2004090906f084_eta218.gem
> GAREA    = us
> IJSKIP   =
> SATFIL   =
> RADFIL   =
> IMCBAR   =
> SKIP     = 0
> POSN     = 0
> COLORS   = 1
> MARKER   = 0
> MAP      = 1
> LATLON   =
> PANEL    = 0
> CINT     = 0
> TITLE    = 1
> SCALE    = 999
> DEVICE   = XW
> PROJ     = MER
> CLEAR    = YES
> TEXT     = 1
> GRDLBL   = 0
> LUTFIL   =
> STNPLT   =
>
>or
>
> GLEVEL   = 0
> GVCORD   = NONE
> GFUNC    = P03I
>
>I get:
>
> [DG -7]  Input grid TMPK ^040909/0600F084 @2 %HGHT cannot be found.
>
>or 
>
> [DG -7]  Input grid P03I ^040909/0600F084 @0 %NONE cannot be found.
>
>And this happens with gdlist, gdcntr, the NAWIPS guis, etc.
>
>One thing I noticed - I still have a single ldm entry for all grid:
>
>HDS     ^([HLMOXYZ]|US058|AACN).*
>        PIPE    decoders/dcgrib2 -d data/gempak/logs/dcgrib.log
>        -v 0
>        -e GEMTBL=/usr/local/nawips/gempak/tables
>
>And you have them all broken out in your new pqact.conf examples . . . would 
>this have anything to do with it?
>
>Stonie
>
>On Wednesday 08 September 2004 19:30, Unidata Support wrote:
>> Stonie,
>>
>> I do not have a problem with a precip loop through f084 ETA218 here.
>> I am storing the ETA 218 as individual forecast hour files, eg
>> using the fFFF naming. Gdinfo shows all the expected fields,
>> and the nmap2 restore functions as well as gdcntr/gdplot2
>> find the forecast fields at 3 hour intervals. I am decoding the
>> ETA218 from grib2 on dvbs for input.
>>
>> If you are finding missing frames in the plot, check the gdinfo
>> listing to verify that all the source grids needed exist.
>>
>> Steve Chiswell
>> Unidata User Support
>>
>> >From: Stonie Cooper <address@hidden>
>> >Organization: Planetary Data, Incorporated
>> >Keywords: 200408162219.i7GMJ2aW009111
>> >
>> >Steve,
>> >
>> >If I put a file up on a server for you to access . . . would that be
>> > desirable
>> >
>> >for you to look at?  I compressed, via bzip2, this mornings run . . . it's
>> > at 84MB.
>> >
>> >Stonie
>> >
>> >On Monday 16 August 2004 22:10, Unidata Support wrote:
>> >> Nope. The grib2 data currently is being stored using grib1 packing.
>> >>
>> >> Steve Chiswell
>> >>
>> >> >From: Stonie Cooper <address@hidden>
>> >> >Organization: Planetary Data, Incorporated
>> >> >Keywords: 200408161901.i7GJ1paW018289
>> >> >
>> >> >Steve,
>> >> >
>> >> >Before I get too far with this . . . I realized my decoding machine is
>> >> > running
>> >> >
>> >> >the latest GEMPAK, but my display box is on 5.6.m.  If the GRIB2
>> >> > messages are decoded, does the gd* programs also need to be GRIB2
>> >> > aware?
>> >> >
>> >> >Stonie
>> >> >
>> >> >On Friday 13 August 2004 22:50, Steve Chiswell wrote:
>> >> >> Stonie,
>> >> >>
>> >> >> It looks like something is missing.
>> >> >> Are you tracking and missing packets on the DVB-S?
>> >> >>
>> >> >> I'd have to see your GDLIST poutput to know if the grids
>> >> >> exist in your file.
>> >> >>
>> >> >> Steve
>> >> >>
>> >> >> On Fri, 2004-08-13 at 16:45, Stonie Cooper wrote:
>> >> >> > Steve,
>> >> >> >
>> >> >> > Ingesting all the new DVB-S data - from both streams - along with
>> >> >> > other NOAAPort data, and seeing something new when I attempt to
>> >> >> > display Eta218 data (See attached).
>> >> >> >
>> >> >> > Any ideas?
>> >> >
>> >> >--
>> >> >Stonie R. Cooper
>> >> >Planetary Data, Incorporated
>> >> >(402) 727-6599
>> >>
>> >> --
>> >> ************************************************************************
>> >>*** * < Unidata User Support                                    UCAR
>> >> Unidata Program < (303)497-8643
>> >> P.O. Box 3000 < address@hidden
>> >> ------------------------------------------------------------------------
>> >>--- - < Unidata WWW Service
>> >> ------------------------------------------------------------------------
>> >>--- - < NOTE: All email exchanges with Unidata User Support are recorded
>> >> in the Unidata inquiry tracking system and then made publically
>> >> available through the web.  If you do not want to have your interactions
>> >> made available in this way, you must let us know in each email you send
>> >> to us.
>> >
>> >--
>> >Stonie R. Cooper
>> >Planetary Data, Incorporated
>> >(402) 727-6599
>>
>> --
>> ***************************************************************************
>>* < Unidata User Support                                    UCAR Unidata
>> Program < (303)497-8643                                                 
>> P.O. Box 3000 < address@hidden                                  
>> ---------------------------------------------------------------------------
>>- < Unidata WWW Service             
>> ---------------------------------------------------------------------------
>>- < NOTE: All email exchanges with Unidata User Support are recorded in the
>> Unidata inquiry tracking system and then made publicly available
>> through the web.  If you do not want to have your interactions made
>> available in this way, you must let us know in each email you send to us.
>
>-- 
>Stonie R. Cooper
>Planetary Data, Incorporated
>(402) 727-6599
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.