20000103: GARP and y2k (fwd)

---------- Forwarded message ----------
Date: Wed, 05 Jan 2000 13:37:04 -0500
From: Gary Lackmann <address@hidden>
To: Steve Chiswell <address@hidden>
Subject: Re: 20000103: GARP and y2k

Steve,

Thanks again for your help.  Indeed, the library somehow was not
updated, so I repeated the procedure and now things are (mostly)
working properly.  

Best Regards,

Gary

At 12:54 PM 1/4/00 -0700, you wrote:
>
>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
>> 
>
>
>
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