Trilinos::Details::LinearSolverFactory< MV, OP, NormType > Class Template Reference

Interface for a "factory" that creates solvers. More...

#include <Trilinos_Details_LinearSolverFactory.hpp>

Public Member Functions
virtual Teuchos::RCP < LinearSolver< MV, OP, NormType > >	getLinearSolver (const std::string &solverName)=0
	Get an instance of a solver from a particular package. More...

Detailed Description

template<class MV, class OP, class NormType>
class Trilinos::Details::LinearSolverFactory< MV, OP, NormType >

Interface for a "factory" that creates solvers.

Template Parameters

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:

1. Include TpetraCore_ETIHelperMacros.h (a header file that Tpetra's CMake configuration process generates and writes to the build directory)
2. In an anonymous outer namespace, define a class that registers your factory in its constructor. See PackageA.cpp in ../example/SolverFactory for an example. Then, define a macro that creates an instance of that class (see the bottom of PackageA.cpp).
3. In the same anonymous outer namespace, invoke the TPETRA_ETI_MANGLING_TYPEDEFS() macro to define typedefs used internally by #3
4. In the same anonymous outer namespace, use the TPETRA_INSTANTIATE_SLGN_NO_ORDINAL_SCALAR macro, passing in the name of your macro (see #2) as its one argument.

Definition at line 235 of file Trilinos_Details_LinearSolverFactory.hpp.

Member Function Documentation

template<class MV , class OP , class NormType >

virtual Teuchos::RCP<LinearSolver<MV, OP, NormType> > Trilinos::Details::LinearSolverFactory< MV, OP, NormType >::getLinearSolver ( const std::string &  solverName )

pure virtual

Get an instance of a solver from a particular package.

Parameters

solverName

[in] The solver's name. Names are case sensitive.

Returns

A pointer to the LinearSolver, if the name was valid; else, a null pointer.

---

The documentation for this class was generated from the following file:

• Trilinos_Details_LinearSolverFactory.hpp