topic it's a 1x10 matrix with in Intel® oneAPI Math Kernel Library

bug in MKL 11.0update5 DGESVG

kangshiyin — Wed, 24 Jul 2013 17:14:11 GMT

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

Check in the MKL

mecej4 — Wed, 24 Jul 2013 17:27:16 GMT

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.

it's a 1x10 matrix with

kangshiyin — Wed, 24 Jul 2013 17:35:28 GMT

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.

The value of l_work in your

mecej4 — Wed, 24 Jul 2013 17:50:00 GMT

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.

Thanks for the quick reply.

kangshiyin — Thu, 25 Jul 2013 02:45:00 GMT

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; }

I cannot understand what your

mecej4 — Thu, 25 Jul 2013 09:08:19 GMT

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.

The above program is trying

kangshiyin — Thu, 25 Jul 2013 09:32:52 GMT

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.

Thanks. Using the details

mecej4 — Thu, 25 Jul 2013 11:27:00 GMT

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.

good to know...

kangshiyin — Thu, 25 Jul 2013 17:20:27 GMT

good to know...

kangshiyin,

Aleksandr_Z_Intel — Thu, 08 Aug 2013 09:42:38 GMT

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.