20041229: 20041222: GEMPAK 5.7.4 sfgram_gf local modification trouble

David,

There are a couple of arrays in sfgram.f that are LLMXTM*MMPARM in size,
which would be 300*70 = 21,000. This type of array size isn't
found in the plan view plotting programs. One reason you may now have problems
that didn't surface with 5.6.L is that other arrays have grown as well
over time.

I haven't ruled out other problems yet, but it could be that
array size is too large. Can you run the program in the debugger
(compile the code with "-g" and provide me with the "where" output
of the location where the program is having the segmentation fault)
and or a trace of the program at the point of failure?

Please provide me with the "limit" command output and your OS,
since stacksize may be an issue here.

Steve Chiswell
Unidata User Support





>From: David Ovens <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200412291724.iBTHOjlI019118

>Steve,
>
>The mods were made before any build.  Older versions, 5.6.L, worked fine, but
>not 5.7.2.  Again, sfgram_gf is the only one that fails --  sfgram,
>sfmap, sfmap_gf work fine with these files.  Suggestions?
>
>David
>-- 
>David Ovens             e-mail: address@hidden
>Research Meteorologist    phone: (206) 685-8108
>Dept of Atm. Sciences      plan: Real-time MM5 forecasting for the
>Box 351640                        Pacific Northwest
>University of Washington          http://www.atmos.washington.edu/mm5rt
>Seattle, WA  98195               Weather Graphics and Loops
>                                  http://www.atmos.washington.edu/~ovens/loops
>
>On Thu, Dec 23, 2004 at 10:36:39AM -0700, Unidata Support wrote:
>> 
>> David,
>> 
>> If you have set MMPARM in both gemprm.h and GEMPRM.PRM, then
>> you have satisfied both cgemlib.a and gemlib.a.
>> 
>> Did you make the mods to a fresh build, or did you do a "make distclean"
>> to remove all libraries in $GEMLIB? Failure to do that would result in confl
> icts
>> between the program using one value and the library routine using
>> a different value. 
>> 
>> If the array is being crashed, it could pop up in older versions as well,
>> just dependent on how the linking order has changes the memory allocation
>> around.
>> 
>> Steve Chiswell
>> Unidata User SUpport
>> 
>> 
>> >From: David Ovens <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200412221928.iBMJSllI020456
>> 
>> >Hello Unidata GEMPAK support (Steve),
>> >
>> >I have made modifications to GEMPRM.PRM and gempak/include/gemprm.h to
>> >change MMPARM from 40 to 70.  This has worked great in all past
>> >releases of GEMPAK with all programs.  
>> >
>> >Now, in GEMPAK 5.7.4, I have encountered a bug in sfgram_gf that is
>> >not found in sfgram.  I create a file with about a week's worth of
>> >surface data in it and then plot meteograms for 3 stations.  2 of the
>> >3 stations work fine but the 3rd causes a Segmentation fault.  Here's
>> >a breakdown of several scenarios that use this exact same file,
>> >lastweeksfc.gem, which was generated by my modified 5.7.4 code:
>> >
>> >  1) 5.7.4 sfgram (all stations fine)
>> >  2) 5.6.L sfgram and sfgram_gf (all stations fine)
>> >  3) 5.7.4 sfgram_gf (2 of the 3 are ok)
>> >
>> >I notice that the linking of programs_gf in sfgram has changed between
>> >5.6.L and 5.7.4 (due I am sure to changes in CGEMLIB and GEMLIB) and
>> >it is my belief that this is the culprit.  I think CGEMLIB which is
>> >now before the second GEMLIB linking step must have MMPARM set smaller
>> >or something like that.
>> >
>> >Attempting to compile sfgram_gf the same way as in 5.6.L leads to this
>> >error:
>> >g77 -fno-second-underscore
>> >-I/home/disk/frosty/ovens/NAWIPS-5.7.4/gempak/include
>> >-I/home/disk/frosty/ovens/NAWIPS-5.7.4/gempak/include/Linux -O
>> >sfgram.f /home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/sfgram.a
>> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/ginitp_alt.o
>> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/gendp_alt.o
>> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/gemlib.a
>> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/gplt.a
>> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/device.a
>> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/gf.a
>> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/gn.a
>> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/gemlib.a
>> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/cgemlib.a \
>> >        -L/usr/X11R6/lib -lX11  -o
>> >    /home/disk/frosty/ovens/NAWIPS-5.7.4/bin/linux/sfgram_gf
>> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/cgemlib.a(cgrrange.o)(.text+
> 0xd
>> > 2):
>> >In function `cgr_range_':
>> >: undefined reference to `gqgprj_'
>> >collect2: ld returned 1 exit status
>> >make: *** [sfgram_gf] Error 1
>> >
>> >There may be numerous other *_gf program failures, but I have not
>> >found them yet.  sfplot_gf works fine with this 'lastweeksfc.gem'
>> >file, plotting data at all 3 of the stations. 
>> >
>> >Please help.
>> >
>> >Thanks and happy holidays,
>> >
>> >David
>> >-- 
>> >David Ovens          e-mail: address@hidden
>> >Research Meteorologist    phone: (206) 685-8108
>> >Dept of Atm. Sciences      plan: Real-time MM5 forecasting for the
>> >Box 351640                        Pacific Northwest
>> >University of Washington          http://www.atmos.washington.edu/mm5rt
>> >Seattle, WA  98195               Weather Graphics and Loops
>> >                                  http://www.atmos.washington.edu/~ovens/lo
> ops
>> >
>> --
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8643                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service              http://my.unidata.ucar.edu/content/support 
>> ----------------------------------------------------------------------------
>> NOTE: All email exchanges with Unidata User Support are recorded in the
>> Unidata inquiry tracking system and then made publicly available
>> through the web.  If you do not want to have your interactions made
>> available in this way, you must let us know in each email you send to us.
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.