This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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