[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GEMPAK #RJD-210253]: Radar to GRIB
- Subject: [GEMPAK #RJD-210253]: Radar to GRIB
- Date: Wed, 24 Aug 2011 13:28:03 -0600
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