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.
Hi again Jack,
Here goes...
The way that grid projections are specified for model grids in McIDAS is through
the grid definition file gbtbpds001.bv1 (this gets installed in the ~mcidas/data
directory).
For the sake of this email, let's focus on grids 202 and 213 since they have
the same coverage, but the 213 is double the resolution of grid 202:
The gbtbpds001.bv1 (GRIB Table B) definitions for the 202 and 213 projections
are:
202 | Conus
Polar Stereographic|0| 2795|43|65|-2.0| 33.0|19.05 |105.0|60.0| 60.0
2795|43|65|-2.0| 33.0|19.05 |105.0|60.0| 60.0
213 | National - CONUS - Double Resolution
Polar Stereographic|0|10965|85|129|-3.0| 65.0|9.525|105.0|60.0|60.0
10965| 85| 129|-3.0| 65.0| 9.525| 105.0| 60.0| 60.0
These definitions for grids broadcast in NOAAPort are part of:
NCEP Office Note 388 G R I B
http://www.nco.ncep.noaa.gov/pmb/docs/on388/
In particular, the pole points specified are:
Grid 202
Nx 65
Ny 43
Pole point
(I,J) (33, 45)
Grid 213
Nx 129
Ny 85
Pole point
(I,J) (65, 89)
The McIDAS plot for grid 213 for the 12 UTC GFS run on 2008068 for forecast
hour 0 matches GEMPAK plots that I could find on the web. To me this indicates
that the gbtbpds001.bv1 for grid 213 is likely to be correct:
10965| 85| 129|-3.0| 65.0| 9.525| 105.0| 60.0| 60.0
^
|__ row number of the pole
If this is really correct, it means that the specification for the row of
the pole for the 202 grid is incorrect:
2795|43|65|-2.0| 33.0|19.05 |105.0|60.0| 60.0
^
|__ row number of the pole
A value of '-1.0' would match the way the pole row is specified for the
213 grid.
To verify if adjusting this value would have the desired effect on the
grid placement, I did the following:
GRDCOPY RTGRID/GFS MYDATA/GRIDS.3000 PAR=P LEV=MSL DAY=68 TIME=12 FHOUR=0
GRIB=202
This created the GRID file GRID3000 on my home test machine with one grid: P at
MSL. I then adjusted the row number of the grid copied to be '-1.0' as follows:
LWU POKE GRID3000 -10000 1047
Value was: -20000 HEX: FFFFB1E0 ASCII:
I then plotted the modified grid 202 P at MSL field and overlaid the grid 213
field for the same time, etc.
I have attached two GIFs that show the results of the change. The first GIF
shows
grid 213 overlaid (cyan) on the unmodified grid 202 grid (yellow). This plot
illustrates exactly the same thing as you reported - the grid 202 features
appear
to be shifted to the south.
The second GIF shows the grid 213 grid overlaid (in cyan) on the modified grid
202
grid (yellow).
Since the agreement between grid 213 and the modified grid 202 one is so good, I
am convinced that the row of the pole for grid 202 specified in gbtbpds001.bv1
is
incorrect!
I will include a revised gbtbpds001.bv1 (and gbtbpds001.b98v1) table in the next
Unidata McIDAS addendum. I will also alert SSEC to the problem that was found.
I will update the tables on all Unidata-maintained, publically-accessible ADDE
servers immediately. We should see good correspondence between the 202 and
213 grids starting with the 12 UTC GFS run on Sunday.
Thanks for spotting the problem! It has been in McIDAS forever!!
Cheers,
Tom
****************************************************************************
Unidata User Support UCAR Unidata Program
(303) 497-8642 P.O. Box 3000
address@hidden Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage http://www.unidata.ucar.edu
****************************************************************************
Ticket Details
===================
Ticket ID: APD-338129
Department: Support McIDAS
Priority: Normal
Status: ClosedAttachment:
grid202_grid213.gif
Description: GIF image
Attachment:
grid202m_grid213.gif
Description: GIF image