- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

good to know...

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page