There was a overzealous DCHECK in suitesparse.cc when converting
a scalar matrix into a block matrix. This stemmed from my poor
understanding of how lower_bound works.
The test for this function was not stringent enough, and was
not run in debug mode for this to get triggered. The test
has been updated, it fails without the fix and runs correctly
with it.
Thanks to Markus Moll for reporting this and suggesting the
fix.
Change-Id: Ide6b971fd4c618ef5e240f500f514c4b78d7b6e3
By virtue of the modeling layer in Ceres being block oriented,
all the matrices used by Ceres are also block oriented.
When doing sparse direct factorization of these matrices, the
fill-reducing ordering algorithms can either be run on the
block or the scalar form of these matrices. Running it on the
block form exposes more of the super-nodal structure of the
matrix to the Cholesky factorization routines. This leads to
substantial gains in factorization performance.
This changelist adds support for approximate minimium degree
orderings to be computed on the block structure of the
Schur complement matrix. This affects, SchurComplementSolver
and VisibilityBasedPreconditioner and SparseNormalCholesky
when using SuiteSparse.
A bool, use_block_amd has been added to Solver::Options and
bundle_adjuster.cc has been updated to allow testing with it.
When combined with a multithreaded Schur elimination, speed ups
can be seen quite uniformly across the board. For some problems
this can be dramatic, reducing the factorization time from 70
seconds down to 17 seconds.
Change-Id: I15ebb0afcbc85ada032ec8d179ee3a2f7c8d3e46
Sameer Agarwal