DSBGVX documentation: ifail dimension is n?

DSBGVX documentation: ifail dimension is n?

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.


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?


3 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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 clear.

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



Leave a Comment

Please sign in to add a comment. Not a member? Join today