simplify and cleanup the SolverFactory
This MR simplifies the SolverFactory. This includes the following changes:
- Unification of the creator interface. All creators (solvers and preconditioners) now get the new type
OperatorTraits
and ashared_ptr<LinearOperator<X,Y>>
. This has the advantage, that all available information is passed to the creator and can be accessed easily via theOperatorTraits
. In particular, it is also possible for an iterative solver creator to access the matrix. This was not possible before as the actual operator type was not passed to the creator. - The
OperatorTraits
replace theTypeList
that was passed to the creators before. This makes the code far more readable as the type can be accessed by their names instead of a list index. - Direct and iterative solvers are no longer kept in separate factories. The reason for keeping them separate was the need of the direct solver to access the matrix. This can now be achieved via the
OperatorTraits
.
Open questions regarding backward-compatibility:
-
Do we need backward compatibility to the old creator interface? For the direct and iterative solvers, we could add easily the old macrosDUNE_REGISTER_ITERARIVE_SOLVER
andDUNE_REGISTER_DIRECT_SOLVER
the wrap a provided old interface creator to the new interface.I'm not sure how to deal withDUNE_REGISTER_PRECONDITIONER
.- I added the old macros again and make
OperatorTraits
compatible toTypeList<matrix_tpye, domain_type, range_type>
so that the old interface can be used. For theDUNE_REGISTER_ITERATIVE_SOLVER
i added a wrapper that translates the creator to the new interface.
-
The method getSolverFromFactory
had a third parameter before to inject a precreated preconditioner. This is now a bit more difficult as the preconditioner is created the the creator of the iterative solvers.Possible solution: Add asetPrecondititioner
method to theIterativeSolver
class, this could then be used to replace the preconditioner of the created iterative solver. With that we could implement a function with the same functionality as before.- I solved that by defining the passed preconditioner in the ProconditionerRegistry with a dummy tag (
__passed at runtime__
)
Edited by Nils-Arne Dreier
Merge request reports
Activity
- Resolved by Nils-Arne Dreier
added 50 commits
-
e4276a9f...fc2b7848 - 44 commits from branch
master
- 222135da - simplify and cleanup solverfactory
- d7a34bad - remove unused code
- 08109e44 - fix matrix checks for direct solvers
- 0d0fbb8d - fix matrix check for amg
- 5c2c9503 - fix default preconditioner creators
- d7920dab - add matrixfreesolverfactorytest
Toggle commit list-
e4276a9f...fc2b7848 - 44 commits from branch
added 14 commits
Toggle commit list- Resolved by Christian Engwer
I cleaned up the creators of the direct solvers further. Now the only question is whether we need backward compatibility for the Register macros
DUNE_REGISTER_DIRECT_SOLVER
,DUNE_REGISTER_ITERATIVE_SOLVER
andDUNE_REGISTER_PRECONDITIONER
?
added 1 commit
- 989df116 - add backward comptibility for the DUNE_REGISTER_... macros
We should probably first decide about !421 (merged) and rebase this MR on it.
mentioned in merge request !421 (merged)
added 26 commits
-
0c094f6b...729ec611 - 18 commits from branch
master
- fa4ff6e9 - simplify and cleanup solverfactory
- d43bd2fb - remove unused code
- dbeaf5ba - fix matrix checks for direct solvers
- dc31cf0d - fix matrix check for amg
- b4b0eb6e - fix default preconditioner creators
- 3e510145 - simplify direct creators
- e57c9121 - add backward comptibility for the DUNE_REGISTER_... macros
- 03ff5111 - deprecate old register macros
Toggle commit list-
0c094f6b...729ec611 - 18 commits from branch
mentioned in merge request !428 (closed)
mentioned in merge request !422
added 18 commits
-
03ff5111...9dae4be7 - 9 commits from branch
master
- 912fcd41 - simplify and cleanup solverfactory
- bbdb52bc - remove unused code
- 0f82c750 - fix matrix checks for direct solvers
- b0ec0224 - fix matrix check for amg
- d564d2f3 - fix default preconditioner creators
- aed9ac66 - simplify direct creators
- 0769adee - add backward comptibility for the DUNE_REGISTER_... macros
- b0263dfd - deprecate old register macros
- cc34f834 - assert sequential operator in creators of direct solvers
Toggle commit list-
03ff5111...9dae4be7 - 9 commits from branch
@christi I rebased and added the assertions for sequential operators in the creators of direct solvers.
Please register or sign in to reply