> > Steve, > > Matt Lazzarra does not want any changes made to the GRIB data at this time. > Matt manages the Antarctic-IDD. I am not quite completely clear on what I > need to do to be able to reproduce your workaround at least > semi-automatically. Can you go over it again? > > Thanks, > Robert Mullenax Robert, I used nagrib to decode just the U and V components into their projection/navigation as follows: GBFILE = 2006102012_D5.grb INDXFL = GDOUTF = antarctica_uv.gem PROJ = str/-90;180;0 GRDAREA = -78.34300;156.7770;-75.74857;174.6063 KXKY = 160;172 MAXGRD = 10000 CPYFIL = GAREA = dset OUTPUT = t GBTBLS = GBDIAG = PDSEXT = NO OVERWR = NO GEMPAK-NAGRIB> I decoded the rest of the your data (eg the 159x171 -78.34;156.78;-75.77;174.52 grid with: GBFILE = 2006102012_D5.grb INDXFL = GDOUTF = antarctica.gem PROJ = str/-90;180;0 GRDAREA = -78.34;156.78;-75.77;174.52 KXKY = 159;171 MAXGRD = 10000 CPYFIL = GAREA = dset OUTPUT = t GBTBLS = GBDIAG = PDSEXT = NO OVERWR = NO GEMPAK-NAGRIB> Note: you could use CPYFIL=gds and omit the KXKY, PROJ and GRDAREA assuming you knew that the first grid in the file was going to be one of the 159x171 grids. GEMPAK is perfectly happy using grids from different navigations and different files in its calculations, so at this point, you could do all your plots, but it would require the use of the +n file notation in your formulas. Alternatively, you can use gddiag to write the UREL and VREL levels into the other file. The gdinfo for the UREL and VREL grids had levels: 10 and 300 for GVCORD= HGHT 1000, 925, 850, 700, 600, 500, 400, 300, 250, 200, 150 and 100 for GVCORD=PRES I created the attached script to run each level/coordiate time foe the F006-F036 times in the sample data you provided. All plotted just fine from the merged file. Steve Chiswell Unidata User Support > > > -----Original Message----- > From: Unidata GEMPAK Support [mailto:address@hidden] > Sent: Mon 10/23/2006 5:08 PM > To: Robert Mullenax > Cc: address@hidden; address@hidden > Subject: [GEMPAK #HAN-893784]: AMPS MM5/WRF and GEMPAK > > 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 > > > > Ticket Details =================== Ticket ID: HAN-893784 Department: Support GEMPAK Priority: Emergency Status: Closed
Attachment:
antarctica_merge.csh
Description: Binary data