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

20000229: GEMPAK decoding problems

I am getting a lot of child exited with status 1 in my ldmd.log
and GEMPAK did not crate any files last night, no UA or SFC,
or HDS, but McIDAS is working fine.  I need to archive the
data from GEMPAK for a flight we are doing right now.
Any ideas where to start looking?

Robert Mullenax

>From address@hidden  Tue Feb 29 07:34:11 2000
>Subject: more GEMPAK decode problems

I looked in my GEMAPK decoder log files and apparently they
do not recognize the leap day and that is why they are failing.
They have:

000229/1425  INVALID DATTIM

but I don't know how to fix it, of course.

Thanks,
Robert Mullenax

>From address@hidden  Tue Feb 29 08:03:51 2000
Hi everyone,

Am I the only one seeing this from dchrly?

DCHRLY[9833]: 000229/1501: [RA -9]  SAAW31  KWBC    291330
DCHRLY[9833]: 000229/1501: INVALID BULLETIN: SAAW31  KWBC    291330
DCHRLY[9833]: 000229/1501: INVALID DATTIM:                000229/1501  42540

I have no Gempak decoded data since 02/29/00Z.  So I assume that my other dc
decoders are having the same trouble.  Could this be a leap year day problem.

Pete.

>From address@hidden  Tue Feb 29 08:25:31 2000

We are having the same problems with any means to put surface data
into gempak (dchrly, sfedit,...)  Gempak will put data in for 2/28 and
3/01, but not for 2/29.

Bryan

>From address@hidden  Tue Feb 29 08:29:20 2000

Hello,

At NCSU we are experiencing the same problem, and a quick check 
around indicates that other sites are as well.  Evidently, something 
is not "leap year compliant"?  Our satellite and radar imagery are
fine though.

Gary Lackmann

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

>From address@hidden  Tue Feb 29 08:35:49 2000

I see it too, Pete.  I believe the problem emanates from a Y2K/leap year
bug in two GEMPAK time library subroutines:  TI_CTOI and TI_ITOC.  Both 
of them have a check for a leap year that rejects a leap year if 
"iyear .eq 0 ".  This is not correct, as we know, for Y2K!  If you
recompile these two TI subroutines, then rebuild your $GEMLIB (gemlib.a)
archive, then rebuild all executables, things appear to work.

--Kevin Tyle <address@hidden>
MESO, Inc.

>From address@hidden  Tue Feb 29 08:50:10 2000

Peter, and All
        You're not alone.  It appears to be a leap day problem from 
looking at some file names. (I've been checking my ldm stuff 'cuz
I installed the new server software, ldm5.0.9, yesterday.)
The decoded stuff is name mangled at Cornell also.
        Example:  
            decoding:   20        _eta_grid211.gem
                should be:  2000022900_eta_grid211.gem
I am thinking...(well, sort'a) that the leap year date got mangled but
the Y2K thousand year fix worked!  (...probably hard coded.)            

>From address@hidden  Tue Feb 29 09:02:15 2000
From: Tom Priddy

We seem to have a feb 29th problem here at U.K.  No scripts are
working...
I'm assuming it is a leap day problem....also noticing other locations
havoing
similar problems. Is there a patch?/ktp

--
Tom Priddy                                address@hidden

>From address@hidden  Tue Feb 29 09:21:19 2000
 
Yup. Look at the hourly weather roundups and the ADMIN messages. Y2K
glitch has struck GEMPAK and AFOS scripts.

>From address@hidden  Tue Feb 29 09:32:39 2000
all:

one of the problems is in gemlib/ti/tictoi.f

there is a fix for the year 1900 that screws up the year 2000.

 here is a temporary patch
C
C*      Change February in leap year.
C
        jmonth = imonth
        IF  ( ( jmonth .eq. 2 ) .and.
     +        ( MOD ( iyear, 4 ) .eq. 0 ) )  jmonth = 13

you can fix it more elegantly if you want by looking at the other routines in 
that directory, but right now i'm scrambling to get things going again. (while 
trying to figure out where the problem was, i'd disabled the more elegant 
solutions and am just checking for mod (iyear,4))

