This bugzilla service is closed. All entries have been migrated to
Bug 897 - IterativeSolver and UmfPack do not work with MappedSparseMatrix
Summary: IterativeSolver and UmfPack do not work with MappedSparseMatrix
Alias: None
Product: Eigen
Classification: Unclassified
Component: Sparse (show other bugs)
Version: 3.3 (current stable)
Hardware: All All
: High Crash
Assignee: Nobody
Depends on: 910
Blocks: 3.3
  Show dependency treegraph
Reported: 2014-10-21 15:15 UTC by Christoph Hertzberg
Modified: 2019-12-04 13:51 UTC (History)
2 users (show)


Description Christoph Hertzberg 2014-10-21 15:15:17 UTC
The problem is that in IterativeSolverBase::compute(const MatrixType& A) the address of a temporary object is retrieved. Even worse, the temporary is an unnecessary `SparseMatrix` copy of the `MappedSparseMatrix`.

Maybe IterativeSolverBase::mp_matrix should be some kind of Ref<SparseMatrix> object (not supported yet, I guess?) and compute shall accept arbitrary Matrices, which are either copied or mapped into mp_matrix.

NB: The problem was exposed after new unit tests from bug 670.
Comment 1 Christoph Hertzberg 2014-10-21 15:55:44 UTC
Addendum: In general, all sparse solvers could accept SparseMatrixBase<...> directly in order to avoid unnecessary copies of MappedSparseMatrices. Some matrices still require copying, so some kind of Nested<> mechanism might be required. The latter is not too important, since performance impact of copying a matrix is usually rather small compared to decomposing.

Another note: For iterative solvers the name `compute` is a bit misleading (since no actual computation happens), but I guess we shall keep that name for consistency.
Comment 2 Gael Guennebaud 2014-10-21 17:17:57 UTC
Right, a Ref<SparseMatrix> is definitely what we need here.

Regrading the name 'compute', we kept it for consistency with other factorization based solver classes, and for iterative solvers you can read it as 'compute the pre-conditioner' which in most cases boils known to some kind of decompositions (incomplete factorization, diag+rest, L+D+U, etc.)
Comment 3 Christoph Hertzberg 2014-10-28 13:53:09 UTC
umfpack_support fails as well for mapped matrices, because by default it iteratively refines its result.
Comment 4 Gael Guennebaud 2014-12-02 14:01:55 UTC
Internally, UmfPackLU already used something like a Ref<SparseMatrix>, so fixing it properly was easy:
Changeset:   8ba3b2cf2df8
User:        ggael
Date:        2014-12-02 12:57:13+00:00
Summary:     Bug 897: fix UmfPack usage with mapped sparse matrices

Comment 5 Gael Guennebaud 2015-02-09 11:43:48 UTC
Done for conjugate gradient and BiCGSTAB:

Still have to fix the unsupported ones.
Comment 6 Gael Guennebaud 2015-02-16 15:26:32 UTC
For the unsupported ones (*RES):
Comment 7 Christoph Hertzberg 2015-02-16 15:34:33 UTC
There is a little problem left when IterativeSolverBase is constructed by directly passing the matrix which is to be solved.
We could either allow Ref to be default-constructed (Referring to an empty matrix) -- that would also avoid the m_dummy member -- or just copy the behavior of the default constructor of IterativeSolverBase.
This is not covered by unit tests, but causes the documentation not to build, because this line causes an error:
Comment 8 Gael Guennebaud 2015-02-16 17:09:33 UTC
Summary:     Bug 897: fix regression in BiCGSTAB(mat) ctor (an all other iterative solvers).
Add respective regression unit test.

If we strive to make Ref<> as close as possible to a C++ reference, then we should stick to the dirty 'dummy' trick.
Comment 9 Gael Guennebaud 2015-06-09 21:30:09 UTC
Summary:     Bug 897: make umfpack support use Ref<>
Comment 10 Nobody 2019-12-04 13:51:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance:

Note You need to log in before you can comment on or make changes to this bug.