Registered Member
|
Hi,
I run into a problem with the SparseQR solver (which does not occur with the SparseLU solver) The problem is the following :
The following assert is not verified :
Indeed the size of the matrix is 52*52 and index is equal to 52 The problem occurs on line 372 of SparseQR.h in the factorize function :
I don't really know what I am doing wrong. I am not even sure that I am doing something wrong, since the SparseLU solver works. The only particularity is that the lhs matrix is row major. (I need it to reformulate some coefficients row-by-row, see viewtopic.php?f=74&t=122606 ) - Is it known that SparseQR may not work with row-major sparse matrix ? (I didn't found any indications in the documentation) - The problem occurs at the third factorization, is it possible that it only occurs because my matrix is singular ? - Is this a possible bug ? |
Moderator
|
Can you show the code where SParseQR is instantiated and called together with the exact types of the involved matrices. Thank you.
|
Moderator
|
btw, it seems that you are using an old version of Eigen. Please give the 3.2.2 a try. Maybe you are just hitting a pretty old bug.
|
Registered Member
|
Updating to 3.2.2 didn't change the problem
It is part of a Semismooth Newton solver. This is the main code
Changing the ordering method does not correct the problem. setup_jacobian has two step, first I compute it :
then I reformulate it using inner iterator :
The solver doesn't converge even with the LU solver, so there is probably a problem somewhere in my code, it is possible that the jacobian is close to singular, leading to a problem with the QR algorithm. With the current parameters the problem only occurs at the 38th iteration. But I would still expect the solver to finish its jobs and indicate the failure when calling solver.info() not with a failed assertion. Is there a way for me to provide you the matrix so you can test ? ( unrelated note with Eigen-3.2.2 and gcc-4.8.3 I have the following non-critical warning
) |
Registered Member
|
using Eigen::AMDOrdering<int> as the ordering method with Eigen-3.2.2 leads to that compilation error :
Also, the BiCGSTAB failed to solve the linear system |
Moderator
|
Yes, having access to the matrix will help to spot the issue. See http://eigen.tuxfamily.org/dox-devel/gr ... tml#title3 to export it in the matrix market format. There is no reason for SparseLU to be numerically more robust than SparseQR!
AMDOrdering is for symmetric problems. It is not compatible with QR. Regarding BiCGSTAB, it is well known that BiCGSTAB does not converge on some problems, nonetheless, make sure you tried BiCGSTAB with the IncompleteLUT preconditioner, not the default Jacobi one. |
Registered Member
|
The matrix : http://pastebin.com/6JeLCiab
The RHS : http://pastebin.com/LWxJNA19 This is not a "good" system, I still have some bugs in my code, and this is probably why the assertion is raised, but I would expect that the solver fails nicely and report the error with the solver.info() methods. The fact that SuperLU and BiCGSTAB manage to return an answer is not very relevant, since the answer is garbage, but at least they don't raise an error that terminates the program. But I think this has something to do with the "row-major" thingy, since transforming the matrix to a column major leads to an answer (still garbage but the assertion is not raised) :
The backtrace is :
In the factorize method :
When the assertion is raised 'st' is equal to 52 (hence the error since mark is a Vector of size 52, m_etree is a vector of size 52 where m_etree[i] = i+1 (so st= m_etree[51] = 52 )) This is the values of the local variables of the method : http://pastebin.com/LtFzrNNU I tried to go deeper in the code, but I don't really know these algorithms so I am a bit lost... |
Moderator
|
alright, this is fixed in the 3.2 and default branch.
What do you mean by garbage? For me your example is working ok with both SparseQ, SparseLU and BiCGSTAB with a relative error of 1e-7. (your matrix is highly singular, so 1e-7 is pretty good) |
Registered Member
|
Great thank you very much
I still have a question, your answer is similar to mine, you copy the matrix in a column-major matrix before you compute the column elimination tree. How expensive is it ? This problem wasn't happening with every row-major matrix I encounter, so it may be too much... and when I said garbage, I was just meaning, not at all the solution I expect (but that's my problem) |
Moderator
|
All the computation and analysis have to be performed column-wise, there is no alternative. The best would be to assemble a column-major matrix at the first place.
|
Registered Member
|
ok, so the fact that it sometimes worked was purely luck...
I have to reformulate the Jacobian row-by-row, so using a row-major seems required Thank you for Eigen and your helpful support |
Registered users: Bing [Bot], claydoh, Google [Bot], rblackwell, Yahoo [Bot]