[Trilinos-Users] Trilinos and MKL

[Hoemmen, Mark]

On Aug 20, 2013, at 12:00 PM, <trilinos-users-request at software.sandia.gov>
 wrote:
> Message: 2
> Date: Tue, 20 Aug 2013 12:11:50 +0000
> From: "Ramsey, James J CIV (US)" <james.j.ramsey14.civ at mail.mil>
> Subject: Re: [Trilinos-Users] Trilinos and MKL
> To: "trilinos-users at software.sandia.gov"
> 	<trilinos-users at software.sandia.gov>
> Message-ID:
> 	<B5E7491E7F72164997C336AA7C85A5FC157FA8D6 at ucolhp9m.easf.csd.disa.mil>
> Content-Type: text/plain; charset=us-ascii
> 
> I noticed that in the library names for BLAS and LAPACK, you have "mkl_intel_ilp64" rather than "mkl_intel_lp64". See what happens if you use "mkl_intel_lp64" instead. FYI, some documentation on the difference between ILP64 and LP64 is here: http://software.intel.com/sites/products/documentation/hpc/mkl/mkl_userguide_lnx/GUID-87821148-338B-4022-8C90-F24C866F2878.htm
> 
> My guess is that the error messages from MKL reflect an issue with integer sizes.

You're spot on.  I vaguely recall seeing this error before.

Trilinos definitely assumes that integer inputs and outputs of BLAS and LAPACK routines are C int (Fortran INTEGER), a 32-bit signed integer type.  This would _not_ work with the ILP64 version of MKL, which assumes 64-bit signed integers.  ("LP64" means long (L) and void* (P ) are 64 bits, but int remains 32 bits.  "ILP64" means that int (I), long (L), and void* (P ) are all 64 bits.)

Users who nevertheless link with the ILP64 version of MKL will likely get errors such as this, because the routine interprets its arguments on the stack as 64-bit integers, thereby merging or otherwise corrupting 32-bit integer arguments.  Other kinds of errors (e.g., segfaults from using corrupted pointers) are also possible.  Users who want to link Trilinos with the MKL should therefore always link with the LP64 version of MKL, never the ILP64 version.

mfh