Snow Leopard + MKL 10.2 update 2 breaks working PARDISO code

[ringlenscl_msu_edu]

Greetings,

I had a working project built in Xcode using PARDISO using Leopard and the MKL version distributed with the 11.1.056 Intel C++ compiler. I work on two machines, a Penryn macbook pro and a Nehalem 8 core mac pro. After upgrading both to Snow Leopard and installing the 11.1.067 version of the c++ compiler and accompanying verison of MKL I have run into issues. I uninstalled all previous versions of the c++ compiler and MKL.

Using the link line advisor the linking has changed slightly from what I was previously using. Using the new link line doesn't fix the problem, though, and this is the link line it advises to use:

-L$MKLPATH $MKLPATH/libmkl_solver_lp64.a -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -openmp -lpthread

I get a segmentation fault when running the code after it has successfully compiled and linked. I set iparm(27)=1 to see if there are any problems with my input matrix, but it returns no errors. The segmentation fault seems to happen randomly as PARDISO is called. If I use the debugger and run PARDISO a few times until the fault appears I receive EXC_BAD_ACCESS in mkl_blas_xcswap. Any advice would be appreciated. Thanks!

[ringlenscl_msu_edu]

Below is the routine which calls PARDISO. There are multiple calls made within a loop where new matrices are calculated and solved (lhsmatrix and rhsvector are recalculated in calcLHSMatrix(n) and calcRHSVector(n)). Now the segmentation fault doesn't happen all of the time, as mentioned previously. The loop below can be run several times without it ever popping up. When it does happen, though, it's always on the first call (n=0) and during the numerical factorization (phase = 22) portion. If I set msglvl=1, the fault occurs at some point when the "Percentage of computed non-zeros for LL^T factorization" message appears.

I should also mention that I ran the complex, unsymmetric example and it doesn't seem to suffer from a segmentation fault, but I didn't run it through as many iterations. Any thoughts or suggestions would be appreciated. Thanks!

Ryan

bool cylpotsolver::solveLinSys3()

{

//same as solveLinSys2 except slightly rearranged

calcRowsandCols();

long long *pt = new long long[64];

for(int i=0; i<64; i++)

pt[i]=0;

int *iparm = new int[64];

iparm[0] = 0; //use default parameters

iparm[1] = 3;

iparm[26]=0; //check data structure if equal to 1

iparm[59] = 0; //use in-core pardiso

int maxfct = 1;

int mnum = 1;

int mtype = 13; //unsymmetric and complex matrix

int phase = 13; //analysis,numerical factorization,solve,iterative refinement

int numeqs = nrad*nz;

int *perm;

int nrhs = 1;

int msglvl = 0;

complex16 *x = new complex16[nrad*nz];

int error;

for(int n=0; n<=ntheta/2; n++)

{

calcLHSMatrix(n);

calcRHSVector(n);

cout<<"Solving for n = "<<<"...n";

/*

Call the linear system solver. See the Intel math kernel library docs for

more info

*/

cout<<"calling solver...n";

PARDISO(pt, &maxfct, &mnum, &mtype, &phase, &numeqs, lhsmatrix, rows,

columns, perm, &nrhs, iparm, &msglvl, rhsvector, x, &error);

cout<<"error = "<<<"...n";

phase = -1; //clear memory used by PARDISO

cout<<"clearing memory...n";

PARDISO(pt, &maxfct, &mnum, &mtype, &phase, &numeqs, lhsmatrix, rows,

columns, perm, &nrhs, iparm, &msglvl, rhsvector, x, &error);

//u_(-n)=conj(u_n)

for(int i=0; ii++) //copy solved data to another array

{

if(n==0)

{

potdata[i*ntheta].re = x[i].re;

potdata[i*ntheta].im = x[i].im;

}

else if(n==ntheta/2)

{

potdata[ntheta/2+i*ntheta].re=x[i].re;

potdata[ntheta/2+i*ntheta].im=x[i].im;

}

else

{

potdata[n+i*ntheta].re=x[i].re;

potdata[n+i*ntheta].im=x[i].im;

potdata[ntheta-n+i*ntheta].re=x[i].re;

potdata[ntheta-n+i*ntheta].im=-x[i].im;

}

}

// cout<<"done."<

}

delete [] x,pt,iparm,perm;

return true;

}

[Gennady_F_Intel]

Quoting - ringlenscl.msu.edu

Greetings,

I had a working project built in Xcode using PARDISO using Leopard and the MKL version distributed with the 11.1.056 Intel C++ compiler. I work on two machines, a Penryn macbook pro and a Nehalem 8 core mac pro. After upgrading both to Snow Leopard and installing the 11.1.067 version of the c++ compiler and accompanying verison of MKL I have run into issues. I uninstalled all previous versions of the c++ compiler and MKL.

