ARPACK with MKL crashes when calling zdotc

[Zauner__Valentin]

I am trying to use the ARPACK library written in fortran to solve an eigenvalue problem from within a C++ program, together with MKL implementations of the required BLAS and LAPACK routines. Specifically, I need to use the ARPACK driver for a standard eigenvalue problem of a complex general matrix. One first calls the ARPACK routine znaupd, which does the Arnoldi iteration, and then zneupd to extract the eigenvalues and -vectors. The sample program I have written is in C++ and calls the routines znaupd and zneupd as external fortran routines. The program runs perfectly fine when I link against regular BLAS/LAPACK (from the Ubuntu repos in my case) or OpenBLAS, but doesn't work with MKL.

The problem I am facing is that if I link against MKL, the program either gets stuck in an infinite loop or crashes during the ARPACK routine zneupd when requesting eigenvectors to be calculated as well.

I have pinpointed the problem to a call to the BLAS routine zdotc. When linked against MKL, mkl_blas_avx_zdotc is actually called and this routine seems to modify memory where it shouldn't. Specifically in this case, it also modifies a for-loop counter and always resets it to 0 and the program is infinitely stuck in this loop (If of interest, the loop is in ARPACK's file zneupd.f from line 719 to 736, the affected loop variable is j). Sometimes mkl_blas_avx_zdotc seems to modify memory somewhere else too and the program segfaults.

I tried linking against a precompiled version of ARPACK from the Ubuntu repos, as well as against a self-built version downloaded from arpack-ng (http://forge.scilab.org/index.php/p/arpack-ng/) that I built using gfortran. The problem is the same in both cases.

I compile my program using
icpc -std=c++11 -g -c arpack_test.cpp -o arpack_test.o

When I link against MKL, I follow the MKL link line advisor and use
icpc -o arp_test arpack_test.o /path/to/arpack/static/libarpack_debug.a -L${MKLROOT}/lib/intel64 -lmkl_intel_lp64 -lmkl_core -lmkl_sequential -lpthread -lm -lgfortran

Is there anything specific I need to watch out for when using MKL together with gfortran compiled libraries? To check if the problem is connected to passing complex c style arrays to fortran, I implemented the C++ program entirely using double c-style arrays only. Apart from that, is there anything one should watch out when using MKL in this case?

Thanks,
Valentin

[Vamsi_S_Intel · Accepted solution]

Since ARPACK is being compiled with GFortran, MKL GFortran interface library should be used in the link line (mkl_gf_lp64). Can you try linking with this interface library?

[Zauner__Valentin]

Oh, wow, that was easy to fix, thanks a lot!! If only all arpack bugs were that easy to resolve... To summarize I just replaced -lmkl_intel_lp64 with -lmkl_gf_lp64 in the linker call:

icpc -o arp_test arpack_test.o /path/to/arpack/static/libarpack_debug.a -L${MKLROOT}/lib/intel64 -lmkl_gf_lp64 -lmkl_core -lmkl_sequential -lpthread -lm -lgfortran

I actually didn't know that there was a separate MKL Gfortran interface. It would be nice if there was a note concerning that on the MKL link line advisor page (similar to the notes about libraries on WIN32 systems).

Are there any performance differences between mkl_intel_lp64 and mkl_gf_lp64?

Thanks again for the quick help and best regards,
Valentin

[Vamsi_S_Intel]

Thanks for letting us know that it worked out.

Regarding the performance differences between mkl_intel_lp64 and mkl_gf_lp64, since these are interface libraries who main purpose is to handle different calling conventions of compilers they have no impact on performance. In MKL, all computational work/functions are located in mkl_core library and are common for all compilers types.

[Zauner__Valentin]

Ah ok, great, thank you!

What should I then actually do if I had a C++ program calling BLAS functions, which is linked to a library compiled with gfortran, that is also calling BLAS function itself (e.g using ARPACK and in the main program also calling some BLAS routines)? I know this sounds very artificial, but I might actually have to consider this case...

Thanks,
Valentin

[Vamsi_S_Intel]

To cover this use-case, MKL mkl_gf_lp64 interface has both CBLAS and BLAS functions. So, you can continue to link with mkl_gf_lp64 even if BLAS/CBLAS functions are called from C/C++ and you also have linked third-party libraries that are compiled with GFortran.

The only exception cases are for Complex-type dot functions (cdotc, cdotu, zdotc, zdotu). In these case, you cannot call standard BLAS [c,z]dot[c,u] functions from C/C++ because the interface library that is linked is specific for GFortran which has a different calling convention of returning a Complex type and would cause issues. You can use the dot functions through the CBLAS interface (cblas_cdotc etc) to avoid this.

Is there any reason why ARPACK is not being compiled with Intel Fortran Compiler, ifort? If you compile ARPACK with ifort, then you can just use mkl_intel_lp64 library

[Zauner__Valentin]

Hi! Thanks for the detailed info! The reason why I use gfortran is that I only have a non-commercial license for icpc, but not for ifort. I saw however that open source developers can obtain a free non-commercial ifort version, so I will probably apply for such a license.

Thanks again for your help!

[marcsolal]

 I just found this post.  I have exactly the same problem. I am trying to link my c++ code with arpack. arpack is linked with gfortran and is crashing when in zdotc or giving a zero result. I am using parallel studio 2019 and I have only the c++ compiler. It looks the library linking since this post. I cannot libmkl_gf_lp64.a. Is it replaced by libmkl_gnu_thread.a ? Also, my c++ code is using blas and lapack a lot. How should I link?

Thanks,

Marc