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

[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