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

20000310: GRIB identifiers

Alan,

Yes, you can store the raw feed and decode it later. In fact,
you can just "cat" the data to the decoders later- 
eg: cat gribfil | dcgrib .....

Grib files do not have a pil line. The way they can be identified is
by using the PDS block with Octets 5 (model center) and 6 (process id)
which is what our pqing uses to create the /mMODEL id tag to
add to the WMOid in the LDM product ID (note, this is only 
used in the LDM id, we don't change the WMO header in the data!!!).

If the NWS would start using the assigned "KWBG" for he RUC, then
most of your problems would be solved. Ideally, you can identify
the data from the LDM rather than wait until it gets to
the decoder, since if you archive the data in its raw form- then you don't
have the benefit of passing it to the decoder. Maybe FSL would be willing to
add the model number from the GRIB PDS to their identifiers. Since they already 
have
the product ready to stick in the LDM, adding one more little access of the
PDS octets for producing the product names is very easy. In fact, for
my NOAAport system here, I actually insert the products named like:

grib/ncep/ETA_89/#211/200003090000/F024/TMP/120-90 mb above gnd/ YTQE86 KWBE 
090000

where the model center, process, grid, initial time, forecast time, parameter
and level are all used to create a more readable name with the WMO id.

Steve Chiswell
Unidata User Support



>From: address@hidden
>Organization: .
>Keywords: 200003101529.IAA07168

>
>
>Once again you have pointed me in the right direction.  It looks as though
>there is enough uniqueness with only a couple of exceptions.  One problem
>is the RUC and AVN pattern of '[YZ].Q.*'.  Since they both get xmitted
>under KWBC, these will get decoded under both.  Do each have the awips
>header on of RUC or AVN on the seond line?  If this is the case, I can look
>for a more unique pattern.
>
>Another question that comes to mind is decoding at a later date.  Can we
>save the raw NOAAPort files and run thru the decoders at a later date as
>needed?  I don't see why not, but I just want to make sure there aren't any
>hidden problems.
>
>Alan.
>
>
>
>
>
>Unidata Support <address@hidden> on 03/09/2000 05:16:57 PM
>                                                              
>                                                              
>                                                              
> To:      Alan Hall/NCDC                                      
>                                                              
> cc:      Unidata Support <address@hidden>   
>                                                              
>                                                              
>                                                              
> Subject: 20000307: GEMPAK Download                           
>                                                              
>
>
>
>
>
>
>
>
>>From: address@hidden
>>Organization: .
>>Keywords: 200003091948.MAA23745
>
>>
>>
>>Got a clean nawips make!!!  Thanks for your help!
>>
>>I have spent that last two hours trying to figure out my pqact.conf file
>>configurations.  Because we use the acqserver supplied by FSL, our ldm
>>product queue entries differ quite a bit.  My entries look like:
>>
>>NOAAPORT.NWSTG.GRID.YVQI37.KWBE.091910.0003678889.2000069193532844
>>
>>As an example, I need to match your pattern of ^[YZ].[Q].*/mETA to decode
>>the ETA grids.  I don't have the /mETA option, so how can I pick out the
>>ETA's?
>>
>>One possibility is (so I'm told) the callsign is different for the
>>different grids, but I can't seem to verify that  in any documentation
>>anywhere.  If this is true, do you have any documentation or can you point
>>me to any documentation?
>>
>>Another possibility would be to re-insert the product into the queue using
>>the same method you use (pqing I think) and that would get the /mETA where
>>I need it.  If I have to go with this option, can someone help me to get
>>this implemented?
>>
>>Thanks in advance,
>>Alan.
>>
>>
>>
>
>
>Alan,
>At one time, all grid data on FOS came out as KWBC which wasn't unique,
>so we had to generate the /m tags- so we just matched on KWB.
>
>The GRIB documentation Table A.5 shows what is supposed to be used.
>ftp://ftp.ncep.noaa.gov/pub/nws/nmc/docs/gribed1/sect5.pdf
>
>Page A.1 referenced header bytes 8-11, and the last letter is shown in
>Table A.5.
>
>For ETA, D is early Eta, and E is Meso. I verified from our NOAAport feed
>that
>all the ETA data is using KWBD or KWBE.
>
>The RUC is supposed to be KWBG...but still appears under KWBC along with
>NOW, SST
>and AVN/SSI.
>
>NGM comes in under KWBF as advertized.
>
>At least for the ETA, you can match your FSL feed using the pattern:
>^NOAAPORT\.NWSTG\.GRID\.[YZ].[Q]...\.KWB[DE]
>and NGM with
>^NOAAPORT\.NWSTG\.GRID\.[YZ].[Q]...\.KWBF
>
>
>
>There are 2 features I included in dcgrib which are the addition of the
>file
>templates @@@ and ### to the standard YYYY MM DD HH so that you can pipe
>grid data to dcgrib with the output file named like
>YYYYMMDDHH_model###_grid@@@.gem
>
>The templates are replaced with appropriate values as determined by each
>grib,
>and ### is the model number (eg 085 or 089 for the ETA...but supposed to
>move to
>084 this year; 039 for NGM, etc) and @@@ is replaced by the grid number (eg
>211 for Q).
>So, at least if you can't get a completely unique pattern for all your
>different
>model needs, you can still generate unique file names.
>
>Here I just pipe all the ETA grids to the decoder with @@@ and get
>211, 207, 216, 212 and 215 grids separated out into separate files.
>
>The downside to using ### is that the AVN and MRF grids use 2 different
>process
>numbers (one for the SSI and the other for the forecast fields so 77, 78,
>80, 81, 82 etc)-
>go figure. The AVN and MRF are supposed to be renumbered to 96 and 94 this
>year...
>but I don't know if they will still use a different number of the SSI.
>The numbers for AVN and MRF are supposed to differentiate T62, T126, T170
>etc.,
>but NCEP doesn't do that. When they went from T126 to T170 then back to
>T126
>etc the numbers stayed the same.
>
>Steve Chiswell
>***************************************************************************
>Unidata User Support                                    UCAR Unidata
>(303)497-8644                                                  P.O. Box
>address@hidden                                   Boulder, CO
>---------------------------------------------------------------------------
>Unidata WWW Service                        http://www.unidata.ucar.edu/
><
>***************************************************************************
>
>
>