topic I don't think that we should in Intel® oneAPI Math Kernel Library

Problem with ZCGESV

Alexander_D_6 — Tue, 30 Jun 2015 14:34:18 GMT

The problem I am facing is that ZCGESV function crashes when matrix size is 46497 or more. When matrix size is, for example, 46202 everything works fine.

From what I can see in LAPACK sources at http://www.netlib.org/lapack/explore-html/d5/d4a/zcgesv_8f_source.html, there can be integer overflow for variable ptsx for large n as ptsx is declared as INTEGER:

*     .. Local Scalars ..
INTEGER            i, iiter, ptsa, ptsx

* Set the indices PTSA, PTSX for referencing SA and SX in SWORK.
ptsa = 1
ptsx = ptsa + n*n

It looks like there is a similar problem in zcgesv routine in MKL. I couldn't find any information in MKL documentation related to this issue. Can anyone confirm that this is a bug in MKL?

Thanks,

Alexander

I don't think that we should

mecej4 — Tue, 30 Jun 2015 16:28:00 GMT

I don't think that we should consider every possible instance of integer overflow, division by zero, etc., in library routines to be a bug. The user has to take steps not to have or generate arrays that are too large to be addressed with 32-bit pointers if the 32-bit or LP64 versions of MKL are to be used.

Have you tried compiling for X64 using the ILP64 MKL libraries? Is your huge matrix dense as well?

Thanks for your reply.

Alexander_D_6 — Tue, 30 Jun 2015 18:08:41 GMT

Thanks for your reply.

How can I take steps to ensure there is no integer overflow *inside* MKL routine? I have two similar matrices, first one with N=46202 and the second one with N=46497. I call zcgesv and it solves the first matrix and crashes for the second one. The code is compiled for X64. Actually I don't know what exactly happens inside zcgesv, it was only my first assumption that integer overflows.

It would be useful for you to

mecej4 — Tue, 30 Jun 2015 21:40:59 GMT

It would be useful for you to post the source code for a case where the ZCGESV fails, and to provide information on how you built the program and what the crash messages were.

I have attached Visual Studio

Alexander_D_6 — Wed, 01 Jul 2015 10:02:13 GMT

I have attached Visual Studio project with full source code of the solver using zcgesv. Number of unknowns can be controlled from input.dat file. It's currently set to 47 000, which requires ~33 GB of RAM. Screenshot of access violation is also attached.

And one more question. Does it make sense to declare swork array as swork(:,:) or swork(n,n,nrhs)? If possible, will it provide any advantage?

Thanks,

Alexander

I do not have access to any

mecej4 — Wed, 01 Jul 2015 14:09:58 GMT

I do not have access to any machine with that much RAM.

Alexander D. wrote:

And one more question. Does it make sense to declare swork array as swork(:,:) or swork(n,n,nrhs)? If possible, will it provide any advantage?

You are using the F77 interface to Lapack/MKL. Therefore, the argument swork is passed by reference, i.e., the address of the first element of the array is passed. Therefore, there will be absolutely no difference as far as the call to zcgesv is concerned. Of course, there will be differences in the declaration (and allocation, if appropriate).

The problem was solved by

Alexander_D_6 — Thu, 02 Jul 2015 08:26:30 GMT

The problem was solved by migrating to 64-bit integers and linking with ILP64 version of MKL.

Thanks for your help.