Reset the subdomain solver, clearing its caches related to the linear operator it has solved so far. More...
#include <ResetSubdomainSolver.hpp>
Public Types | |
| using | const_global_cache_tags = implementation defined |
Static Public Member Functions | |
| template<typename DbTagsList , typename... InboxTags, typename Metavariables , size_t Dim, typename ActionList , typename ParallelComponent > | |
| static Parallel::iterable_action_return_t | apply (db::DataBox< DbTagsList > &box, const tuples::TaggedTuple< InboxTags... > &, const Parallel::GlobalCache< Metavariables > &, const ElementId< Dim > &element_id, const ActionList, const ParallelComponent *const) |
Reset the subdomain solver, clearing its caches related to the linear operator it has solved so far.
Invoke this action when the linear operator has changed. For example, an operator representing the linearization of a nonlinear operator changes whenever the point around which it is being linearized gets updated, i.e. in every iteration of a nonlinear solve. Note that the operator does not change between iterations of a linear solve, so make sure you place this action outside the looping action list for the linear solve.
LinearSolver::Serial::ExplicitInverse solver for an example of a subdomain solver with high initialization cost. For this reason the reset can be skipped with the option LinearSolver::Schwarz::Tags::SkipSubdomainSolverResets. Skipping resets means that caches built up for the linear operator are never cleared, so expensive re-initializations are avoided but the subdomain solves may be increasingly inaccurate or slow down as the linear operator changes over nonlinear solver iterations. Whether or not skipping resets helps with the overall convergence of the solve is highly problem-dependent. A possible optimization would be to decide at runtime whether or not to reset the subdomain solver.