[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GEMPAK #HAN-893784]: AMPS MM5/WRF and GEMPAK
- Subject: [GEMPAK #HAN-893784]: AMPS MM5/WRF and GEMPAK
- Date: Mon, 23 Oct 2006 16:08:48 -0600
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