Direct sparse solver calling MUMPS. More...
#include <string>#include <vector>#include <tuple>#include <numeric>#include <limits>#include <algorithm>#include <functional>#include <chrono>#include <iostream>#include <cstring>#include <cmath>#include <memory>#include <optional>#include <dune/common/exceptions.hh>#include <dune/common/indices.hh>#include <dune/common/hybridutilities.hh>#include <dune/common/parallel/mpihelper.hh>#include <dune/istl/bvector.hh>#include <dune/istl/bcrsmatrix.hh>#include <dune/istl/solver.hh>#include <dune/istl/solvercategory.hh>#include <dumux/common/parameters.hh>#include <dumux/linear/solver.hh>#include <dumux/linear/solvercategory.hh>#include <dumux/linear/parallelhelpers.hh>#include <dumux/linear/linearsolvertraits.hh>#include <dumux/linear/matrixconverter.hh>#include <dumux/common/typetraits/matrix.hh>#include <dumux/common/typetraits/vector.hh>#include <dumux/parallel/vectorcommdatahandle.hh>Go to the source code of this file.
Supports single-domain (BCRSMatrix/BlockVector) systems and MultiType/multidomain systems (flattened to scalar via MatrixConverter/VectorConverter), sequential and parallel (non-overlapping and overlapping) decompositions.
The multidomain support is agnostic to the number of subdomains and allows each subdomain to live on its own grid (e.g. a coupled free-flow / porous-medium problem with momentum, mass and Darcy subdomains on two different grids). The parallel constructor takes a tuple of the subdomain grid geometries (in the same order as the MultiTypeBlockVector subvectors); the sequential path needs no grid information and is N-agnostic by construction (it just flattens and renumbers the global system).
Single-domain systems are solved in parallel runs by the constructor taking a grid view and a dof mapper; the constructor without them is for sequential runs. The constructor that takes grid geometries (multidomain) requires linear solver traits that can communicate (e.g. LinearSolverTraits<GridGeometry>). In parallel runs, the dof mapper of every subdomain has to support the generic grid communication, which the face-centered staggered discretization does not provide: such subdomains are supported in sequential runs only.
The symbolic analysis is reused as long as the matrix keeps its size and sparsity pattern and is repeated automatically otherwise. The numeric factorization of the matrix given to setMatrix is reused by every solve(x, b), also for several right-hand sides at once; solve(A, x, b) factorizes A. In parallel runs, the dof maps depend on the grid: after the grid changed (e.g. grid adaption or load balancing), call updateAfterGridAdaption.
This solver backend requires MPI (even for sequential runs, using MPI_COMM_SELF).