topic Since m is an output variable in Intel® oneAPI Math Kernel Library

DSBGVX documentation: ifail dimension is n?

martenjan — Tue, 25 Mar 2014 12:51:39 GMT

dsbgvx kept crashing on me with an access violation for large enough problems (n=3636). I am compiling for an x64 target.

Meticulously studying the manual, http://software.intel.com/sites/products/documentation/hpc/mkl/mklman/index.htm#GUID-659297EE-D35B-428C-ABBE-1A7EBE2B0F6E, I noticed that the dimension of ifail is m for dsbgvx, and n for sbgvx.

Allocating n integers for ifail, dsbgvx stops crashing.

Another peculiarity is that dsbgvx does not crash on me while compiled for an Win32 target.

Questions:

I am selecting only m out of n eigenvalues. The information I aim for should fit in w(1:m) and z(1:n,1:m), as discussed in the Fortran 95 interface of e.g. ?stein. So, is w(n) and z(n,n) really required in dsbgvx?

Now that ifail(n) works and ifail(m) fails, should the manual read that the dimension of ifail must be n? And if so, why do w(m), z(n,m) and ifail(m) work for Win32 targets?

Since m is an output variable

mecej4 — Tue, 25 Mar 2014 13:44:00 GMT

Since m is an output variable, its value is not known before the subroutine ?sbgvx is called except in the special case where only a subset of the eigenvalues are being sought and their count is already known before the call. It is impossible to declare an array with an unknown size (at compile time) unless one is using allocatable arrays, which we are not doing here. Therefore, the array ifail must be declared with dimension n. The MKL manual states in the output section what the contents of locations 1:m of the array are, but the caller must allocate the array to be sufficiently large in order to cover all eventualities.

Thanks, this makes it very

martenjan — Wed, 26 Mar 2014 13:55:49 GMT

Thanks, this makes it very clear.

That also explains why z(n,n) is required.