[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20000103: GARP and y2k

Gary,
you might need to double check that the gemlib.a routines were 
correctly built prior to updating garp in that pl14 (here also assuming
that you had been running the pl12 distribution). If you hadn't upgraded
to pl12 first, then you would probably have trouble.

run: ar tv $GEMLIB/gemlib.a tictoi.o
verify that the date on the file is since Dec 30.

Am I correct that you are running under Solaris?
You can try downloading the binary from
~gbuddy/nawips-5.4/binary/solaris/garp/garp_2.1 
and verifying that you see the same problems.

Steve Chiswell
Unidata User Support


On Tue, 4 Jan 2000, Gary Lackmann wrote:

> Steve,
> 
> Yes, I fixed that, so that the Garp_defaults file is consistent
> with our 2-digit-year naming convention (I uncommented the lines
> you are referring to, and commented the others).  Like I said, this
> allows GARP to "see" all the data.  The times that appear in the
> selection window are of the form 200001041200F024.  When I select 
> such times, they cannot be plotted because (I suspect) that GEMPAK 
> cannot handle dates in this format. After clicking "display and
> close" in the "model plan projection" window, I get the following
> error message:
> 
> GEMPAK:  [DG -22] TIME ^200001041200F024 is invalid.
> 
> So, this problem is evidently not fixed by the suggested alteration
> of the Garp_defaults file.
> 
> Thanks again,
> 
> Gary
> 
> 
> At 10:57 AM 1/4/00 -0700, you wrote:
> >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
> >> 
> >
> >
> >
> 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
>