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

Re: 20000306: gempak_pl15 bug?

Hi again Chiz,
     Yet another potential clue. As you know we don't run a quite stock
gempak here. One of the things I changed was:

<       PARAMETER       ( LLMXTM =   200   )
---
>       PARAMETER       ( LLMXTM =   2000   )

in include/gemprm.SunOS. We do this to allow more ob times in surface
files.

I notice that gdcntr.f used to (incorrectly) use LLMXTM as the maximum
number of times, but has now been changed to (correctly) use LLMXGT
instead. I suspect that somewhere in the code is lurking a place where
LLMXTM should still be changed to LLMXGT to match the change in gdcntr.

I'll look into this further, but not today. Perhaps instead I'll just
change LLMXTM  to equal LLMXGT in gemprm.SunOS (1000 should fulfill most,
if not all our needs) and recompile. I'm guessing that this will solve our
problem for now. Either way I'll let you know what I find unless you
happen to find something first.
Oh what fun...
Later,
David

> Hi Chiz,
> I know it has been awhile - I ran into a busy time...   
> More information on this problem. Hoping this
> will help you help us debug the problem.
> 
> If I specify
>  GDATTIM  = 940706/0000f021:940706/0000f024
>  GLEVEL   = 925:850
>  GVCORD   = pres
> 
> In gempak5.4_pl15
> I get
>  GEMPAK-GDCNTR> [DG -23]  LEVEL @ is invalid.
> 
>  Grid file:                                                                   
>       
>  GRID IDENTIFIER: 
>     TIME1             TIME2         LEVL1 LEVL2   VCORD PARM
> 940706/0000f021:94                      0  0       NONE             
> 
> 
> In gemp5.4_pl6 I get 
>  GRID IDENTIFIER: 
>     TIME1             TIME2         LEVL1 LEVL2   VCORD PARM
> 940706/0000F021    940706/0000F024    925  850     PRES RES         
> 
> 
> It appears that our gempak5.4_pl15 is not properly parsing
> the mutiple times. It looks like might be resulting in other
> variables getting clobbered as well.
> 
> Does this help suggest where we might  look for the problem?
> 
> Thanks
> David
> 
> > 
> > 
> > it was built in a clean new directory.
> > 
> > But we are still using v4 compilers
> > (I know, I guess we should upgrade).
> > Still I don't understand why pl6 would work and
> > pl15 would not...
> > 
> > David
> > 
> > > 
> > > >From: "David J. Knight" <address@hidden>
> > > >Organization: .
> > > >Keywords: 200003081517.IAA25757
> > > 
> > > >
> > > >Chiz,
> > > >     I did not create the offending grid file, but
> > > >my understanding is that is was made using gempak5.4
> > > >and gddiag. 
> > > >
> > > >Yes I compiled the gempakupc_pl15 from source
> > > >on Solaris 2.6 machine.
> > > >
> > > >I put the grid on
> > > >ftp://ftp.atmos.albany.edu/pub/gempak/mmoutp2.type2b2thermo.gem
> > > >
> > > >If you could test it that would be great. For right now
> > > >we will just use gempak5.4_pl6 for this particular plot.
> > > >
> > > >Thanks
> > > >
> > > >David
> > > >
> > > 
> > > David,
> > > 
> > > I downloaded the file and plotted the field using both solaris and sgi.
> > >  GDATTIM  = 940706/0000f021:940706/0000f024
> > >  GLEVEL   = 925:850
> > >  GVCORD   = pres
> > >  GFUNC    = mul(res,3600)
> > >  GDFILE   = mmoutp2.type2b2thermo.gem
> > >  PROJ     = scc
> > >  GAREA    = grid
> > > 
> > > Its a pretty noisy looking field...but I don't see the problem
> > > you are having.
> > > 
> > > So, my next question is, was the pl15 built in a clean subdirectory-
> > > or was it unpacked in your previous pl6 tree (I figured you wouldn't
> > > have done this sonce you had modified some tables for your use that
> > > you probably didn't want to get overwritten...but if you did, then 
> > > its possible that some functions in the libraries were not rebuilt
> > > if you didn't completely wipe out $GEMLIB/*).
> > > 
> > > My solaris configuration for 2.6 is
> > > chiz--> cc -V
> > > cc: WorkShop Compilers 5.0 98/12/15 C 5.0
> > > chiz --> f77 -V
> > > f77: WorkShop Compilers 5.0 99/09/16 FORTRAN 77 5.0 patch 107596-03
> > > 
> > > Steve Chiswell
> > > ****************************************************************************
> > >  <
> > > Unidata User Support                                    UCAR Unidata 
> > > Program <
> > > (303)497-8644                                                  P.O. Box 
> > > 3000 <
> > > address@hidden                                   Boulder, CO 80307 <
> > > ----------------------------------------------------------------------------
> > >  <
> > > Unidata WWW Service                        http://www.unidata.ucar.edu/   
> > >    <
> > > ****************************************************************************
> > >  <
> > > 
> > 

From address@hidden  Wed Mar 29 10:39:57 2000
Received: from atmos.albany.edu (redwood.atmos.albany.edu [169.226.4.37])
        by unidata.ucar.edu (8.8.8/8.8.8) with ESMTP id KAA21100;
        Wed, 29 Mar 2000 10:39:55 -0700 (MST)
Organization: .
Keywords: 200003291739.KAA21100
Received: from oak.atmos.albany.edu (oak [169.226.4.39])
        by atmos.albany.edu (8.8.8+Sun/8.8.8) with ESMTP id RAA20713;
        Wed, 29 Mar 2000 17:39:52 GMT
Received: (from knight@localhost)
        by oak.atmos.albany.edu (8.9.3+Sun/8.9.1) id RAA18297;
        Wed, 29 Mar 2000 17:39:51 GMT
Date: Wed, 29 Mar 2000 17:39:51 GMT
From: "David J. Knight" <address@hidden>
Message-Id: <address@hidden>
To: address@hidden, address@hidden
Subject: Re: 20000306: gempak_pl15 bug?
Cc: address@hidden, address@hidden
X-Sun-Charset: US-ASCII

Hi Chiz,
I know it has been awhile - I ran into a busy time...   
More information on this problem. Hoping this
will help you help us debug the problem.

If I specify
 GDATTIM  = 940706/0000f021:940706/0000f024
 GLEVEL   = 925:850
 GVCORD   = pres

In gempak5.4_pl15
I get
 GEMPAK-GDCNTR> [DG -23]  LEVEL @ is invalid.

 Grid file:                                                                     
    
 GRID IDENTIFIER: 
    TIME1             TIME2         LEVL1 LEVL2   VCORD PARM
940706/0000f021:94                      0  0       NONE             


In gemp5.4_pl6 I get 
 GRID IDENTIFIER: 
    TIME1             TIME2         LEVL1 LEVL2   VCORD PARM
940706/0000F021    940706/0000F024    925  850     PRES RES         


It appears that our gempak5.4_pl15 is not properly parsing
the mutiple times. It looks like might be resulting in other
variables getting clobbered as well.

Does this help suggest where we might  look for the problem?

Thanks
David

> 
> 
> it was built in a clean new directory.
> 
> But we are still using v4 compilers
> (I know, I guess we should upgrade).
> Still I don't understand why pl6 would work and
> pl15 would not...
> 
> David
> 
> > 
> > >From: "David J. Knight" <address@hidden>
> > >Organization: .
> > >Keywords: 200003081517.IAA25757
> > 
> > >
> > >Chiz,
> > >     I did not create the offending grid file, but
> > >my understanding is that is was made using gempak5.4
> > >and gddiag. 
> > >
> > >Yes I compiled the gempakupc_pl15 from source
> > >on Solaris 2.6 machine.
> > >
> > >I put the grid on
> > >ftp://ftp.atmos.albany.edu/pub/gempak/mmoutp2.type2b2thermo.gem
> > >
> > >If you could test it that would be great. For right now
> > >we will just use gempak5.4_pl6 for this particular plot.
> > >
> > >Thanks
> > >
> > >David
> > >
> > 
> > David,
> > 
> > I downloaded the file and plotted the field using both solaris and sgi.
> >  GDATTIM  = 940706/0000f021:940706/0000f024
> >  GLEVEL   = 925:850
> >  GVCORD   = pres
> >  GFUNC    = mul(res,3600)
> >  GDFILE   = mmoutp2.type2b2thermo.gem
> >  PROJ     = scc
> >  GAREA    = grid
> > 
> > Its a pretty noisy looking field...but I don't see the problem
> > you are having.
> > 
> > So, my next question is, was the pl15 built in a clean subdirectory-
> > or was it unpacked in your previous pl6 tree (I figured you wouldn't
> > have done this sonce you had modified some tables for your use that
> > you probably didn't want to get overwritten...but if you did, then 
> > its possible that some functions in the libraries were not rebuilt
> > if you didn't completely wipe out $GEMLIB/*).
> > 
> > My solaris configuration for 2.6 is
> > chiz--> cc -V
> > cc: WorkShop Compilers 5.0 98/12/15 C 5.0
> > chiz --> f77 -V
> > f77: WorkShop Compilers 5.0 99/09/16 FORTRAN 77 5.0 patch 107596-03
> > 
> > Steve Chiswell
> > ****************************************************************************
> >  <
> > Unidata User Support                                    UCAR Unidata 
> > Program <
> > (303)497-8644                                                  P.O. Box 
> > 3000 <
> > address@hidden                                   Boulder, CO 80307 <
> > ----------------------------------------------------------------------------
> >  <
> > Unidata WWW Service                        http://www.unidata.ucar.edu/     
> >  <
> > ****************************************************************************
> >  <
> > 
>