a generalized eigenvalue problem question - Part 2

a generalized eigenvalue problem question - Part 2

Dear all,

I am using

LAPACKE_dsygv

to solve a generalized eigenvalue problem, AX = lambda BX, by using row major orientation.

My A matrix is almost identity matrix, there are numerically really small entries off-diagonal(on the order of 1e-17) and My B matrix is also close to symmetric. The terms close to the diagonal seems to be symmetrix, however there are again small entries apart from the diagonal and the orders of these terms are also the same as the ones(1e-17). So I guess using a symmetric solver in this case is ok.

If I use a symmetric solver, I can find the eigenvalues correctly. But my eigenvectors are not right. I compare them with MATLAB and the ratio of the terms in the two vectors(MATLAB and the one compute with dsygv) are not the same.

Since I use the ROW_MAJOR_FORMAT for my matrices, I am assuming that the output eigenvector array is also in ROW_MAJOR_ORDER, is this right?

If that is correct then there is an ambuiguity on the computations that I could not solve. I use the ROW_MAJOR_FORMAT but I input whole arrays for A and B. I guess MKL takes care of the Upper/Lower selection issue correctly and since the eigenvalues are computed correctly, I am assuming that the input matrix operations are correct. Now, what could be going wrong in the eigenvector computation, or phrased differently where could be my problem on the ordering?

Any help is appreciated,
Umut

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

You make many conjectures here that may be unfounded and may give you incorrect results. I will not respond to them item by item.

> I use the ROW_MAJOR_FORMAT but I input whole arrays for A and B.
>
I
guess
MKL takes care of the Upper/Lower selection issue correctly
>

since the
eigenvalues are computed correctly.

A Lapack routine that has a symmetric matrix as an input argument will have a statement in the documentation that tells you whether it is the upper or the lower triangle that is to be filled in before the call. You have to pass a whole array, but only the values in either the lower or the upper triangle are used. The other half triangle may be used as scratch space, or may be used to return results (e.g., eigenvectors). If the documentation so specifies, it may even happen that something else is passed in through that part.

If the documentation tells you that only the upper triangle needs to be filled before the call, it is harmless, if wasteful, to fill in the lower triangle. If the documentation tells you that something else should be placed in the lower triangle, on the other hand, putting in the symmetric image of the upper triangle will cause errors.

Lapack dates back to the 80s and 90s. People went to great lengths to reduce memory consumption by packing disparate items into arrays. Until a major revision of Lapack is undertaken and completed, we have to continue using subroutines whose design may seem anachronistic and inconvenient in these times of cheap gargantuan memory.

Login to leave a comment.