So I've been avoiding Fortran like the plague, but finally my time has come... I need to take part of someone else's Fortran code (let's call it program A) and do two things with it:
(1) Merge it with a third person's Fortran code (let's call it program B) so that B can call A
(2) Merge it with my C++ code (program C) so that C can call A
B and C are optimization algorithms, and A is a collection of benchmark functions... But before all that awesomeness can happen, I must first compile the portion of A that I need. All the subroutines of A that I need are contained in one file. I've been getting it into shape based on information I got online (e.g. adding "IMPLICIT NONE" to the code and making it suitable for gfortran). But I've got two stubborn bugs and a warning (I'll leave the warning for another post).
Here's how I am currently compiling it (via a Makefile):
all:
gfortran progA.FOR
g++ -c progC.cpp
g++ -o Program.out progA.o progC.o
rm *.o
But the first line fails to complete with the following errors,
FIRST ERROR:
SUBROUTINE TP1(MODE)
1
Error: Unclassifiable statement at (1)
RELEVANT CODE (starting from the top of the file):
IMPLICIT NONE
INTEGER NMAX,MMAX,LMAX,MNNMAX,LWA,LIWA,LACTIV,N,NILI,NINL,
/ NELI,NENL,NEX, MODE
PARAMETER (NMAX = 101,
/ MMAX = 50,
/ LMAX = 50,
/ MNNMAX = NMAX + NMAX + MMAX + 2,
/ LWA = 2*NMAX*NMAX + 33*NMAX + 10*MMAX + 200,
/ LIWA = MMAX + NMAX + 150,
/ LACTIV = 2*MMAX + 15)
LOGICAL INDEX1,INDEX2
SUBROUTINE TP1(MODE)
COMMON/L1/N,NILI,NINL,NELI,NENL
COMMON/L2/X(2)
COMMON/L4/GF(2)
COMMON/L6/FX
COMMON/L9/INDEX1
COMMON/L10/INDEX2
COMMON/L11/LXL
COMMON/L12/LXU
COMMON/L13/XL(2)
COMMON/L20/LEX,NEX,FEX,XEX(2)
REAL*8 X,G,GF,GG,FX,XL,XU,FEX,XEX
LOGICAL LXL(2),LXU(2),LEX
GOTO (1,2,3,4,4),MODE
1 N=2
NILI=0
NINL=0
NELI=0
NENL=0
X(1)=-2.D0
X(2)=1.D0
LXL(1)=.FALSE.
LXL(2)=.TRUE.
LXU(1)=.FALSE.
LXU(2)=.FALSE.
XL(2)=-1.5D0
LEX=.TRUE.
NEX=1
XEX(1)=1.D0
XEX(2)=1.D0
FEX=0.D0
RETURN
2 FX=100.D0*(X(2)-X(1)**2)**2+(1.D0-X(1))**2
RETURN
3 GF(2)=200.D0*(X(2)-X(1)**2)
GF(1)=-2.D0*(X(1)*(GF(2)-1.D0)+1.D0)
4 RETURN
END
I do not understand why this error appears since there are over 300 other subroutines declared exactly the same way (e.g. SUBROUTINE TP2(MODE), ..., SUBROUTINE TP300(MODE) ).
SECOND ERROR:
HX=TP273A(X)
1
Error: Return type mismatch of function 'tp273a' at (1) (REAL(4)/REAL(8))
RELEVANT CODE:
SUBROUTINE TP273(MODE)
COMMON/L1/N,NILI,NIML,NELI,NENL
COMMON/L2/X
COMMON/L4/GF
COMMON/L6/FX
COMMON/L11/LXL
COMMON/L12/LXU
COMMON/L20/LEX,NEX,FEX,XEX
LOGICAL LEX,LXL(6),LXU(6)
REAL*8 X(6),FX,GF(6),FEX,XEX(6),HX,DFLOAT
GOTO (1,2,3,4,4)MODE
1 N=6
NILI=0
NINL=0
NELI=0
NENL=0
DO 6 I=1,6
X(I)=0.D+0
XEX(I)=0.1D+1
LXL(I)=.FALSE.
6 LXU(I)=.FALSE.
LEX=.TRUE.
NEX=1
FEX=0.D+0
RETURN
2 HX=TP273A(X)
FX=0.1D+2*HX*(0.1D+1+HX)
RETURN
3 HX=TP273A(X)
DO 7 I=1,6
7 GF(I)=0.2D+2*(0.16D+2-DFLOAT(I))*(X(I)-0.1D+1)
1 *(0.1D+1+0.2D+1*HX)
4 RETURN
END
REAL*8 FUNCTION TP273A (X)
REAL*8 X(6),DFLOAT
TP273A=0
DO 10 I=1,6
10 TP273A=TP273A+(0.16D+2-DFLOAT(I))*(X(I)-0.1D+1)**2
RETURN
END
After reading Physics Forums I tried renaming the variable "TP273A" to "TP273Avar" so that it would not have the same name as the function. This did not resolve the error. Also, I replaced the "1" with "F" just below "7 GF(I) = ..." and recompiled. Nothing changed. I'm pretty sure the changes I just mentioned are necessary anyway, but there must be something else going on.
I have also read Data type mismatch in fortran and Function return type mismatch, so I naively tried adding "module mycode" to the top and "end module mycode" to the bottom of the file to no avail.
After this is all said and done, my goal is to call these subroutines from C++ using a code similar to:
#include <kitchensink>
extern"C"
{
void TP1_(int *mode);
}
int main()
{
TP1_(2);
return 0;
}
Once the Fortran Code compiles, I want to modify the subroutines so that C++ can pass std::vector X to TP#_(2,*X,*Y) and get back the computed value for Y. My std::vector X will replace COMMON/L2 X in each of the subroutines, and Y will be the value of FX computed in the subroutines. I used Mixing Fortran and C as guidance for the above C++ code.
As for the B calls A part, I hope that it will be as simple as compiling A along with B, and adding "CALL TP1(MODE)" lines wherever I need them.
Any and all guidance will be greatly appreciated!!!
You cannot have statements just in a file outside of a compilation unit. These can be subroutines, functions, modules or programs. In your case you have some statements( first of them being implicit none) and only after them there is the beginning of the subroutine TP1.
Either organize the procedures in a module and leave the common part before the contains section (more work with the C++ interoperability will follow if you are a Fortran newbie) or you must include the implicit none and others in every subroutine separately. Are you sure you even need this if the code worked before?
Related
I need a special library for Fortran so that I can code and visualize on the fly, instead of writing to a text file then use either Python or Matlab to plot. I followed this:
https://people.sc.fsu.edu/~jburkardt/f_src/gnufor/gnufor.html
The instructions are not cleared so I did not use their examples, so I wrote my own code. There are 2 files: gnu.f90 from website, and myplot.f90, which I wrote like this:
program myplot
!Declare data types
implicit none
integer, parameter :: N1 = 50
real(kind=8) :: x1(N1),x2(N1)
real(kind=8) :: y1(N1)
real(kind=8) :: y2(N1)
integer :: i
!Generate 2D plot
do i = 1,N1
x1(i) = i
x2(i) = i
end do
y1 = x1**2
y2 = x2**3
!print *, 'Plotting'
!call plot(x1,y1,x2,y2)
call write_xy_data(x1,y1)
end program myplot
Apparently, from their gnufor.f90 file, I only need to do:
write_xy_data(X,Y) and it should work. In their example code, they did not use gnufor.f90 as a module so I didnt put: use gnufor at the beginning. Although, I tried that and it didn't work as well. So in my current directory, I have:
gnufor.90
myplot.f90
And to compile it, I am on Linux: gfortran myplot.f90 -o test
The error was:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x7FB0B051DE08
#1 0x7FB0B051CF90
#2 0x7FB0AFF574AF
#3 0x40302F in write_xy_data_
#4 0x400D7E in MAIN__ at myplot.f90:?
Segmentation fault (core dumped)
Any help is greatly appreciated. I expected the problem to be in my own code, although all array sizes are declared.
The subroutine write_xy_data in gnufor.f90 from the website you linked has a signature
subroutine write_xy_data(data_filename, n, x, y, ierror)
implicit none
character ( len = * ) data_filename
integer ( kind = 4 ) n
real ( kind = 8 ) x(n)
real ( kind = 8 ) y(n)
integer(kind = 4) ierror
Which means instead of passing only x,y, you have to call it as
call write_xy_data('myfile',N1,x1,y1,ierr)
passing as arguments the name of the file to write to ('myfile' in the example), the number of points to write (N1), the data (x1,y1) and an integer that carries information on the success of the write (ierror, this one has to be declared, too)
Also, there is no module gnufor, so no use clause is required, all functions in gnufor.F90 are global, which is also the reason why you need to pass the number of points as an extra argument, as assumed shape would require an explicit interface.
I am new to Fortran, writing some practice code with a function that returns Farenheit from Celsius
program Console1
implicit none
real, parameter :: ikind = selected_real_kind(p=15)
real (kind = ikind):: c,f,o,faren
print *, "enter a temperature in degrees celsius"
read *, c
write(*,10) "farenheit =", faren(c)
10 format(a,f10.8)
end program Console1
function faren(c)
real, parameter :: ikind = selected_real_kind(p=15)
real (kind = ikind):: c,f
faren = (9/5)*c + 32
end function faren
I get an error #7977 : The type of the function reference does not match the type of the function definition.
So with that if i change function faren(c) to real function faren(c)
I get the same error, but the types are the same?
Am i missing something? Do I have to define the function in the main program?
There are several issues in addition to the structural/code arrangement ones already noted.
First, KIND is an integer, so you want to change
real, parameter :: ikind = selected_real_kind(p=15)
to
integer, parameter :: ikind = selected_real_kind(p=15)
Ideally, you want to define that in only one place (i.e. in a module) and reference it from both your main program and the function, but the code should be fine as it is for test purposes.
A second issue that often trips up newcomers to Fortran (and Python2) is that real numbers and integers are distinct types and are not generally interchangeable.
faren = (9/5)*c + 32
simplifies to
faren = (1)*c + 32
because integer division has an integer result; 9/5 = 1
Fortran is picky about numerical values (that's sort of the whole point of the language) so what you probably want is:
faren = (9.0 / 5.0) * c + 32.0
Or more precisely, if faren is defined with a specific precision of ikind,
faren = (real(9.0,ikind) / real_(5.0,ikind)) * c + real(32.0,ikind)
or
faren = (9.0_ikind / 5.0_ikind) * c + 32.0_ikind
This syntax tends to make people's heads explode. Welcome to modern fortran ;)
The last issue deals with the horrors of Fortran I/O. From a design standpoint, you need to know what results the user expects and make sure the output format can display them. The legitimate range of input values for c is -273.15 (give or take) to some upper bound which relies on the use case for the code. If you're dealing with cooking temperatures, you probably won't exceed 400.0; if you're doing fusion research, you could be going much higher. Are 8 figures past the decimal useful or believable? In this case, we're just testing the code so we may not need a lot of precision in the output; you'll want to change the output format to something like:
10 format(a,es10.2)
or
10 format(a,g16.8)
You need to ensure the total field width (the number before the dot) can contain the decimal part (the number after the dot) along with the integer part of the number, plus the space needed to show sign and exponent. For scientific notation, four characters are eaten by mantissa sign, decimal point, 'E' and exponent sign. It may be safer just starting out to use an output format of *; it's frustrating to fight with numerics and formatting simultaneously.
That is a good effort and simple start to work through the nuance, so a good question.
Personally I would use reals for the math, rather the 9/5, and use a module. In this example you could pass in a real or a double to C2Faren and the interface/procedure will sort out whether to use the real or the double version. Then you have a few options in case you want different precision.
You could also use the ISO_C_BINDING if you do mixed language...
MODULE MyTEMPS
PRIVATE
DOUBLE PRECISION, PARAMETER :: C2F_ScaleFact = 1.8D0
DOUBLE PRECISION, PARAMETER :: F2C_ScaleFact = /(1.0D0 / 1.8D0)/
DOUBLE PRECISION, PARAMETER :: F2C_Offset = 32.0D0
PUBLIC Faren2C
INTERFACE C2Faren
MODULE PROCEDURE C2Faren_Real, C2Faren_DBL
END INTERFACE
CONTAINS
!========= REAL VERISON =========
REAL FUNCTION C2Faren_Real(c)
IMPLICIT NONE
real, INTENT(IN ) :: c
C2Faren_Real = ( C*F2C_ScaleFact ) + F2C_Offset
RETURN
END FUNCTION C2Faren_Real
!========= DOUBLE VERSION =========
DOUBLE PRECISION FUNCTION C2Faren_DBL(c)
IMPLICIT NONE
DOUBLE PRECISION , INTENT(IN ) :: c
C2Faren_DBL = ( C*F2C_ScaleFact ) + F2C_Offset
RETURN
END FUNCTION C2Faren_DBL
!========= REAL VERSION (Faren to Centigrade) =========
REAL FUNCTION faren2C(Faren)
IMPLICIT NONE
REAL, INTENT(IN ) :: Faren
faren2C = (faren - F2C_Offset) / F2C_ScaleFact
RETURN
END FUNCTION faren2C
END MODULE MyTEMPS
Then your program uses the module via USE n the second line...
program Console1
USE MyTEMPS !<== Here
implicit none
real :: c, f
DOUBLE PRECISION :: Dc, Df ! No way to get Df to C or DC in the module (yet)!
print *, "enter a temperature in degrees celsius"
read *, c
write(*,10) "farenheit =", C2faren(c)
10 format(a,f10.6)
Dc = C
write(*,12) "farenheit =", C2faren(Dc)
12 format("DBL:",A,f10.6)
F = Dc
write(*,14) "Centigrade =", faren2C(F)
14 format("DBL:",A,f10.6)
end program Console1
So/and the main advantage of the module is when you end up wanting to use this stuff in a variety of programs and test and sort out the module once... Usually people put this sort of stuff (lots of modules) in a library, when the module(s) have lot of functions.
You could also put just the real, parameter :: ikind = selected_real_kind(p=15) into a module and use that in both the program and the function and you would be there. You were real close, and it mostly a matter of style and utility.
For Intel Fortran you can use REAL(KIND=4) and REAL(KIND=8)... Which I do, but that is not portable to gfortran, so it is probably a better habit to use the ISO_C_BINDING or just use REAL and DOUBLE PRECISION.
Modules are great but if you have a very simple code another way to work is to put the subroutines and functions in your main program. The trick is to put them after the word contains:
program xxx
stuff
contains
subroutine yyy
function zzz
end program xxx
In this way the functions can see into the contents of the main program so you don't have to re-declare your parameters and you are likely to get more meaningful error messages.
Since you are new I have a great resource I learned a lot from to share:
http://www.uv.es/dogarcar/man/IntrFortran90.pdf
Here's a part of my fortran code after compiling gives me an error saying that 'icount at (1) is not a variable
Here goes my code:
integer*4 iy1
integer*2 id1,im1
parameter (month=12,maxper=5,specmax=8)
real conc(month,8,icount(8,month))
integer smonth(12),icount(8,month)
real per(maxper),rper(maxper)
data smonth/12,1,2,3,4,5,6,7,8,9,10,11/
data per/0.10,0.25,0.5,0.75,0.90/
open(unit=1`,file='data_co.txt',status='old')
open(unit=2,file='chennai_alldatatop10.txt',status='unknown',iostat=ierr)
if(ierr.eq.0)close(2,status='delete')
open(unit=2, file='chennai_alldatatop10.txt',status='unknown')
inum=0
2 read(2,*,end=3)id1,im1,iy1,conc1
icount(1,im1)=inum+1
conc(im1,1,icount(1,im1))=conc1
goto 2
3 continue
end
In your variable declarations at the top of your code, you switched the order:
real conc(month,8,icount(8,month))
integer smonth(12),icount(8,month)
You are using icount before you defined it, so your code should look like this:
integer smonth(12),icount(8,month)
real conc(month,8,icount(8,month))
But actually, this doesn't make any sense either, if icount(8, month) has not yet been initialized to a value. So your code should look like this:
integer smonth(12), icount(8,month)
real conc(month, 8, some_scalar_value)
Why am I in an infinite loop?
PROGRAM tayls
USE kertoma
USE tforexp
IMPLICIT NONE
INTEGER :: n= 5
INTEGER :: i
REAL :: x
WRITE(*,*) "f1(x)= (e**x-1)/x"
DO i=1,10
x= 0.01*i
WRITE(*,*)x, (taylexp(x,n)-1)/x
END DO
END PROGRAM tayls
with
MODULE tforexp
USE kertoma
IMPLICIT NONE
CONTAINS
FUNCTION taylexp(x,ord)
REAL :: taylexp, x, sum
INTEGER :: ord, i
sum= 1.0
DO i=1,ord
sum= sum+ x**i/fact(i)
END DO
taylexp= sum
END FUNCTION taylexp
END MODULE tforexp
and
MODULE kertoma
IMPLICIT NONE
CONTAINS
FUNCTION fact(n)
INTEGER :: fact,n,y=1
DO WHILE (n>1)
y= y*n
n= n-1
END DO
fact = y
END FUNCTION fact
END MODULE kertoma
The infinite loop starts right after the first print "f1(x)=...".
So I think it goes to infinite loop when calling the taylexp-function for the first time, but I don't understand why.
I think it has got something to do with fortran using public variables, but I'm clueless how to consistently avoid this.
First I tried to call the function without defining x, just using "0.01*i", and I thought maybe the problem was that this function used the same name for the dummy index, but it clearly it didn't solve the problem.
The problem is inside then function fact(n):
n= n-1
changes the argument and, therefore, the loop counter i in taylexp. In your code i never exceeds 2. I'm surprised the compiler didn't issue a warning (mine didn't either), because anything might happen in this case.
Better specify the intent of dummy arguments to avoid issues like this in the future:
FUNCTION fact(n)
integer,intent(in) :: n
INTEGER :: fact,nn,y
y=1 ! Avoid the implicit save and assign variables separately
nn=n
DO WHILE (nn>1)
y= y*nn
nn= nn-1
END DO
fact = y
END FUNCTION fact
With gfortran, it is possible to catch this error with
the -fcheck=all option:
$ gfortran -fcheck=all 1.f90
$ ./a.out
f1(x)= (e**x-1)/x
At line 22 of file 1.f90
Fortran runtime error: Loop variable has been modified
There is a F77 code, slightly modified from me. The code calls a particular routine, but it seems that compilation does not stop (and I believe there is no problem with loops). This makes me wonder why this might happen.
Second i cannot really understand what the output of that routine will be. Can anyone help here?
this is the section of the code that calls the routine/function. By working a MWE,
integer, parameter:: nf=101, ns=7, nas=427, na=61, nxm=3
integer:: i,j,k,
allocate(xf(nf), xa(na))
allocate(absa(nxm,na-1), wgta(nxm,na-1),absf(nxm,nf-1), wgtf(nxm,nf-1))
do 150 i=1,na-1
call qgausl (nxp(i), xa(i), xa(i+1), absa(1,i), wgta(1,i))
150 continue
do 160 i=1,nf-1
call qgausl (nxp(i), xf(i), xf(i+1), absf(1,i), wgtf(1,i))
160 continue
And this is the routine
subroutine qgausl(n,x1,x2,x,w)
implicit none
integer:: n, m
real*8:: xl,x2, x1, xm, eps, z, p1,p2,p3, pp, z1
real*8:: x(n), w(n)
eps=1.0e-8
m=(n+1)/2
xm=0.5*(x2+x1)
xl=0.5*(x2-x1)
do 12 i=1,m
z = cos(3.141592654*(i-.25)/(n+.5))
1 continue
print*, z
p1 = 1.0
p2 = 0.0
do 11 j=1,n
p3 = p2
p2 = p1
p1 = ((2.0*j-1.0)*z*p2-(j-1.0)*p3)/j
11 continue
pp = n*(z*p1-p2)/(z*z-1.0)
z1 = z
z = z1-p1/pp
if (dabs(z-z1).gt.eps) go to 1
x(i) = xm-xl*z
x(n+1-i) = xm+xl*z
w(i) = 2.0*xl/((1.0-z*z)*pp*pp)
w(n+1-i) = w(i)
12 continue
return
end subroutine
For your information and if I made a good job, i translated this into Matlab and seems that there is no problem with the loops in the routine.
A bit of an extended comment:
One thing I notice is you tagged this as fortran77 but in fact it will not compile if this is indeed an f77-type external subroutine (ie. not in a module/contains construct) because you use implicit none but fail to declare i in the subroutine.
( There are numerous other post-f77 syntax features in there as well. )
So...assuming this subroutine is internal (ie. lives within contains in the calling routine) the i here :
do 12 i=1,m
is the same i from the scope of the calling routine, ie. you are effectively using the same variable for two nested loops.
This is obviously an illegal thing to do, and I must say I'm disturbed to see that gfortran silently compiles such and runs off in an endless loop.. (!?!)
I'd suggest moving the subroutine to a module or simply making it external if you think this is the case. Then the compiler will flag your failure to declare i
example
both gfortran and ifort compile this without warnings:
implicit none
integer j
do j = 1,2
call x()
enddo
contains
subroutine x()
implicit none
do j=3,4
write(*,*)j
enddo
end subroutine
end
the gfortran version runs away endlessly printing 3,4,3,4. The intel version writes 3,4 just once (ie not what you might expect either)
declaring j in the subroutine fixes it of course..