Inconsistent calls to MKL library

Inconsistent calls to MKL library

I have an issue that I hope someone here could shed some light on. I am a new user, so presumably the issue is that I do not understand the workings of Fortran properly.

The problem occurs when I call the MKL LAPACK subroutine HEGVD and pass the ITYPE parameter to it. 

I have included a small piece of code that shows the problem (and the makefile that I used to compile it all with - I had to put a filetype on it, otherwise the uploader here wouldn't eat it :-) )

The first call to HEGVD gives no errors, but the outputted eigenvalues are wrong (zeros). The second call to HEGVD, however, gives me the error "MKL ERROR: Parameter 1 was incorrect on entry to ZHEGVD" and does not return either eigenvalues or eigenvectors.

If I then remove the "PRINT*,E" between calls, both calls goes through without giving any errors.

If i instead remove the second call to HEGVD, the first call actually gives me the correct eigenvalues.

In lager code I have also had the problem that HEGVD calls would only work when I didn't call specific other subroutines that I've written. Or that I had to define the itype variable in a different way.

Can anyone shed some light on what I'm doing wrong here?

Downloadapplication/octet-stream test.f90732 bytes
Downloadtext/plain makefile.txt801 bytes
7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I could not reproduce the problem on Windows, using MKL 10.3/IFort 12.1 and MKL 11/IFort13.0.

I obtained the result as

-2.000000 2.000000

instead of zeros as you reported.

Please state your platform, OS, compiler and MKL versions used.

I'm running Ubuntu 12.04 in a VMware virtual machine under Windows 8.
I don't know how to check what versions I have of either iFort or MKL. I just installed the Intel Composer XE 2011. As far as I can ascertain that means I have MKL 10.3 and iFORT 12.1.

I can reproduce the error (under Linux) with the versions indicated and newer versions (including XE 2013). I am unable to produce correct eigenvalues per your description so I am still trying to understand the behavior. Stay tuned...

My apologies for the delayed update.

So what’s going on is your program calls the MKL generic interface HEGVD with a 4-byte integer argument per you recompiling the lapack.f90 interfaces with the default integer size and that’s why you also had to add the KIND=4 specification to the ITYPE declaration; however, the underlying MKL library routine (ZHEGVD) was compiled with -i8 so it expects a 8-byte integer for ITYPE.

When using this mismatch in argument size, adding/removing the second CALL/PRINT in the caller alters the stack usage such that different combinations alter the 8-byte argument ZHEGVD receives enough that for some it cannot discern the value of ITYPE and issues the run-time error; where other changes do not trigger a failure; however, the values ZHEGVD received for ITYPE and JOBZ are likely incorrect.

To correct this issue, remove the KIND specification from the ITYPE declaration and adjust the KIND argument to the INT intrinsic for the assignment to ITYPE accordingly. Next, choose either to use the pre-compiled MKL Fortran 95 interfaces or change your compilation for lapack.f90 (and blas.f90 if you use those routines) to use 8-byte integers.

MKL provides pre-compiled Fortran 95 interfaces so it is not required users build those. To use those, in your sample Makefile do not recompile the blas.f90 and lapack.f90 or include the object in your executable and set FCOPT as follows:

FCOPT = -i8 -r8 -I$(MKLROOT)/include/intel64/ilp64

According to the MKL lapack95 interfaces makefile (/opt/intel/composer_xe_2013/mkl/interfaces/lapack95/makefile), that interface file should be compiled with “-i8 -auto” ; therefore, add those options in your Makefile for lapack.f90 (and to blas.f90 if your larger apps depends on that) if you choose to recompile the interface file yourself.

Sorry again for the delay. Hope that helps.

Kevin Davis:
Thank you for your very thorough answer. Your solution fixed my problem. Again, thanks :)

You're welcome. Glad I could help.

Leave a Comment

Please sign in to add a comment. Not a member? Join today