bug in MKL 11.0update5 DGESVG

[kangshiyin]

Same code works fine in 11.0update1 but return error (result=-13) in update5

Linux version CentOS 6.4
$ uname -a
Linux 2.6.32-358.6.2.el6.x86_64 #1 SMP Thu May 16 20:59:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

code:

dgesvd(v_job, u_job, &M, &N, data_, &LDA, s->Data(), V->Data(), &V_stride, U->Data(), &U_stride, p_work, &l_work, &result);

data:

u_job char * 0x4d4fea "N" 
v_job char * 0x4d4fea "N" 
M KaldiBlasInt 1
N KaldiBlasInt 10 
LDA KaldiBlasInt 2 
V_stride KaldiBlasInt 2 
U_stride KaldiBlasInt 2 

data_ double [20] 0x741300
data_[0] double 0.78239572048187256
data_[1] double 1.0829823019173015e-312
data_[2] double -0.50321561098098755
data_[3] double 1.5021374629402668
data_[4] double 2.4055604934692383
data_[5] double 1.0829822489929895e-312
data_[6] double -0.79770100116729736
data_[7] double 0
data_[8] double 0.25807684659957886
data_[9] double 0
data_[10] double 1.0628244876861572
data_[11] double 0
data_[12] double 0.30530369281768799
data_[13] double 0
data_[14] double 0.82724034786224365
data_[15] double 0
data_[16] double -0.49196150898933411
data_[17] double 0
data_[18] double -0.21408705413341522
data_[19] double -0.10297946631908417

l_work KaldiBlasInt 5 

p_work double * 0x741460

result KaldiBlasInt -13

[mecej4]

Check in the MKL documentation to see whether you have made the work array large enough. The values of data_[1] and data_[5] arouse suspicion that these may be undefined, and therefore vary from run to run.

[kangshiyin]

it's a 1x10 matrix with leading dim = 2, so data_[1]/[5] should be useless, and 1x10 should be large enough according to the ref man.

mecej4 wrote:

Check in the MKL documentation to see whether you have made the work array large enough. The values of data_[1] and data_[5] arouse suspicion that these may be undefined, and therefore vary from run to run.

[mecej4]

The value of l_work in your argument list is given as 5. For m = 1 and n = 10, that value does not satisfy the requirement that

      l_work ≥ max(3*min(m, n)+max(m, n), 5*min(m,n)).

Please edit your first post and change "DGESVG" to "DGESVD" in the thread title so that future users may use the search features to find this page.

[kangshiyin]

Thanks for the quick reply. I just reviewed the code and found that l_work=5 is a query result given by dgesvd() itself by setting l_work=-1 first. I write a simple code to test this issue. I found the query result of l_work are both 5 for 11.0.1 and 11.0.5, but 11.0.5 will then give "MKL ERROR: Parameter 13 was incorrect on entry to DGESVD." while 11.0.1 not. Here is the test code PS. I cannot find EDIT button for my original post. Should a post a new thread? #include #include int main() { double data[20] = { 2, 7, 5, 9, 3, 6, 2, 5, 4, 8, 5, 6, 3, 4, 6, 3, 7, 2, 3 }; int m = 1; int n = 10; int lda = 2; int ldvt = 2; int ldu = 2; int l_work = -1; double p_work[100]; int result; double s[100], u[100], vt[100]; dgesvd("N", "N", &m, &n, data, &lda, s, u, &ldu, vt, &ldvt, p_work, &l_work, &result); std::cout << p_work[0] << std::endl; l_work = (int) p_work[0]; dgesvd("N", "N", &m, &n, data, &lda, s, u, &ldu, vt, &ldvt, p_work, &l_work, &result); std::cout <<"MKL ver: "<< INTEL_MKL_VERSION << std::endl; return 0; }

[mecej4]

I cannot understand what your program is trying to do. One difficulty is that you chose to call the Fortran 77 routine dgesvd from C++, rather than using the better-suited LapackE interface. 

• The array data is declared to be of size 20, but the initialization list contains 19 values. 
• Neither of these numbers equals the product of the specified values of m and n.
• The values of lda, ldu, ldvt do not match either m or n, and I see no reason why they should not.

To untangle the problem, let us back up and state the mathematical problem clearly. You want to compute the decomposition A = U.S.V^T, what is the size of matrix A, and what are its elements? Once we establish that, we can proceed to implementing the decomposition using MKL.

[kangshiyin]

The above program is trying to show there's an implementation bug in MKL 11.0.5

• Using fortran 77 interface in my real code is to enable the code link to other BLAS libs such as ATLAS.
• init list with 19 values is a typo, and I will fix it.
• lead dimensions like lda ldu ldvt often greater than the length of the rows in a row-major matrix is because we are trying to make the data well aligned. Please refer to this link for further discussion.  
• the size of A is 1x10

All these details have nothing to do with the bug.

[mecej4]

Thanks. Using the details that you just provided, I constructed an easier-to-use reproducer in Fortran and posted it as http://software.intel.com/en-us/forums/topic/402473, "Incorrect workspace size returned by query to DGESVD in MKL 11.0.5" . 

Gennady Fedorov (Intel) has responded to that post and they are looking into the problem.

[kangshiyin]

good to know...

[Aleksandr_Z_Intel]

kangshiyin,

Thank you for reporting the issue. Workaround is to set gesvd lwork  ≥ max(3*min(m, n)+max(m, n), 5*min(m,n)) for real flavors and lwork ≥ 2*min(m, n)+max(m, n) for complex flavors for m and n such that (12*m+n) <160 or (12*n+m) <160.