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

[GEMPAK #RJD-210253]: Radar to GRIB

There are actually two easy solutions.  The first is to edit 
$GEMTBL/config/datatype.tbl to point to where the LDM is writing the NIDS 
files.  The second is to edit the LDM pattern action to decode / file the 
incoming data to where NEXRIII is defined in datatype.tbl.   Either solution 
will work, you just want these paths to be the same.

About your /data/ldm/nids/YYYYMMDD/%SITE%_YYYYMMDD.nids files, I'd have to see 
your pqact.conf entry for NIDS.  

The pattern action I use and suggest others use is:

# Use this action to file everything
NEXRAD  ^SDUS[2357]. .... ([0-3][0-9])([0-2][0-9])([0-6][0-9]).*/p(...)(...)
        FILE    -overwrite      -close  
data/gempak/nexrad/NIDS/\5/\4/\4_(\1:yyyy)(\1:mm)\1_\2\3

This way the products are files by Station ID (\5), then Product (\4), then the 
file name is written with product (\4) and year/month/day, resulting in files 
structured accordingly:

cd $RAD
du | grep FTG
4.5M    ./NIDS/FTG/DHR
836K ./NIDS/FTG/DPA
1.5M    ./NIDS/FTG/DSP
3.5M    ./NIDS/FTG/DVL
1.8M    ./NIDS/FTG/EET
4.7M    ./NIDS/FTG/N0Q
2.2M    ./NIDS/FTG/N0R
2.6M    ./NIDS/FTG/N0S
 12M    ./NIDS/FTG/N0U
2.6M    ./NIDS/FTG/N0V
1.6M    ./NIDS/FTG/N0Z
1.1M    ./NIDS/FTG/N1P
3.9M    ./NIDS/FTG/N1Q
2.1M    ./NIDS/FTG/N1S
8.9M    ./NIDS/FTG/N1U
3.1M    ./NIDS/FTG/N2Q
1.8M    ./NIDS/FTG/N2S
...
so on an so forth.

Michael






> Michael,
> 
> It appears that my problem wasn't with the conversion to grib, but with
> the creation of the gempak grid file in the first place.  Our system
> isn't set up in a way that has the NIDS files where the datatype.tbl
> file says the NEXRIII should be.  The person who handles our ldm feed
> doesn't think this is easy to remedy, so I'm looking for other options.
> That leads us to a few more questions...
> 
> First, is there any easy work-around to make gdradr point to where NIDS
> files currently reside on our system?  Currently, there are nids files
> located in a directory structure like
> /data/ldm/nids/YYYYMMDD/%SITE%_YYYYMMDD.nids.  Honestly, I don't know
> what is in these files.  They are, however, constantly updating.
> 
> Second, if option 1 isn't possible, is there a way to convert the
> NEXRCOMP image files to n0r grid files?  I played around with IMG2GD
> briefly (which I understand is meant for satellite imagery), but once
> the grid file was "created," it didn't contain any n0r data.
> 
> Thanks again for the help.
> 
> - Jeff
> 
> 
> On 8/18/2011 12:33 PM, Unidata GEMPAK Support wrote:
> > Jeff,
> >
> > I have a process that hopefully works for you.
> >
> > beginning with the n0r grid in a file called radr.gem
> >
> > gdgrib2
> >
> >   GDFILE   = radr.gem
> >   GBFILE   = radr.grb
> >   GFUNC    = n0r
> >   GDATTIM  = last
> >   GLEVEL   = 0
> >   GVCORD   = none
> >   PROJ     = mer
> >   GRDAREA  = us
> >   KXKY     = 720;500
> >   CPYFIL   =
> >   G2TBLS   =
> >   G2IS     =
> >   G2IDS    =
> >   G2PDT    =
> >   G2DRT    =
> >   WMOHDR   = NCAR
> > GEMPAK-GDGRIB2>r
> >
> > this will produce a grib2 file radr.grb
> >
> > checking with wgrib2:
> >
> > 1:0:16Z17aug2011:BREF Base Reflectivity [dB]:lvl1=(1,0) lvl2=(1,-1):surface 
> > - surface:anl:
> >
> > and decoding back to a gempak grid with dcgrib2:
> >
> > dcgrib2 radr2.gem<  radr.grb
> >   Opening WMO Originating Center Table wmocenter.tbl...
> >   Opening WMO GRIB2 Parameter Table g2varswmo2.tbl...
> >   Opening WMO GRIB2 Vertical Coordinate Table g2vcrdwmo2.tbl...
> >
> >
> > gdinfo on this new radr2.gem file shows:
> >
> >   GDFILE   = radr2.gem
> >   LSTALL   = YES OUTPUT   = T
> >   GDATTIM  = last
> >   GLEVEL   = 0
> >   GVCORD   = none
> >   GFUNC    = n0r
> >   GEMPAK-GDINFO>r
> >
> >   GRID FILE: radr2.gem
> >
> >   GRID NAVIGATION:
> >       PROJECTION:          MER
> >       ANGLES:                 0.0     0.0     0.0
> >       GRID SIZE:          720 500
> >       LL CORNER:              19.00   -119.00
> >       UR CORNER:              47.00    -56.00
> >
> >   GRID ANALYSIS BLOCK:
> >        UNKNOWN ANALYSIS TYPE
> >
> >   Number of grids in file:     1
> >
> >   Maximum number of grids in file:   5000
> >
> >    NUM       TIME1              TIME2           LEVL1 LEVL2  VCORD PARM
> >      1     110817/1659F000                          0         NONE N0R
> >
> >
> > This seems to work for me, hopefully for you as well.
> >
> > Let me know if anything looks off.
> >
> >
> > Michael James
> > Unidata
> >
> >
> >
> >
> >> Hi Michael,
> >>
> >> That sounds great.  Thanks for taking the time to respond while you're
> >> traveling.  If I find any information about the bug that allows me to
> >> fix it before you get back, I will let you know.
> >>
> >> Safe travels,
> >> - Jeff
> >>
> >>
> >> On 7/27/2011 2:44 PM, Unidata GEMPAK Support wrote:
> >>> Hi Jeff,
> >>>
> >>> I believe this is an old gdradr bug.  I'm traveling overseas at the 
> >>> moment so can't look into this but i'll see if i can get a fix for you 
> >>> when i'm about in a couple of weeks.  With the fix it will be easy to 
> >>> convert from gem grid to grib.
> >>>
> >>> Best,
> >>>
> >>> Michael James
> >>> Unidata
> >>>
> >>>
> >>>
> >>>> Full Name: Jeff Zielonka
> >>>> Email Address: address@hidden
> >>>> Organization: Penn State
> >>>> Package Version:
> >>>> Operating System:
> >>>> Hardware:
> >>>> Description of problem: Hi,
> >>>>
> >>>> I'm attempting to create GRIB files from national radar mosaic files.  
> >>>> My first step was to use gdradr as documented here 
> >>>> http://www.unidata.ucar.edu/software/gempak/examples/gdradr/ to make the 
> >>>> national mosaic .gem file.
> >>>>
> >>>> Is it then possible to use gdgrib to create a GRIB file of the 
> >>>> reflectivity fields from that .gem file?  I have attempted to do so, but 
> >>>> the result is a grib file with a constant field filled with missing 
> >>>> values.
> >>>>
> >>>> Any help and guidance would be much appreciated.  Thanks.
> >>>>
> >>>> - Jeff Z.
> >>>>
> >>>>
> >>> Ticket Details
> >>> ===================
> >>> Ticket ID: RJD-210253
> >>> Department: Support GEMPAK
> >>> Priority: Normal
> >>> Status: Open
> >>>
> >>
> >
> > Ticket Details
> > ===================
> > Ticket ID: RJD-210253
> > Department: Support GEMPAK
> > Priority: Normal
> > Status: Open
> >
> 
> 


Ticket Details
===================
Ticket ID: RJD-210253
Department: Support GEMPAK
Priority: Normal
Status: Open