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

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



Stonie,

I haven't tried decoding the grib1 and grid2 versions of ETA218 to
the same file, since I really wanted to do analysis of the
DVBS broadcast signal without complicating things with
those fields from the grid 218 on the existing NOAAport
(and/or the 218 grib2 from the NWS ftp server), but I have
mixed the sources for 212 for example - though that doesn't involve
Grib2 decoding.

The general problem of GRIB2 is that the grid number (eg 218) is
not provided in the data since the projection is defined by
provided coordinates. That makes a single dcgrib2 pipe
action difficult, and you can't have two instances of the decoder
writing at the same time.

Steve Chiswell



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

>Steve,
>
>Thanks for the feedback - main thing, if it's not bothering you, then it's my 
>problem, and I'll need to work on it.  This only happens in the files when I 
>mix the v.35 NOAAPort stream with the DVB-S stream - no idea why, if I filter 
>the Eta218 one way or another, then there is no problem with the resulting 
>dcgrib2 file.
>
>Stonie
>
>On Thursday 09 September 2004 19:11, Unidata Support wrote:
>> 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
>>
>> --
>> ***************************************************************************
>>* < 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.