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.
Gary, In my previous message, I refered to the file naming section at the bottom of the $GARPHOME/config/Garp_defaults file. In the config file, the gridsT template is set at the bottom of the file to either: gridsT : $(grids)/@(YYYYMMDDHH)_*.gem or gridsT : $(grids)/@(YYMMDDHH)_*.gem depending on how you name your files locally. One of them should be commented out. The default I sent out was to expect 4 digit years in the file names, eg YYYY. I have tested the display with grid files using the 2 digit file names as well as 4 digit names. All of the data within the grid files will be YYMMDD/HHMM regardless of the file name. Steve Chiswell Unidata User SUpport On Tue, 4 Jan 2000, Gary Lackmann wrote: > Hi Steve, > > Thanks again for your help yesterday. That solved the satellite > problem that was resulting in core dumps. > > However, I am still having some major y2k/GARP/Gempak trouble, > even though GARP is now seeing most of the data files. When > I go to actually display model data in GARP, having selected > current times, the contours do not appear. In the parent window, > I am notified that the time 200001041200F024 (etc.) is invalid. > This seems to be because GARP is telling gdcntr to use dates like > the one above, when it really wants things like 0001041200F024. > > Is there a simple fix on a config file somewhere that I am missing? > Thanks again for any help. > > Gary > > > At 04:34 PM 1/3/00 -0700, you wrote: > > > >Gary, > > > >There is one problem with satellite lables. The affected routine is > >$GEMPAKHOME/src/gemlib/im/imar2gm.f, and I have placed an updated version of > >this routine in ~gbuddy/nawips-5.4/patches/imar2gm.f > > > >This routine is also used by all the text interface programs which > >display satellites with the SATFIL variable. > > > >You can download this file into the $GEMPAKHOME/src/gemlib/im directory > >and patch your distribution with: > > > >cd $GEMPAKHOME/src/gemlib/im > >make clean > >make all > >make clean > > > >cd $GARPHOME > >make all > >make install > >make clean > > > >cd $GEMPAKHOME/src/programs/ > >make all > >make install > >make clean > > > >Sorry for omitting that routine in the patch. Nsat also needs to be updated > >if you use that program (but Garp basically alleviates the need). If you do, > >then in $NAWIPS/nprogs/nsat/source/file.c, around line 79 should be > updated from: > > > > sprintf(tmpdate, "%s %s 19%s", day, months[m-1], year); > > > >to: > > > > if(year[0] < '2') > > sprintf(tmpdate, "%s %s 20%s", day, months[m-1], year); > > else > > sprintf(tmpdate, "%s %s 19%s", day, months[m-1], year); > > > >As for trouble reading other file types (surface, upperair, model, etc), > >check the $GARPHOME/config/Garp_defaults file for the templates at > >the bottom of the file, to make sure they match how your data is > >being stored. In the patch distribution, I made the patterns match YYYYMMDD > >file naming (rather than 2 digit YYMMDDHH) naming. If you are storing your > >data with 2 digit years, then you will want to use the patterns that are > >commented out just above the YYYY set at the bottom. > > > > > > > >Steve Chiswell > >Unidata User Support > > > > > > > >On Mon, 3 Jan 2000, Unidata Support wrote: > > > >> > >> ------- Forwarded Message > >> > >> >To: address@hidden > >> >From: Gary Lackmann <address@hidden> > >> >Subject: GARP and y2k > >> >Organization: . > >> >Keywords: 200001032123.OAA12787 > >> > >> Dear GEMPAK support team: > >> > >> I am experiencing some of what is evidently y2k GARP trouble. I applied > >> the GARP 2.1 patch, as per the earlier email from Steve Chizwell, and the > >> installation went smoothly. However, when I try to plot data with GARP, > >> cores get dumped right and left. For example, GARP "sees" the surface > >> data files, but when I go to actually plot the data, I only get a blank > >> map with the correct time stamp at the bottom. When I attempt to plot > >> satellite data, a core gets dumped. Mike Trexler has patched our > >> LDM, so the problem may lie with GARP itself. GEMPAK programs such as > >> sfmap and gdcntr work just fine with the new datafiles. > >> > >> Any hints/suggestions of things I might have overlooked would be greatly > >> appreciated. > >> > >> Best regards, > >> > >> Gary > >> > >> > >> > >> > >> Dr. Gary M. Lackmann > >> Department of Marine, Earth, and Atmospheric Sciences > >> North Carolina State University > >> Raleigh, NC 27695-8208 > >> phone: (919) 515-9688 > >> E-mail: address@hidden > >> > >> > >> ------- End of Forwarded Message > >> > >> > > > > > > > Dr. Gary M. Lackmann > Department of Marine, Earth, and Atmospheric Sciences > North Carolina State University > Raleigh, NC 27695-8208 > phone: (919) 515-9688 > E-mail: address@hidden >