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

[GEMPAK #VNL-434404]: GEMPAK - Using g77 to link to gempak libraries



Baxter,

I had not seen your code segment since my response to your original support 
request.

After looking at your code, I see that you have incorrectly defined IGHDR as a 
single integer,
where instead it needs to be defined as an integer array of size LLGDHD as 
defined in GEMPRM.PRM
(typically 128). The call to GD_RDAT will attempt to write to the array, which 
will step
on other variables you have declared around that location in memory. The 
Solaris compiler is
simply arranging variables differently in memory, so you have not directly seen 
this affect your
execution yet. Note that the linker and loader will arrange memory usage as 
efficiently as possible
with the -O flag, so the variables getting stepped on are not necessarily in 
the same order
as how you have declared them in your program.

Steve Chiswell
Unidata User Support


> I was wondering if you had a chance to look at the question below. I have 
> tried the code using g77, ifort, pgf77, and gfortran and get the same 
> results, but it still works with solaris f77. If I include -O, I at least get 
> igx and igy read correctly, but it is still writing over the file access 
> number. I am at a loss with this. I have tried this on multiple linux boxes.
> 
> Thanks
> 
> _____________________________
> Martin A. Baxter, Ph.D.
> Assistant Professor of Meteorology
> Department of Geography
> Central Michigan University
> Mount Pleasant, MI 48859
> (989) 774-2055
> 
> ________________________________
> 
> From: Baxter, Martin A
> Sent: Wed 1/24/2007 10:49 AM
> To: address@hidden
> Subject: RE: [GEMPAK #VNL-434404]: GEMPAK - Using g77 to link to gempak 
> libraries
> 
> 
> 
> Steve,
> 
> Yes, I see that the program is writing over memory when it tries to read in 
> even a single grid, but I can't figure out why it is doing this or how to fix 
> it. Machine details and an example of the problem follow. I tried building 
> 5.9.4 from source and running the same code and it didn't work. It still runs 
> fine on Solaris.
> 
> uname -a Linux baxter.cst.cmich.edu 2.6.18-1.2239.fc5smp #1 SMP Fri Nov 10 
> 13:22:44 EST 2006 i686 i686 i386 GNU/Linux
> 
> The program below is compiled with:
> 
> f77 -fno-second-underscore -o newtest.exe ./newtest.f $GEMLIB/gemlib.a 
> $GEMLIB/cgemlib.a $GEMLIB/gemlib.a
> 
> integer IRET, IERR
> integer IGDFLN, NAVSZ, IANLSZ, IHDRSZ, MAXGRD
> integer IGX, IGY, IGHDR
> logical WRTFLG
> real    RNVBLK(256), ANLBLK(256)
> 
> character gfile*45, gdattim(2)*20, parm*4
> integer ivcord, level(2)
> parameter (ix=93,iy=65)
> real grid(ix,iy)
> real temp(ix,iy), httt(ix,iy)
> 
> WRTFLG = .true.
> gfile = '2007012012_eta211.gem'
> ivcord = 1
> level(1) = 500
> level(2) = -1
> gdattim(1) = '070120/1200f000'
> gdattim(2)= ' '
> 
> CALL IN_BDTA(IRET)
> 
> CALL GD_OPNF(gfile, WRTFLG, IGDFLN, NAVSZ, RNVBLK, IANLSZ,
> +             ANLBLK, IHDRSZ, MAXGRD, IRET)
> if (iret .ne. 0) print*, iret, 'open1'
> 
> parm='TMPK'
> CALL GD_RDAT  ( IGDFLN, gdattim, level, ivcord, parm, temp, IGX,
> +                IGY, IGHDR, IRET )
> if (iret .ne. 0) print*, iret, 'tmpk', gdattim(1), level(1)
> 
> print *,'igdfln= ',IGDFLN
> print *,'gdattim= ',gdattim
> print *,'level= ',level
> print *,'ivcord= ',ivcord
> print *,'parm= ',parm
> print *,'igx= ',IGX
> print *,'igy= ',IGY
> print *,'ighdr= ',IGHDR
> print *,'iret= ',IRET
> 
> if (93.ne.IGX.or.65.ne.IGY) then
> print *,' the dimensions you specified do not agree'
> stop ' grid dimensions inconsistant'
> endif
> 
> stop
> end
> 
> And gives the following output:
> 
> igdfln=  0
> gdattim= 070120/1200f000
> level=  500 -1
> ivcord=  1
> parm= TMPK
> igx=  0
> igy=  0
> ighdr=  0
> iret=  0
> the dimensions you specified do not agree
> 
> Thanks,
> 
> Marty
> 
> _____________________________
> Martin A. Baxter, Ph.D.
> Assistant Professor of Meteorology
> Department of Geography
> Central Michigan University
> Mount Pleasant, MI 48859
> (989) 774-2055
> 
> 
> 
> -----Original Message-----
> From: Unidata GEMPAK Support [mailto:address@hidden]
> Sent: Tue 1/23/2007 2:26 PM
> To: Baxter, Martin A
> Cc: address@hidden
> Subject: [GEMPAK #VNL-434404]: GEMPAK - Using g77 to link to gempak libraries
> 
> Martin,
> 
> Check the iacss (aka iflno) file access number you are passing to the gd_rdat 
> routine.
> You may be stepping on it inadvertantly and the "-4" response is the file 
> number
> is not open.
> 
> Often, Solaris is more tolerant to running past an array bounds due to the way
> memory is positioned, where gcc/g77 shows the problems first.
> 
> Steve Chiswell
> Unidata User Support
> 
> 
> > Institution: Central Michigan University
> > Package Version: 5.9.2
> > Operating System: Linux FC5
> > Hardware Information: Dell 380 Poweredge
> > Inquiry: Hi,
> >
> > Gempak was installed on my system via the binary distribution, which does 
> > not include the libraries. So I downloaded the libraries and attempted to 
> > link to them in my program, with the following:
> >
> > f77 -o qvect.exe $srcdir/qvect.f $srcdir/maplcc.f $GEMLIB/gemlib.a $GEML
> > IB/cgemlib.a -fno-second-underscore
> >
> > The code compiles but doesn't work correctly with respect to the gempak 
> > calls - after I open a file with gd_opnf and read one variable from it with 
> > gd_rdat, the file then "closes" (attempts to read a subsequent variable 
> > give a -4 file not open message. The same code compiles and runs without 
> > this problem with f77 on Sun Solaris. I have tried some other flags I saw 
> > in Makefile.linux, such as -Df2cFortran, but to no avail. Any thoughts?
> >
> >
> >
> >
> 
> 
> Ticket Details
> ===================
> Ticket ID: VNL-434404
> Department: Support GEMPAK
> Priority: Normal
> Status: Closed
> 
> 
> 
> 
> 
> 
> 


Ticket Details
===================
Ticket ID: VNL-434404
Department: Support GEMPAK
Priority: Normal
Status: Closed