[eigen] Organization of the sparse module(s)

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


I'm in the process of moving the few sparse solvers currently spread
in the unsupported folder into official Eigen/ folder. So the question
is about the granularity of the module I'll create for that. For
consistency reason, the Sparse module should include everything that
is related to sparse and built-in. "Support" modules have to stay into
isolated modules. Here is the list of features with a proposal for an

* SparseCore *
- representation, manipulation,
- coefficient-wise operations, products (sparse-sparse, sparse-dense,
- triangular solvers
- ordering methods (currently AMD=approximate minimum degree only)

* SimplicialFactorizations *
- direct LLT and LDLt decompositions and solving for SPD sparse matrices,
- two classes: SimplicialLLt and SimplicialLDLt
- future: direct simplicial LU and QR factorization and solver

* IterativeLinearSolvers *
- ConjugateGradient (Iterative solver for Ax=b with A SPD)
- BiCGSTAB (Iterative solver for A square)
- Basic preconditioners:
  - IdentityPreconditioner
  - DiagonalPreconditioner (= Jacobi preconditioner)
  - future: SSOR, ILUT

Three support modules:
* SuperLUSupport *
* CholmodSupport *
* UmfPackSupport *
future: MumpsSupport, PastixSupport, MetisSupport, ScotchSupport, etc.

Future could add some new modules:

* ConstrainedLinearSolvers *
 - for both dense and sparse worlds

* <a generic word for multifrontal and supernodal>Factorizations *
 - Fast direct LLt and LU factorizations based on supernodes or
multifrontal approaches (automatically make use of dense matrix

Any opinion about this granularity? Another options for the direct
solvers would be to organize them into three modules:
DirectSparseCholesky, DirectSparseLU, DirectSparseQR.



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/