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.
---------- Forwarded message ---------- Date: Mon, 18 Dec 2000 22:41:18 -0700 (MST) From: Steve Chiswell <address@hidden> To: David Ovens <address@hidden> Subject: Re: 20001215: sfcntr bug David, Our machine is still running OSF4.0f. Once the reomodeling of our office space is complete, our system administrator will set up the new Compaq running 5.0 so that I can test things directly on your platform. One thing that you could try is completely removing $GEMLIB/sfcntr.a then in the sfcntr director do a " make all install clean". Occasionally, I have found that DEC's "make" program fails to update archive members after compiling the code. Other than that, I'll keep delving into the problem, but will go ahead and release GEMPAK 5.6.a tomorrow since I want to make sure sites have time to upgrade to read the zlib compressed NIDS products before January. Thanks for your efforts, Steve Chiswell Unidata User Support On Mon, 18 Dec 2000, David Ovens wrote: > Steve Chiswell wrote: > > David, > > > > I think the problem lies in the fact that a "grid" is defined on one of > > the standard angular projections and not RAD or SAT projections using the > > gsmprj() call in sfcntr. > > > > I have worked around this now, so that if SAT or RAD is the projection > > of the display, the grid is created on a CED projection using the LL and UR > > bounds of the image. The grid can always be projected to the image > > coordinates for display (similarly, I don't think you can run GDCFIL > > and get a meaningful grid with PROJ=SAT). > > > > I have attatched updated sfcntr.f and oagagn.f for the > > $GEMPAK/source/programs/sf/sfcntr directory. > > > > I will make these routines part of the GEMPAK5.6a release, but > > you can try them out now if you have the chance. > > > > Steve Chiswell > > Unidata User Support > > > Steve, > > Sure enough the Sun version now works flawlessly. The DEC version > still fails to ever plot any contours, however. > > David > -- > David Ovens e-mail: address@hidden > (206) 685-8108 plan: Real-time MM5 forecasting for Pacific Northwest > Research Meteorologist > Dept of Atmospheric Sciences, Box 351640 > University of Washington > Seattle, WA 98195 >