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.
Bob,
The Lo1 longitude is 59.503, while the Lov is 52.550, so the
central longitude is outside the grid domain which is not
a possibility I checked when I put in a work around for
another problem.
Here the problem with dcgrib2 is a check in the lambert grib routine
which is necessary when grids straddle the date line (eg Lo1 might be
175, but Lov -179), where if Lov is less than Lo1, it assumes that 360
has to be added so the computation is possible. This is something I put
in, and not in NCEP's distribution. I can change
$GEMPAK/source/gemlib/gb/gblamb.c to
only do that when the Lo1 > 0 and loncnt < 0.
I made that change and now the gdinfo produces:
GRID FILE:
2006011306_testme.gem
GRID NAVIGATION:
PROJECTION: LCC
ANGLES: 60.0 52.5 30.0
GRID SIZE: 252 252
LL CORNER: 29.07 59.50
UR CORNER: 38.22 75.59
This is pakistan.
Do you want the updated routine, or a recpiled dcgrib2 binary?
Steve
On Fri, 2006-02-17 at 10:48, Robert Rozumalski wrote:
> Steve,
>
> Attached is a grib I pulled from a larger file generated by the AFWA WFR
> model.
> The domain should be over Afghanistan but after converting it to GEMPAK with
> dcgrib2 the domain appears to be over Hawaii. So, can you tell if the problem
> is with the navigation in gempak or the grib file?
>
>
> Bob
>
>
>