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 > > >