Teuchos Package Browser (Single Doxygen Collection)
Version of the Day
|
Interface for a "factory" that creates solvers. More...
#include <Trilinos_Details_LinearSolverFactory.hpp>
Public Member Functions | |
virtual | ~LinearSolverFactory () |
virtual Teuchos::RCP < LinearSolver< MV, OP, NormType > > | getLinearSolver (const std::string &solverName)=0 |
Get an instance of a solver from a particular package. More... | |
Interface for a "factory" that creates solvers.
MV | Type of a (multi)vector, representing either the solution(s) X or the right-hand side(s) B of a linear system AX=B. For example, with Tpetra, use a Tpetra::MultiVector specialization. A multivector is a single data structure containing zero or more vectors with the same dimensions and layout. |
OP | Type of a matrix or linear operator that the LinearSolver to create understands. For example, for Tpetra, use a Tpetra::Operator specialization. |
NormType | Type of the norm of the residual. See the documentation of LinearSolver for details. |
Every package that implements solvers needs to implement a concrete LinearSolverFactory subclass as well. That subclass knows how to create all the solvers which that package implements. The package must register a LinearSolverFactory instance using registerLinearSolverFactory() (see below). Then, any package may access that package's solvers, using getLinearSolver() (see above).
You do not need to worry about "de-registering" or deallocating LinearSolverFactory instances; std::shared_ptr takes care of that automatically, after main() finishes. LinearSolverFactory instances should not hold on to resources that need explicit deallocation or "finalization," such as MPI_* data structures (that need to be "freed" before MPI_Finalize() is called) or open file handles.
If you have a compelling use case that requires explicit finalization of a LinearSolverFactory instance at some point before main() finishes, please talk to the Trilinos developers about adding a deregisterLinearSolverFactory() function (which does not exist yet).
In the Tpetra solver stack, it's necessary to register factories for all combinations of template parameters that applications plan to use. The easiest way to do that is to hook into the explicit template instantiation (ETI) system of each package. If ETI is ON, this is easy. If ETI is OFF, it's a bit harder. Tpetra defines a set of template parameter combinations over which it tests. If ETI is ON, this is always a subset of the ETI set. If ETI is OFF, I would recommend using this set of test types for registering factories. Do the following:
Definition at line 203 of file Trilinos_Details_LinearSolverFactory.hpp.
|
inlinevirtual |
Definition at line 205 of file Trilinos_Details_LinearSolverFactory.hpp.
|
pure virtual |
Get an instance of a solver from a particular package.
solverName | [in] The solver's name. Names are case sensitive. |
Implemented in A::FactoryA< MV, OP, NormType >, B::FactoryB< MV, OP, NormType >, and C::FactoryC< MV, OP, NormType >.