Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
7111 Discussions

HEEVR to calculate eigenvalues only (Fortran95)

AWMagill
Novice
1,764 Views

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

0 Kudos
8 Replies
mecej4
Honored Contributor III
1,739 Views

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?

Gennady_F_Intel
Moderator
1,728 Views

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

 

Gennady_F_Intel
Moderator
1,726 Views

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

AWMagill
Novice
1,714 Views

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

 

0 Kudos
mecej4
Honored Contributor III
1,701 Views

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.

mecej4
Honored Contributor III
1,691 Views

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. 

AWMagill
Novice
1,673 Views

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

0 Kudos
Gennady_F_Intel
Moderator
1,669 Views

ok, the issue is closed.


0 Kudos
Reply