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

20000306: gempak_pl15 bug?

David,

At the very least, your surface files can have a problem.
The key point in changing these array sizes is that the number 
of headers has to be large enough to accomodate the number of times
and the number of stations in a surface file.

The defaults as I configure are:
MMHDRS =  10000
LLMXTM =   200
LLSTFL =  9800

If you change LLMXTM to 2000, then you should increase MMHDRS accordingly.
This value will also have to be changed in gemprm.h! You can increase LLMXGT
up to MMHDRS.

Since your gd program problem isn't directly related to surface files,
looking for a LLMXTM is probably a good idea.
I found in $GEMPAKHOME/source/gemlib/gr/grtlst.f line 41 and line 47
that there are 2 occurances that should be changed.

When these array sizes are stepped on, it probably is just luck, or unluck
as to whether  your program is corrupted. The compiler version and the use of
-g or -O can affect how the variable values are aligned in memory, which would
explain why you see the problem and I haven't.

Hope that this solves your problems.

Steve Chiswell
Unidata User Support








>From: "David J. Knight" <address@hidden>
>Organization: .
>Keywords: 200003291943.MAA25650

>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 Pro
>> > > (303)497-8644                                                  P.O. Box 
>> > > address@hidden                                   Boulder, CO 8
>> > > ------------------------------------------------------------------------
>> > > Unidata WWW Service                        http://www.unidata.ucar.edu/ 
>> > > ************************************************************************
>> > > 
>> > 
>