- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am trying t use the Fortran95 interface to HEEVR to calculate only the eigenvalues of a matrix (I don't need the eigenvectors). When I use
call heevr(A,w)
it segfaults with
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
When I use
call heevr(A,w,z=U)
it works just fine. I must be missing something stupid, but I cannot see what is wrong.Can somebody tell me what's wrong?
The compiler is gfortran 7.5.0, MKL version is 2018. Here is a full minimum (non-)working example:
program min_heevr_test
use f95_precision, only: wp => dp,sp,dp
use lapack95, only: heevr
implicit none
real(wp) :: w(4),A_re(4,4),A_im(4,4)
complex(wp) :: A(4,4),U(4,4)
! Generate random Hermitian matrices
call random_number(A_re)
call random_number(A_im)
A = cmplx(A_re,A_im,wp)
A = 0.5_wp * (A + transpose(conjg(A)))
! This line causes a segfault
call heevr(A,w)
! This line works
!call heevr(A,w,z=U)
write(*,"(4g12.3)") w
end program min_heevr_test
Thank you in advance!
Arthur
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I compiled, linked and ran your example on Windows using the 19.1.3.311 Intel Fortran compiler and the MKL that came with Parallel Studio 2020 . The output was
-0.970 -0.138 0.542 2.48
Please provide details of compiler options used, the command line used to compile and build, and whether you are generating code for 32-bit or 64-bit OS.
Did you generate the Lapack95 module file for Gfortran yourself? What happens if you comment out the " use lapack95..." line?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I agree with mecej4. We need to know all details.
We built your example on win10,64bit and here is the result: -0.970 -0.138 0.542 2.48
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
and here are the mkl verbose outputs:
MKL_VERBOSE Intel(R) MKL 2020.0 Update 4 Product build 20200917 for Intel(R) 64 architecture Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2) enabled processors, Win 2.60GHz cdecl intel_thread
MKL_VERBOSE ZHEEVR(N,A,U,4,00007FF772766A00,4,0000005C792FF8D0,0000005C792FF8D8,1,4,0000005C792FF8C8,0,00007FF772766B00,0000005C792FF890,1,0000005C792FF8C0,0000005C792FF8B0,-1,0000005C792FF8E0,-1,0000005C792FF910,-1,0) 1.29ms CNR:OFF Dyn:1 FastMM:1 TID:0 NThr:2
MKL_VERBOSE ZHEEVR(N,A,U,4,00007FF772766A00,4,0000005C792FF8D0,0000005C792FF8D8,1,4,0000005C792FF8C8,4,00007FF772766B00,0000005C792FF890,1,0000005C792FF8C0,0000023544AD3F80,8,0000023544ADFD00,96,0000023544ADBF60,40,0) 151.83us CNR:OFF Dyn:1 FastMM:1 TID:0 NThr:2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks both for your help. Here are the details I neglected to include before:
The OS is Ubuntu (buster/sid),
GNU Fortran (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
MKL 2018.2.199
And yes, I built the Lapack95 module myself.
My Makefile for the above example looks like this:
MKLROOT =/opt/intel/mkl
F95ROOT =/opt/intel/mkl/interfaces/lapack95/gfortran
FC = gfortran
FCFLAGS = -m64 -O3 -g \
-I${F95ROOT}/include/intel64/lp64 \
-I${MKLROOT}/include \
-Wall -Wno-maybe-uninitialized -Wno-tabs \
-fcheck=all \
-fopenmp
LDFLAGS = -L${MKLROOT}/lib/intel64
LDLIBS = ${F95ROOT}/lib/intel64/libmkl_lapack95_lp64.a \
-Wl,--no-as-needed -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core \
-lgomp -lpthread -lm -ldl -lz
min_heevr_test: min_heevr_test.o
$(FC) $(FCFLAGS) -o $@ $^ $(LDFLAGS) $(LDLIBS)
min_heevr_test.o: min_heevr_test.f90
$(FC) $(FCFLAGS) -c $^
If I compile with call heevr(A,w,z=U), I get
$./min_heevr_test
MKL_VERBOSE Intel(R) MKL 2018.0 Update 2 Product build 20180127 for Intel(R) 64 architecture Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2) enabled processors, Lnx 3.70GHz lp64 gnu_thread
MKL_VERBOSE ZHEEVR(V,A,U,4,0x7fff881c1e00,4,0x7fff881c1a48,0x7fff881c1a40,1,4,0x7fff881c1aa0,0,0x7fff881c1c60,0x7fff881c1f00,4,0x5583f4f8f8d0,0x7fff881c1990,-1,0x7fff881c19a0,-1,0x7fff881c19ac,-1,0) 20.56ms CNR:OFF Dyn:1 FastMM:1 TID:0 NThr:6
MKL_VERBOSE ZHEEVR(V,A,U,4,0x7fff881c1e00,4,0x7fff881c1a48,0x7fff881c1a40,1,4,0x7fff881c1aa0,4,0x7fff881c1c60,0x7fff881c1f00,4,0x5583f4f8f8d0,0x5583f4fa0bf0,8,0x5583f4fa1990,96,0x5583f4fa18e0,40,0) 181.72us CNR:OFF Dyn:1 FastMM:1 TID:0 NThr:6
-0.566 0.203 0.780 2.28
If I compile with call heevr(A,w), I get
$ ./min_heevr_test
MKL_VERBOSE Intel(R) MKL 2018.0 Update 2 Product build 20180127 for Intel(R) 64 architecture Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2) enabled processors, Lnx 1.90GHz lp64 gnu_thread
MKL_VERBOSE ZHEEVR(N,A,U,4,0x7fff92b2dd00,4,0x7fff92b2d998,0x7fff92b2d990,1,4,0x7fff92b2d9f0,0,0x7fff92b2dbb0,0x7fff92b2da10,1,0x7fff92b2da28,0x7fff92b2d8e0,-1,0x7fff92b2d8f0,-1,0x7fff92b2d8fc,-1,0) 20.71ms CNR:OFF Dyn:1 FastMM:1 TID:0 NThr:6
MKL_VERBOSE ZHEEVR( 191.71us CNR:OFF Dyn:1 FastMM:1 TID:0 NThr:6
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x7f9d1c7ec2ed in ???
#1 0x7f9d1c7eb503 in ???
#2 0x7f9d1b80803f in ???
#3 0x7f9d1b957b80 in ???
#4 0x55f4ce1f677e in ???
#5 0x55f4ce1f5558 in min_heevr_test
at <SNIP>/min_heevr_test.f90:20
#6 0x55f4ce1f4a8e in main
at <SNIP>/min_heevr_test.f90:3
Segmentation fault (core dumped)
If I comment out the USE lapack95 line, the make fails with
min_heevr_test.o: In function `MAIN__':
<SNIP>/min_heevr_test.f90:20: undefined reference to `heevr_'
collect2: error: ld returned 1 exit status
@mecej4 what are you looking for with this test?
I half expected that I was doing something wrong in the way I called HEEVR, so that you have both compiled and run the example already tells me something useful.
Please let me know if I have missed something, or if I can try something else. Or even better, if you have figured out what is wrong!
Thanks,
Arthur
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are a number of issues present that complicate tracking down the error that you encountered. The Netlib version of Lapack95 does not contain the optional argument z=, and the Intel MKL version does; the MKL version does not contain JOBZ as an optional argument, but the Netlib version does. We can infer that the particular sources used for building Lapack95 affect the interface; furthermore, the makefile and compiler options and version may also affect the resulting modules and libraries. Furthermore, different compilers use different RNGs for RANDOM_NUMBER.
Here is a modified version of your example program, which runs without error with the current release of Intel Fortran (19.1.3) and MKL 2020.0.4.
program min_heevr_test
use f95_precision, only: wp => dp,sp,dp
use lapack95, only: heevr
implicit none
real(wp) :: w(4),A_re(4,4),A_im(4,4)
complex(wp) :: A(4,4),U(4,4)
! Generate random Hermitian matrices
call random_number(A_re)
call random_number(A_im)
A = cmplx(A_re,A_im,wp)
A = 0.5_wp * (A + transpose(conjg(A)))
U = A ! U is not used in first call, so use it to save A
call heevr(A,w)
write(*,"(1x,A17,4g12.3)") '(A,w) : ',w
!restore A
A = U
call heevr(A,w,z=U)
write(*,"(1x,A17,4g12.3)") "(A,w,z=U) : ",w
write(*,"(1x,A4,/,4(4(2F7.3,2x),/))") 'U = ',transpose(U)
end program min_heevr_test
Compiling and running:
S:\LANG\MKL>ifort /Qmkl xheevr.f90 mkl_lapack95_lp64.lib
...
S:\LANG\MKL>xheevr
(A,w) : -0.970 -0.138 0.542 2.48
(A,w,z=U) : -0.970 -0.138 0.542 2.48
U =
0.226 -0.550 -0.541 0.082 0.089 -0.489 -0.317 -0.008
-0.130 0.327 -0.444 0.244 0.159 0.505 -0.577 0.078
-0.542 -0.058 0.388 -0.263 0.441 -0.283 -0.453 -0.045
0.474 0.000 0.474 0.000 -0.445 0.000 -0.594 0.000
Thus, the two calls are fine when the Intel compiler and prebuilt Lapack95 are used (on Windows, at least).
If you state how you built Lapack95 and identify the version of the sources used, someone may investigate further. Otherwise, there appears to be no error as far as this particular example is concerned.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For a second approach, I built a Lapack95+Blas95 library using the sources that come with MKL, in the interfaces/blas95/source and interfaces/lapack95/source directories. I built on Windows 10 x64, using Cygwin64 and Gfortran 10. Rather than wrestle with the makefile, I simply compiled all the sources using -c -O, and created liblapack95.a using ar.
Using the library now built, I compiled the example that I gave with the command
gfortran -I. awm.f90 -L. -llapack95 -llapack -lblas
The resulting EXE ran normally and the output was similar to that in my preceding post.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your help. I now have the problem fixed.
As a first step, I tried downloading and installing a newer version of the MKL (OneAPI 2021.1.1). I built the lapack95 interface using the provided makefile, and then my code compiled and ran exactly as I expected it to.
I then went back and rebuilt the lapack95 interface for the old version (2018.2.199) using the makefile from Intel as:
/opt/intel/mkl/interfaces/lapack95$ sudo make libintel64 INSTALL_DIR=./gfortran interface=lp64 FC=gfortran
And now my example compiles and runs just fine there too. It's not a very satisfying answer, but at least it runs! I suspect I may have updated gfortran as part of an apt-update, and not rebuild the interface. The main clue I needed was that you could compile it, so it was an installation problem rather than a programmer-not-understanding-the-interface problem.
Thanks again,
Arthur
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ok, the issue is closed.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page