Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Intel Community
- Software
- Software Development SDKs and Libraries
- Intel® oneAPI Math Kernel Library
- Cannot use MKL F95 eigensolver routines

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

chung__kristian

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-16-2019
05:50 PM

223 Views

Cannot use MKL F95 eigensolver routines

I am using Intel Parallel Studio XE with Visual Studio. I would like to use the heev()/heevr() routines. I have written a simple code to test it, and I have enabled the "Use MKL libraries" option in Project Properties:

include 'lapack.f90' program heev_test use lapack95 implicit none integer , parameter :: dp = kind(0.0d0) complex(dp) :: matrix(4,4) real(dp) :: eigs(4) integer :: i matrix = (1.0_dp,0.0_dp) call heevr(matrix, eigs, info=i) print*, i print*, eigs read(*,*) stop end program

This code produces the error:

error LNK2019: unresolved external symbol _ZHEEVR_F95 referenced in function _MAIN__ fatal error LNK1120: 1 unresolved externals

So the linker is not finding the ZHEEVR_F95 subroutine whose interface is provided in the lapack.f90 file. Replacing HEEVR with HEEV produces the same results. I should say that I am also using the VSL and DFT libraries without any issue.

I noticed in the documentation for ?heev it says to include the mkl.fi file (which I don't normally include for the VSL or DFT libraries), but doing so produces the following errors:

Error error #6218: This statement is positioned incorrectly and/or has syntax errors. C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\\mkl\include\lapack.f90 21 Error error #6790: This is an invalid statement; an END [PROGRAM] statement is required. C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\\mkl\include\lapack.f90 24 Error error #6785: This name does not match the unit name. [F95_PRECISION] C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\\mkl\include\lapack.f90 24 Error Compilation Aborted (code 1) Warning warning #5427: Program may contain only one main entry routine

The line numbers are referring to these lines from the lapack.f90 file:

21 MODULE F95_PRECISION 22 INTEGER, PARAMETER :: SP = KIND(1.0E0) 23 INTEGER, PARAMETER :: DP = KIND(1.0D0) 24 END MODULE F95_PRECISION

which doesn't really tell me much.

I need to figure out why the linker can't find the f95 subroutines, any help appreciated.

EDIT:

I tried using the F77 interface with the following code:

include 'lapack.f90' program heev_test use lapack95 implicit none integer , parameter :: dp = kind(0.0d0) complex(dp) :: matrix(4,4) real(dp) :: eigs(4) integer :: i matrix = (1.0_dp,0.0_dp) call eigenvalues(matrix,eigs) print*, eigs read(*,*) stop contains subroutine eigenvalues(H,eigs) complex(dp) :: H(:,:) real(dp) :: eigs(:) integer :: d integer :: info integer :: lwork, liwork real(dp), allocatable :: work(:) integer , allocatable :: iwork(:) d = size(eigs) lwork = 4*d liwork = 10 allocate(work(lwork)) allocate(iwork(liwork)) call zheevr('N','U',d,H,d,eigs,work,-1,iwork,-1,info) lwork = work(1) liwork = iwork(1) deallocate(work,iwork) allocate(work(lwork)) allocate(iwork(liwork)) call zheevr('N','U',d,H,d,eigs,work,lwork,iwork,liwork,info) deallocate(work,iwork) if (info /= 0) then print*, "diagonalization failed, info = ", info read(*,*) stop end if end subroutine end program

but this causes a seg fault as soon as zheevr is called, and now I have absolutely no idea what is going on.

Link Copied

6 Replies

mecej4

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-16-2019
07:47 PM

223 Views

Take your first (shortest) code. The missing external routine is to be found in the Lapack95 library for the architecture that you are targeting. If, for example, you are targeting X64 and using 4-byte integer arguments to MKL routines, the command to compile and link is:

ifort /Qmkl xheevr.f90 mkl_lapack95_lp64.lib

For other combinations, etc., a good tool to use is the MKL Link Line Advisor, see https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor .

chung__kristian

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-18-2019
11:14 AM

223 Views

mecej4 wrote:Take your first (shortest) code. The missing external routine is to be found in the Lapack95 library for the architecture that you are targeting. If, for example, you are targeting X64 and using 4-byte integer arguments to MKL routines, the command to compile and link is:

ifort /Qmkl xheevr.f90 mkl_lapack95_lp64.libFor other combinations, etc., a good tool to use is the MKL Link Line Advisor, see https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor .

Thanks for your reply, I was able to compile and run the program by adding mkl_lapack_lp64.lib to the additional depedencies in Project Properties, but I still don't understand why it is that explicitly linking to external libraries is required for the lapack routines and not for the VSL or DFT routines.

Next, I am trying to get this running on a remote cluster now (let's ignore parallelization), but when I try to compile it there is tells me that the .lib file is not found (I normally run on this cluster compiling with the -mkl flag for the VSL and DFT libraries without issue). I tried copying the library over and linking it explicitly, but I still get the error "undefined reference to `zheev_f95_'". Any ideas why? I will also contact the admins and see if they can help with that.

Lastly, I still want to understand why my code seg faults when calling the F77 zheev algorithm as in my second example. It does this both on my computer and on the cluster. The code compiles without any warnings or errors and runs fine, but as soon as it calls the zheevr subroutine it seg faults. Any idea why this is?

chung__kristian

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-18-2019
12:07 PM

223 Views

Okay, after further testing, I have a somewhat different problem. I understand why the code was seg faulting, I wasn't using an explicit interface for the f77 routine and I was using it incorrectly. I now have the F77 routines running on both my own computer and the cluster. I still don't have the f95 routine running on the cluster, but I wrote a subroutine for the F77 routine which makes it equivalent. However, I noticed that the F95 routine running on my computer produces an incorrect output. Consider the following code

include 'lapack.f90' program heev_test use lapack95 implicit none integer , parameter :: dp = kind(0.0d0) complex(dp) :: matrix(4,4) real(dp) :: eigs(4) matrix = (1.0_dp,0.0_dp) print*, "checking eigenvalues using zheevr" call eigenvalues(matrix,eigs) print*, eigs print*, "checking eigenvalues using heevr" call heevr(matrix,eigs) print*, eigs read(*,*) stop contains subroutine eigenvalues(a,w) complex(dp) :: a(:,:) real(dp) :: w(:) character*1 :: jobz, range, uplo integer :: n, m, lda, il, iu, ldz real(dp) :: vl, vu, abstol integer :: info integer :: lwork, liwork, lrwork complex(dp) , allocatable :: z(:,:) complex(dp) , allocatable :: work(:) real(dp) , allocatable :: rwork(:) integer , allocatable :: iwork(:) integer , allocatable :: isuppz(:) jobz = 'N' range = 'A' uplo = 'U' n = size(a,dim=1) lda = max(1,n) vl = -huge(vl) vu = +huge(vl) il = 1 iu = n abstol = 0.0_dp ldz = max(1,n) lwork = max(1,2*n) lrwork = max(1,24*n) liwork = max(1,10*n) allocate(work(lwork)) allocate(rwork(lrwork)) allocate(iwork(liwork)) allocate(z(ldz,max(1,n))) allocate(isuppz(2*max(1,n))) lwork = -1 liwork = -1 lrwork = -1 print*, "test 2" call zheevr(jobz, range, uplo, n, a, lda, vl, vu, il, iu, abstol, m, w, & & z, ldz, isuppz, work, lwork, rwork, lrwork, iwork, liwork, info) print*, "test 3" lwork = work(1) liwork = iwork(1) lrwork = rwork(1) deallocate(work,iwork,rwork) allocate(work(lwork)) allocate(iwork(liwork)) allocate(rwork(lrwork)) call zheevr(jobz, range, uplo, n, a, lda, vl, vu, il, iu, abstol, m, w, & & z, ldz, isuppz, work, lwork, rwork, lrwork, iwork, liwork, info) deallocate(work,iwork,rwork) if (info /= 0) then print*, "diagonalization failed, info = ", info read(*,*) stop end if end subroutine end program

which produces the following output

checking eigenvalues using zheevr -6.330005540529565E-016 0.000000000000000E+000 7.788904174037827E-017 4.00000000000000 checking eigenvalues using heevr -0.612842417299582 -1.525922570253684E-002 0.612055954590501 4.01604568841162

The heevr (F95) result is incorrect, the correct eigenvalues are {0,0,0,4} as returned by the zheevr routine. Any idea why this is? For now I can move forward using my own subroutine as it seems to work properly.

mecej4

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-18-2019
02:58 PM

223 Views

chung, kristian wrote:

... but I still don't understand why it is that explicitly linking to external libraries is required for the lapack routines and not for the VSL or DFT routines.

Explicit linking is not required for Lapack routines called using the F77 interface. Explicit linking is required for Lapack routines called using the Fortran 95 interface (calls to generic routine names with abbreviated arguments lists and optional arguments) because the corresponding specific names are not present in the Lapack library; they are present in the Lapack95 library.

chung, kristian wrote:

Next, I am trying to get this running on a remote cluster now (let's ignore parallelization), but when I try to compile it there is tells me that the .lib file is not found (I normally run on this cluster compiling with the -mkl flag for the VSL and DFT libraries without issue). I tried copying the library over and linking it explicitly, but I still get the error "undefined reference to `zheev_f95_'". Any ideas why?

Does your cluster have MKL and Lapack95 installed on it? Which versions?

chung, kristian wrote:

However, I noticed that the F95 routine running on my computer produces an incorrect output. Consider the following code...

When your call to **zheevr **in Subroutine Eigenvalues returns, the matrix will have been overwritten. Please consult the documentation. You have to set the array **matrix **back to the desired set of values before calling **heevr**.

chung__kristian

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-18-2019
07:26 PM

223 Views

mecej4 wrote:When your call to

zheevrin Subroutine Eigenvalues returns, the matrix will have been overwritten. Please consult the documentation. You have to set the arraymatrixback to the desired set of values before callingheevr.

Thanks! My mistake, I should have realized this. After resetting the matrix both routines produce the same result

mecej4 wrote:Does your cluster have MKL and Lapack95 installed on it? Which versions?

Certainly MKL, but perhaps not Lapack95, is there a simple way I could check?

mecej4

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-18-2019
07:58 PM

223 Views

Topic Options

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page

For more complete information about compiler optimizations, see our Optimization Notice.