Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • D dune-istl
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 32
    • Issues 32
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 29
    • Merge requests 29
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Core ModulesCore Modules
  • dune-istl
  • Merge requests
  • !453

simplify and cleanup the SolverFactory

  • Review changes

  • Download
  • Patches
  • Plain diff
Open Nils-Arne Dreier requested to merge simplify_solverfactory into master Sep 13, 2021
  • Overview 13
  • Commits 9
  • Pipelines 8
  • Changes 14

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 a shared_ptr<LinearOperator<X,Y>>. This has the advantage, that all available information is passed to the creator and can be accessed easily via the OperatorTraits. 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 the TypeList 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 macros DUNE_REGISTER_ITERARIVE_SOLVER and DUNE_REGISTER_DIRECT_SOLVER the wrap a provided old interface creator to the new interface.
    • I'm not sure how to deal with DUNE_REGISTER_PRECONDITIONER.
    • I added the old macros again and make OperatorTraits compatible to TypeList<matrix_tpye, domain_type, range_type> so that the old interface can be used. For the DUNE_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 a setPrecondititioner method to the IterativeSolver 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 Feb 03, 2022 by Nils-Arne Dreier
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: simplify_solverfactory