Skip to content

Feature/istl ini

Linus Seelinger requested to merge feature/istl-ini into master

Allow creating solvers / preconditioners from ParameterTrees.

A solver (including preconditioner) can now be configured via an ini file like this:

[solver]
precond = SeqSSOR
solver = CGSolver

[SeqSSOR]
iterations = 1
relaxation = 1.8

[CGSolver]
reduction=1e-9
maxit = 5000
verbose = 3

The corresponding dune code currently looks like this:

auto solver = SolverPrecondFactory::create<VectorType> (matrix, configuration, "solver");

Both the actual type of the solver/preconditioner and their parameters can chosen in the ini file.

It is also possible to create only a solver or only a preconditioner this way. See the factory doxygen for details.

Todo

  • Dynamic category for ScalarProduct
  • Use the IterativeSolver base class proposed by @christi

Open for debate

  • Remove old SolverCategory (Now that we have a dynamic category, should we remove/deprecate the static one?)
  • How to optimize compile time (As the factory supports creating all kinds of solvers, all these will be instantiated which takes time; in a simple example 2.5s vs 7s compile time. Library, extern template,...?)
  • Should the new generic factory concept of dune-common be used here?

Christian's and Steffen's brainstorming at Dune Course 2017

  • The only place that the categories get checked is in the constructor of the solvers etc. Thus, we might be able to still support unported objects that use the enum-based parallel categories. The idea would be to have a free-standing function solverCategory() that first looks for the enum, and if it can't find it, uses the new virtual function. All solvers would need to be changed to use this new function. Note: This
  • If an unported type still exports the old static enum category, that shadows the new category() function when accessing the derived type. This is dangerous! Do we want to keep the name anyway?
  • Use factory utilities from dune-common

Merge request reports