- changed milestone to 1.5
Cleanup of linear solver logic needed
AL: The naming of linear solvers (direct, iterative, krylov, lu, gmres etc) is somewhat of a jungle and the parameter sets (krylov_solver, lu_solver) must match and do not really correspond to the solvers. This should be discussed on the mailing list and cleaned up (after the release of 1.3).
JB: Yes, there are plenty of defficienscis, for example: When DOLFIN is not compiled with CHOLMOD, then LinearSolver('cholesky') redirects to CholmodCholeskySolver which implements a fallback to UmfpackLUSolver. It should be discussed if LinearSolver('cholesky') should call rather LUSolver with symmetric=True option.
In PETScLUSolver::select_solver there is missing a logic for picking Cholesky-capable (as indicated by PETScLUSolver::_methods_cholesky) solver when symmetric=True.
Comments (13)
-
-
I wouldn't hurry with picking Cholesky whenever it could seem favourable. There is a bug in PETSc which affects default Cholesky-capable PETScLUSolver MUMPS. It's fixed but not yet released.
-
- changed milestone to 1.6
-
-
assigned issue to
- marked as task
-
assigned issue to
-
- changed milestone to 1.7
-
This is a symptom of the
GenericFoo
interface not being a good design for linear solvers. Solvers are too specialised for a viable and extensiveGenericFoo
interface. -
reporter I agree that the
GenericFoo
interface requires quite a bit of stretch to work for solvers.One option could be to remove all those interfaces to solvers and replace them with
PETScLinearSolver
etc in combination with the following two important points:-
Keep the very high level
solve()
interface to enablesolve(A, x, b, "gmres", "ilu")
without needing to care about la backend. -
Allow sending in a
Matrix
to the specialized solvers which could start by making adynamic_cast
to check whether solve is possible and otherwise issue an informative error message.
-
-
We could allow the PDE solve function
solve(a==L)
to optionally take a (non)linear solver. Linear solvers should be able to return a suitable matrix that is assembled into. A user can than set more advanced options on the solver object. This reduces the need for a collection of linear solvers to have an extensive common interface. -
reporter Yes, sounds like a good idea.
-
reporter - removed milestone
Removing milestone: 1.7 (automated comment)
-
- changed component to linear algebra
- changed milestone to 2016.2
This is largely complete on the backend side. Needs some polishing.
-
- changed milestone to 2017.1
-
- changed milestone to 2017.2
- Log in to comment