with this fix i'm now able to process surface data that we need to get mesonet 
going again.

john

>From address@hidden  Tue Feb 29 09:36:21 2000

FYI, The pl15 binaries that were distributed for linux DO NOT have
the fix this problem. And since we can't compile from source, linux 
users will have to wait for the fix from Steve out at Unidata.

Pete

>From address@hidden  Tue Feb 29 09:44:32 2000

my apologies. i hadn't checked email for a while to see bug had been identified 
earlier.

john

>From address@hidden  Tue Feb 29 09:45:29 2000

I've got a Linux recompile running right now.
Will post the binary soon as it's availble.

>From address@hidden  Tue Feb 29 10:38:45 2000

Sorry for the delay... I had to start from a clean source
tree and it takes a LONG time for the several hundred gempak
files to compile.  Am testing now.  Will tell you where to
get them shortly if it seems to be working.  Waiting for
some surface data to come in.

>From address@hidden  Tue Feb 29 10:49:18 2000

OK... Seems to be working, though haven't checked it
too carefully yet.  However in the interests of getting
this to everyone who wants it ASAP...

ftp to data2.atmos.uiuc.edu
username: gemfix   passwd: gemfix

There you'll find a directory
gempakpl15_linux6_bin

This contains all the gempak binaries, recompiled with
a fix the the date handling code that's causing
the LY2K problem.

Remember to:

 1) save your old gempak binaries (in case something's
    wrong with the new ones)
 2) transfer the files in binary mode
 3) temporarily shut down pqact while installing the binaries
 4) run "chmod 755" on the binaries after ftp'ing

>From address@hidden  Tue Feb 29 11:01:52 2000

Hi,

I am assuming that this problem will go away around 0000Z tomorrow.  If
I'm wrong, please tell me!  We're just waiting for 0Z at this point.

Thanks,
Tim

>From address@hidden  Tue Feb 29 11:47:38 2000

One note of warning I just realized:  The one's I put out
there are Redhat6.0 binaries.  (I'm compiling for
both platforms).  There is an incompatibility between
6.0 and 6.1 and not all the 6.0 binaries work on 6.1.

I'm compiling for 6.1 now, or you can wait for Steve's
pl16 version at Unidata.

--------------------------------------------------------
 David Wojtowicz, Research Programmer/Systems Manager
 Department of Atmospheric Sciences Computer Services
 University of Illinois at Urbana-Champaign
 email: address@hidden  phone: (217)333-8390
--------------------------------------------------------

From: Steve Chiswell <address@hidden>
Date: Tue, 29 Feb 2000 10:52:45 -0700
To: address@hidden, address@hidden
cc: address@hidden
Subject: 20000229: year mod 400 leap year

I have updated copies of the 2 time format routines
rearranged for MOD(year,400) leap years.

I have posted updates for tiitoc.f and tictoi.f in the
~gbuddy/gempak5.4/patches directory. I will post recompiled
binaries for Solaris X86 and Linux distributions in the
~gbuddy/gempak5.4/binary directories as pl16.

To update your source distribution, download the 2 files
into your $GEMPAKHOME/source/gemlib/ti directory, then:

1) update your gemlib

cd $GEMPAKHOME/source/gemlib/ti
make clean
make all
make clean

2) update your programs and decoders

cd $GEMPAKHOME/source/programs
make clean
make all
make install
make clean

cd $NAWIPS/unidata
make clean
make all
make install
make clean

cd $NAWIPS/nprogs
make clean
make all
make install
make clean

cd $GARPHOME
make clean
make all
make install
make clean

(optional if you are using dcacars and dcncprof which aren't built 
by default since you need NetCDF installed)

cd $NAWIPS/unidata/ldmbridge/dcacars
make clean
make all
make install
make clean

cd $NAWIPS/unidata/ldmbridge/dcncprof
make clean
make all
make install
make clean

The above will relink programs, decoders, and GUIs.

I will repackage the complete source distribution as pl16 asap.


Steve Chiswell
Unidata User Support