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.
Robert, I looked at your image. And after looking at the GEMPAK image, it appeared that in the wind barbs there was a row shift, such that when looking at wind barbs for the entire GAREA=grid, there was a pronounced lower left to upper right pattern in the barbs. I tried comparing a file decoded with NAGRIB to dcgrib2 and found that nagrib didn't even write out the UREL and VREL fields to the file. Using the "-v 4" flag to dcgrib2, I found that while the navigation of the grids was the same for all the grids in the file, the UREL and VREL grids have a different number of grid points than the other grids. That is, all the other grids are 159x171, while the UREL and VREL grids are 160x172. NAGRIB is correct in not writing the data out to the file, but it should be more explicit on why. The dcgrib2 decoder sends the grid to the gemlib writing routine, which is just taking the array size needed to fill out the grid - trying to avoid checking every grid nav with the file on disk for a realtime decoder. Since there is extra data for the UREL,VREL on each row, the pattren shifts one point every row. So, it makes no sense that the number of rows/columns would change in the middle of the data, but I was able to work around this with nagrib and gdcfil. 1) I created a grid file with size to match UREL and VREL only: GEMPAK-GDCFIL>l GDOUTF = testme_ant2.gem PROJ = str/-90;180;0 GRDAREA = -78.34300;156.7770;-75.74857;174.6063 KXKY = 160;172 MAXGRD = 10000 CPYFIL = ANLYSS = GEMPAK-GDCFIL> I then created a parameter table with just "33" and "34" in it for wmogrib2.tbl and decoded the grib data with nagrib. I produced the gif at: http://www.unidata.ucar.edu/staff/chiz/gifs/antarctica_850_wnd.gif The pattern matches yours (note I convered McIDAS's map file to GEMPAK format) to show the same island as in your display. The pattern matches your, but I'm displaying in m/s, and though you said yours were m/s, they look like 2x what I'm plotting (eg in knots). At any rate, I beleive the projection code in GEMPAK is correct, and I can hack around the decoder issue with a separate output file. You could then use GDDIAG to remap the data....but the point is that something with the GRIB output should probably be fixed. Possibly they have a problem with the staggared grid remapping routine. I should fix dcgrib to match nagrib and not write the UREL and VREL to the output file an verbosely explain why! Can you double check your display units for me? Steve Chiswell Unidata User SUpport > > Were you able to see the second image, the one I placed on the webserver? > > Thanks, > Robert > > > -----Original Message----- > From: Unidata GEMPAK Support [mailto:address@hidden] > Sent: Fri 10/20/2006 5:07 PM > To: Robert Mullenax > Cc: address@hidden; address@hidden > Subject: [GEMPAK #HAN-893784]: AMPS MM5/WRF and GEMPAK > > > I used McIDAS to determine that grid point 67;72 is at -76.77S 166.27E. > > The file you grabbed has been scoured, I used McIDAS to look at the new > > run. Please get this file: > > > > http://psnldm.balloonfacility.org/csbf/wximages/grib/2006102012_D5.grb > > > > At that point for 850 mb, 12-hour forecast, McIDAS shows U=4.56 and V=-6.38 > > > > Attached is an image of wind vectors at 850. The red X is at the grid > > point. > > > > > > Robert, > > I didn't find an attached image. > > Steve > > > Ticket Details > =================== > Ticket ID: HAN-893784 > Department: Support GEMPAK > Priority: Normal > Status: Open > > > > Ticket Details =================== Ticket ID: HAN-893784 Department: Support GEMPAK Priority: Normal Status: Closed