There is a problem when I use the mpif90 compiler that complains that 'bad value during integer read'. However, when I use the gfortran compiler, there is no problem.
The gfortran version is
program main
implicit none
character*100 :: line
integer :: ierr, i
open(10, file="test.txt", action="read")
read(10, '(A)' ,iostat=ierr) line
read(line, "(6X, I5)") i
print*, i
end program
The mpif90 version is
program main
implicit none
include "mpif.h"
character*100 :: line
integer :: ierr, i, procID
call mpi_init(ierr)
call mpi_comm_rank(mpi_comm_world,procID,ierr)
if (procID==0) then
open(10, file="test.txt", action="read")
read(10, '(A)' ,iostat=ierr) line
read(line, "(6X, I5)") i
print*, i
endif
call mpi_finalize(ierr)
endprogram
the test.txt file contains that
TEST 1
The gfortran version gives correct answer 1
mpif90 version uses mpif90 compiler to compile the program and use mpirun -n 4 ./a.out to run the program the outcome is
At line 12 of file read.f90
Fortran runtime error: Bad value during integer read
Why there is such a problem? Can anyone fix this?
Related
This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it in Fortran?
(5 answers)
Fortran 90 compiling issue: undefined reference to <modulename>
(1 answer)
Closed 1 year ago.
I am trying to write two simple functions, one which contains the definition of a real function and the other one uses the previous function to find its derivative. However i keep getting the undefined reference error.
my module:
module module_name
contains
function f(x)
implicit none
real(8) :: x
real(8) :: f
f= 2.71**x
endfunction
function f_p_def(x)
implicit none
real(8) :: x, dx, f
real(8) :: f_p_def
dx= 0.1
f_p_def= (f(x+dx)-f(x))/dx
endfunction
endmodule
then in my main program I have this:
program test
use module_name
real(8) :: f1, x
x=0
f1= f_p_def(x)
write(*,*) f1
endprogram
and this is the error:
.\principal.o:principal.f95:(.text+0x27): undefined reference to `__module_name_MOD_f_p_def'
collect2.exe: error: ld returned 1 exit status
Seems like you have your module defined in a separate file. This means that when producing the final executable you must add the object file as well.
EDIT To clarify, you need to compile each source file, producing an object file. Then at the end you link them together. The compiler driver program (gfortran in this case) can run the linker for you automatically.
Separating out all these steps, you need to do something like:
gfortran -O2 -g -fcheck=all -c principal.f95
gfortran -O2 -g -fcheck=all -c module_name.f95
gfortran -O2 -g -fcheck=all principal.o module_name.o -o myprogram
./myprogram
where module_name.f95 is the name of the file where module_name is defined. If not, modify appropriately. In the above, the first two commands compile the source files, producing object files. The third command doesn't actually compile anything, but rather links together your two object files, producing the executable. Then the final command executes the executable.
Consider the following code.
! test.f90
program test
use iso_fortran_env, only: INT64, REAL64
print *, real(0_INT64, REAL64)
print *, real(1000_INT64, REAL64)
print *, real(huge(0_INT64), REAL64)
end program test
When compiling it with gfortran in the following way:
$ gfortran -Wconversion -std=f2008 test.f90
I got the following warning:
test.f90:5:18:
5 | print *, real(huge(0_INT64), REAL64)
| 1
Warning: Change of value in conversion from ‘INTEGER(8)’ to ‘REAL(8)’ at (1) [-Wconversion]
Note that gfortran is happy with the first two conversions, but not the last one.
Question: Is the warning illustrated above an expected behavior of gfortran? I thought that NO warning should be produced in any of the three cases, since the conversion is done explicitly by REAL( , INT64).
Here is the version information of my gfortran:
$ gfortran --version
GNU Fortran (Ubuntu 9.3.0-10ubuntu2) 9.3.0
As a reference, ifort 19.1.127 compiles test.f90 without any complaint:
$ ifort -warn all -stand f08 test.f90
Thank you very much for any comments or critics.
Answer by #dave_thompson_085 in the comments:
“0 and 1000 can be represented exactly in REAL64 (and even in REAL32). HUGE(INT64) is 9223372036854775807 and it cannot. REAL64 has 53 bits for the 'mantissa' (really, significand), and after subtracting the sign and adding the hidden bit this supports just under 16 decimal digits of magnitude. 9223372036854775807 is 19 decimal digits. This is not a diagnostic required by the standard, so it's up to each 'processor' (compiler) what to do about it.”
Thank you very much, #dave_thompson_085.
I'm newbie to MPI. I try to test MPI with simple Hello_world code. I compiled the code with mpifort -c ../main.f95 -g -w -I/opt/openmpi4.0.1/include. The output file is test1.
When i used mpirun np -4 ./test1, it gave an error "mpirun: symbol lookup error: mpirun: undefined symbol: opal_libevent2022_event_base_loop
". Could you please figure out what is wrong with mpirun.
program hello
include 'mpif.h'
integer rank, size, ierror, tag, status(MPI_STATUS_SIZE)
call MPI_INIT(ierror)
call MPI_COMM_SIZE(MPI_COMM_WORLD, size, ierror)
call MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierror)
print*, 'node', rank, ': Hello world'
call MPI_FINALIZE(ierror)
end
I am learning how to call fftw from fortran. My test program is the following:
Program Single_Thread_FFTW
use, intrinsic :: iso_c_binding
implicit none
integer, parameter :: N=16
type (c_ptr) :: plan_forward
integer :: k
complex (kind=8) :: in(N), out(N)
include 'fftw3.f03'
in=(/(sin(3.14159d0*k),k=1,N)/)
print *,in
plan_forward=fftw_plan_dft_1d(N,in,out,FFTW_FORWARD,FFTW_ESTIMATE)
call fftw_execute_dft(plan_forward,in,out)
print *,out
call fftw_destroy_plan(plan_forward)
End Program Single_Thread_FFTW
The first confusion came about because the fftw website suggests all the fftw call should be prefaced with the letter d, as in 'dfftw_plan_dft_1d'. However none of the functions/subroutines in fftw3.f03 (located in /usr/include) have the d prefix. When I try to compile/link with either
gfortran -I/usr/include -o example1 example1.f90 or
gfortran -I/usr/include -L/usr/lib/x86_64-linux-gnu -o example1 example1.f90
the linker throws the errors:
example1.f90:(.text+0xf3): undefined reference to `fftw_plan_dft_1d'
example1.f90:(.text+0x114): undefined reference to `fftw_execute_dft'
example1.f90:(.text+0x1cc): undefined reference to `fftw_destroy_plan'
even though the libraries are in /usr/lib/x86_64-linux-gnu. A separate point is that I would like to lear how to declare double precision complex variables without using the (kind=8) modifier. My compiler (gfortran) doesnt know about double complex.
I am building some unit tests and find that my code gives a slightly different result when vectorized. In my example case below, an array a is summed in one dimension and added to an initial value x. Most elements of a are too small to change x. The code is:
module datamod
use ISO_FORTRAN_ENV, only : dp => REAL64
implicit none
! -- Array dimensions are large enough for gfortran to vectorize
integer, parameter :: N = 6
integer, parameter :: M = 10
real(dp) :: x(N), a(N,M)
contains
subroutine init_ax
! -- Set a and x so the issue manifests
x = 0.
x(1) = 0.1e+03_dp
a = 0.
! -- Each negative component is too small to individually change x(1)
! -- But the positive component is just big enough
a( 1, 1) = -0.4e-14_dp
a( 1, 2) = -0.4e-14_dp
a( 1, 3) = -0.4e-14_dp
a( 1, 4) = 0.8e-14_dp
a( 1, 5) = -0.4e-14_dp
end subroutine init_ax
end module datamod
program main
use datamod, only : a, x, N, M, init_ax
implicit none
integer :: i, j
call init_ax
! -- The loop in question
do i=1,N
do j=1,M
x(i) = x(i) + a(i,j)
enddo
enddo
write(*,'(a,e26.18)') 'x(1) is: ', x(1)
end program main
The code gives the following results in gfortran without and with loop vectorization. Note that ftree-vectorize is included in -O3, so the problem manifests when using -O3 also.
mach5% gfortran -O2 main.f90 && ./a.out
x(1) is: 0.100000000000000014E+03
mach5% gfortran -O2 -ftree-vectorize main.f90 && ./a.out
x(1) is: 0.999999999999999858E+02
I know that certain compiler options can change the answer, such as -fassociative-math. However, none of those are included in the standard -O3 optimization package according to the gcc optimization options page.
It seems to me as though the vectorized code is adding up all components of a first, and then adding to x. However, this is incorrect because the code as written requires each component of a to be added to x.
What is going on here? May loop vectorization change the answer in some cases? Gfortran versions 4.7 and 5.3 had the same problem, but Intel 16.0 and PGI 15.10 did not.
I copied the code you provided (to a file called test.f90) and then I compiled and ran it using version 4.8.5 of gfortran. I found that results from the -O2 and -O2 -ftree-vectorize options differ just as your results differ. However, when I simply used -O3, I found that the results matched -O2.
$ gfortran --version
GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
Copyright (C) 2015 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
$ gfortran -O2 test.f90 && ./a.out
x(1) is: 0.100000000000000014E+03
$ gfortran -O2 -ftree-vectorize test.f90 && ./a.out
x(1) is: 0.999999999999999858E+02
$ gfortran -O3 test.f90 && ./a.out
x(1) is: 0.100000000000000014E+03