Using the link line advisor the linking has changed slightly from what I was previously using. Using the new link line doesn't fix the problem, though, and this is the link line it advises to use:

-L$MKLPATH $MKLPATH/libmkl_solver_lp64.a -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -openmp -lpthread

I get a segmentation fault when running the code after it has successfully compiled and linked. I set iparm(27)=1 to see if there are any problems with my input matrix, but it returns no errors. The segmentation fault seems to happen randomly as PARDISO is called. If I use the debugger and run PARDISO a few times until the fault appears I receive EXC_BAD_ACCESS in mkl_blas_xcswap. Any advice would be appreciated. Thanks!

Hi ringle,
this is well known limitation with the latest Intel MKL's version dealt with XCode 3.2.
Please refer tothehttp://software.intel.com/en-us/articles/known-limitations-in-intel-mkl-10-2/ article.
--Gennady

[Gennady_F_Intel]

Quoting - Gennady Fedorov (Intel)

Hi ringle,
this is well known limitation with the latest Intel MKL's version dealt with XCode 3.2.
Please refer tothehttp://software.intel.com/en-us/articles/known-limitations-in-intel-mkl-10-2/ article.
--Gennady

It should be noticed that this limitation doesn't affect dynamic libraries.
the similar probelm was disscused inhttp://software.intel.com/en-us/forums/showthread.php?t=68104as well.
--Gennady

[ringlenscl_msu_edu]

Quoting - Gennady Fedorov (Intel)

It should be noticed that this limitation doesn't affect dynamic libraries.
the similar probelm was disscused inhttp://software.intel.com/en-us/forums/showthread.php?t=68104as well.
--Gennady

Hi,

Thanks for your reply. I looked at the first link and the only relevant entry that I saw was:

To bind with static libraries for the Intel 64 architecture, you need Xcode* version 2.4.1 as the linkers which come with earlier Xcode* versions fail to bind. This limitation doesn't affect dynamic libraries, nor any IA-32 libraries.

Yet this seems to indicate that Xcode 2.4.1 is the earliest version which is usuable. Am I missing something? Also, the second link you posted leads to a page not found error. Anyway, are there any workarounds for this problem? Can one use 32 bit libraries, or is it a consequence of the static linking of the solver library? Thanks for your time.

Ryan

[Quoc-An_L_Intel]

Quoting - ringlenscl.msu.edu

Hi,

Thanks for your reply. I looked at the first link and the only relevant entry that I saw was:

To bind with static libraries for the Intel 64 architecture, you need Xcode* version 2.4.1 as the linkers which come with earlier Xcode* versions fail to bind. This limitation doesn't affect dynamic libraries, nor any IA-32 libraries.

Yet this seems to indicate that Xcode 2.4.1 is the earliest version which is usuable. Am I missing something? Also, the second link you posted leads to a page not found error. Anyway, are there any workarounds for this problem? Can one use 32 bit libraries, or is it a consequence of the static linking of the solver library? Thanks for your time.

Ryan

Try this link: http://software.intel.com/en-us/forums/showthread.php?t=68104

Try linking with dylibs instead of static libs.

[ringlenscl_msu_edu]

Quoting - Qale (Intel)

Try this link: http://software.intel.com/en-us/forums/showthread.php?t=68104

Try linking with dylibs instead of static libs.

Greetings,

I started out with the link line suggested by the link line advisor:

-L$MKLPATH $MKLPATH/libmkl_solver_lp64.a -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -openmp -lpthread

By reading the MKL documentation it looks like $MKLPATH/libmkl_solver_lp64.a isn't required and one can use

-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_lapack -lmkl_core -openmp -lpthread,

instead, which is what I tried (all dylibs). Everything links fine but the segmentation fault still occurs randomly and when it doesn't, the output is still wrong.

Ryan

CORRECTION: When the code runs and the segmentation fault doesn't occur the output is correct.

[Gennady_F_Intel]

Hello Ringle,
1)Yes, you can try to use only dynamic linking without this libraries( these libs are deprecated libraries since the next update of MKL - MKL 10.2 Update 2).
2) the snip of the code you provided is not complete. Could you get the testcase and the input data you are using for reproducing the problem? You can use private tread for sending this data. We will check this problem.
--Gennady

[William_Isaacs]

Quoting - Gennady Fedorov (Intel)

