20041222: GEMPAK 5.7.4 sfgram_gf local modification trouble

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 conflicts
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/loops
>
--
**************************************************************************** <
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.