Hello Ringle,
1)Yes, you can try to use only dynamic linking without this libraries( these libs are deprecated libraries since the next update of MKL - MKL 10.2 Update 2).
2) the snip of the code you provided is not complete. Could you get the testcase and the input data you are using for reproducing the problem? You can use private tread for sending this data. We will check this problem.
--Gennady

I ran across this when I was testing a fresh install of the 11.1 compilers on SL. You have a testcase in hand already - it's in the mkl/tests/ directory:

[waisaacs@waisaacsmacbookpro ~]$ cd /opt/intel/Compiler/11.1/067/bin

[waisaacs@waisaacsmacbookpro bin]$ . iccvars.sh intel64
[waisaacs@waisaacsmacbookpro bin]$ . ifortvars.sh intel64

[waisaacs@waisaacsmacbookpro bin]$ echo $MKLROOT
/opt/intel/Compiler/11.1/067/Frameworks/mkl

[waisaacs@waisaacsmacbookpro bin]$ ifort -V
Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20090827 Package ID: m_cprof_p_11.1.067
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

[waisaacs@waisaacsmacbookpro bin]$ cd ../Frameworks/mkl/tests/blas/

[waisaacs@waisaacsmacbookpro blas]$ make libem64t
make s1sparse.res d1sparse.res c1sparse.res z1sparse.res sblat1.res dblat1.res cblat1.res zblat1.res cblat1_f.res sblat2.res dblat2.res cblat2.res zblat2.res sblat3.res dblat3.res cblat3.res zblat3.res EXT=a _IA=em64t RES_EXT=lib
mkdir -p ./_results/intel_lp64_parallel_em64t_lib
ifort -w -O0 -vec-report0 source/s1sparse.f source/auxspars.f -L"/opt/intel/Compiler/11.1/067/Frameworks/mkl/lib/em64t" "/opt/intel/Compiler/11.1/067/Frameworks/mkl/lib/em64t"/libmkl_intel_lp64.a "/opt/intel/Compiler/11.1/067/Frameworks/mkl/lib/em64t"/libmkl_intel_thread.a "/opt/intel/Compiler/11.1/067/Frameworks/mkl/lib/em64t"/libmkl_core.a "/opt/intel/Compiler/11.1/067/Frameworks/mkl/lib/em64t"/libmkl_intel_thread.a "/opt/intel/Compiler/11.1/067/Frameworks/mkl/lib/em64t"/libmkl_core.a -L"/opt/intel/Compiler/11.1/067/Frameworks/mkl/lib/em64t" -liomp5 -lpthread -o _results/intel_lp64_parallel_em64t_lib/s1sparse.out
ld: in /opt/intel/Compiler/11.1/067/Frameworks/mkl/lib/em64t/libmkl_core.a(_mc3_cscal.o), ObjectFileAddressSpace::mappedAddress(0xFFFFFFFFFFFFFFFC) not in any section
make[1]: *** [s1sparse.res] Error 1
make: *** [libem64t] Error 2


Cheers,
William

[William_Isaacs]

ld: in /opt/intel/Compiler/11.1/067/Frameworks/mkl/lib/em64t/libmkl_core.a(_mc3_cscal.o), ObjectFileAddressSpace::mappedAddress(0xFFFFFFFFFFFFFFFC) not in any section
make[1]: *** [s1sparse.res] Error 1
make: *** [libem64t] Error 2

Perhaps redundant, but this is mkl 10.2 update 2:

from the examples/versionquery directory:

[waisaacs@waisaacsmacbookpro versionquery]$ make libem64t
make getversionstring_c.res getversion_tst.res getversionstring_f.res _IA=em64t EXT=a RES_EXT=lib
mkdir -p ./_results/intel_lp64_parallel_em64t_lib

...

[waisaacs@waisaacsmacbookpro versionquery]$ cat _results/intel_lp64_parallel_em64t_lib/getversion_tst.res
Major version: 10
Minor version: 2
Update version: 2
Product status: Product
Build: 20090814
Processor optimization: Intel Core 2 Duo Processor
================================================================

[waisaacs@waisaacsmacbookpro versionquery]$

[Gennady_F_Intel]

Willian,I noticed you linked statically. This is well known problem for SnowLeo.
Please try to use dynamic linking by make soem64t instead of libem64t.
--Gennady

[Gennady_F_Intel]

Quoting - Gennady Fedorov (Intel)

Willian,I noticed you linked statically. This is well known problem for SnowLeo.
Please try to use dynamic linking by make soem64t instead of libem64t.
--Gennady

Hello,

We have recently released Compiler Professional Edition for Mac OS version 11.1 update 3.

The problem when static linking of MKL in XCode was resolved in this version.

You can update this version of Compiler into intel registration center( https://registrationcenter.intel.com/ ).

--Gennady