Thyra::LinearOpWithSolveBase< RangeScalar, DomainScalar > Class Template Reference

Base class for all linear operators that can support a high-level solve operation. More...

#include <Thyra_LinearOpWithSolveBaseDecl.hpp>

Inheritance diagram for Thyra::LinearOpWithSolveBase< RangeScalar, DomainScalar >:

Inheritance graph
[legend]
List of all members.

Pure virtual functions that must be overridden in subclasses

virtual void solve (const EConj conj, const MultiVectorBase< RangeScalar > &B, MultiVectorBase< DomainScalar > *X, const int numBlocks=0, const BlockSolveCriteria< PromotedScalar > blockSolveCriteria[]=NULL, SolveStatus< PromotedScalar > blockSolveStatus[]=NULL) const =0
 Request the forward solution of a block system with different targeted solution criteria.

Virtual functions with default implementations

virtual bool solveSupportsConj (EConj conj) const
 Return if solve() supports the argument conj.
virtual bool solveTransposeSupportsConj (EConj conj) const
 Return if solveTranspose() supports the argument conj.
virtual bool solveSupportsSolveMeasureType (EConj conj, const SolveMeasureType &solveMeasureType) const
 Return if solve() supports the given the solve measure type.
virtual bool solveTransposeSupportsSolveMeasureType (EConj conj, const SolveMeasureType &solveMeasureType) const
 Return if solveTranspose() supports the given the solve measure type.
virtual void solveTranspose (const EConj conj, const MultiVectorBase< DomainScalar > &B, MultiVectorBase< RangeScalar > *X, const int numBlocks=0, const BlockSolveCriteria< PromotedScalar > blockSolveCriteria[]=NULL, SolveStatus< PromotedScalar > blockSolveStatus[]=NULL) const
 Request the transpose (or adjoint) solution of a block system with different targeted solution criteria.

Public Types

typedef Teuchos::PromotionTraits<
RangeScalar, DomainScalar
>::promote 
PromotedScalar
 Local typedef for promoted scalar type.

Detailed Description

template<class RangeScalar, class DomainScalar = RangeScalar>
class Thyra::LinearOpWithSolveBase< RangeScalar, DomainScalar >

Base class for all linear operators that can support a high-level solve operation.

Outline

Introduction

This interface supports linear operators (with potentially different range and domain scalar types) that can also support a forward solve operation (using solve()) of the form:

\[ A X = B \]

and/or a transpose solve operation (using solveTranspose()) of the form:

\[ A^T X = B \]

and/or an adjoint solve operation (using solveTranspose()) of the form:

\[ A^H X = B \]

where $A$ is *this linear operator, $B$ is an appropriate RHS multi-vector with $m$ columns, and $X$ is a LHS multi-vector with $m$ columns that is computed by this interface. Note that if the underlying operator has real-valued entries then the transpose $A^T$ and the adjoint $A^H$ are the same.

Note that this interface does not assume that the linear operator itself is nonsingular or invertible in the classic sense (i.e. an inverse operator may not exist).

Let $op(A)$ signify either the forward operator $A$, the transpose operator $A^T$ or the adjoint operator $A^H$. What this interface assumes is that for any appropriately selected consistent multi-vector RHS B that a solve of $A X = B$ will yield an approximate solution LHS multi-vector X such that A X == B. Note that this interface does not assume that a solution $X$ can be computed for any random RHS multi-vector $B$. Solutions for any random RHS can on be expected for relatively well conditioned non-singular operators.

Note: It is recommended that clients use the non-member helper functions defined here rather than call these member functions directly as they support a number of other simpler use cases.

Solve Criteria

This interface potentially allows clients to specify a relative tolerance on either the relative residual norm or the relative norm of the solution error and can target different solution criteria to different blocks of linear systems. This interface tries to allow for mathematically rigorous solution tolerances that are not based only any implementation-dependent features like the number of iterations of some solver algorithm. This interface, however, allows *this operator to exclude support certain types of solve measures (see the functions solveSupportsSolveMeasureType() and solveTransposeSupportsSolveMeasureType()). Also, this interface assumes that all implementations can support a "default" solve criteria that is determined internally to *this.

This interface is meant to support direct and iterative linear solvers as well as combinations of the two in a variety of configurations. Because of the almost infinite number of types of linear solver configurations possible, this interface tries not to specify any particular solver-specific solution control options. The one exception is a maximum number of iterations which is totally implementation defined. These types of control options are better specified in lower lever implementations and should be kept out of an interface such as this.

The functions solve() and solveTranspose() both take the arguments:

    ,const int                                    numBlocks             = 0
    ,const BlockSolveCriteria<PromotedScalar>     blockSolveCriteria[]  = NULL
    ,SolveStatus<PromotedScalar>                  blockSolveStatus[]    = NULL

The array arguments blockSolveCriteria[] and blockSolveStatus[] specify different blocks of solution criteria and the corresponding solve return statuses for a partitioned set of linear systems. Assuming that the client passes in arrays of dimensions $N=$numBlocks, these tolerances define the solution criteria for the block systems:

\[ op(A) \left[ \begin{array}{ccccc} X_{(:,0:i_1)} & X_{(:,i_1+1:i_2)} & \ldots & X_{(:,i_{N-1}+1:i_N)} \end{array} \right] = \left[ \begin{array}{ccccc} B_{(:,0:i_1)} & B_{(:,i_1+1:i_2)} & \ldots & B_{(:,i_{N-1}+1:i_N)} \end{array} \right] \]

where the column indexes are given by $i_j = \left( \sum_{k=0}^{j} \mbox{blockSolveCriteria[k].numRhs} \right)$, for $j = 0 \ldots N-1$.

The solve criteria for the $j^{\mbox{th}}$ block system

\[ op(A) X_{(:,i_{j}+1:i_j)} = B_{(:,i_{j}+1:i_j)} \]

is given by blockSolveCriteria[j] (if blockSolveCriteria!=NULL) and the solution status after return is given by blockSolveStatus[j] (if blockSolveStatus!=NULL).

By specifying solution criteria in blocks and then only requesting basic tolerances, we allow linear solver implementations every opportunity to perform as many optimizations as possible in solving the linear systems. For example, SVD could be performed on each block of RHSs and then a reduced set of linear systems could be solved.

For the remainder of this discussion we will focus on how the solution criteria for single block of linear systems specified by a single BlockSolveCriteria object is specified and how the status of this block linear solve is reported in a SolveStatus object.

The struct BlockSolveCriteria contains a SolveCriteria member and a number of RHSs that it applies to. It is the SolveCriteria object that determines the type and tolerance of a block solve request.

Let solveCriteria be a SolveCriteria object setup by a client to be passed into a solve operation. This object can be set up in a variety of ways to support several different use cases which are described below:

Solve Status

After the solve() and solveTranspose() functions return, the client can optionally get back a solution status for each block of linear systems for of block solve criteria. Specifically, for each block of linear systems

\[ A X_{(:,i_{j}+1:i_j)} = B_{(:,i_{j}+1:i_j)} \]

whose solution criteria is specified by a SolveCriteria object, a SolveStatus object can optionally be returned that lets the client know the status of the linear solve.

A note about direct solvers is in order. The "inexact" solve features of this interface are primarily designed to support "loose" solve tolerances that exploit the properties of iterative linear solvers. With that said, any decent direct solver can assume that it has met the convergence criteria as requested by the client but does not have to return an estimate of the actual tolerance achieved.

If solveStatus is a SolveStatus object returned for the above block linear system the the following return status are significant:

The implementation of the function accumulateSolveStatus() defines how to accumulate the individual solve status for each RHS in a block into the overall solve status for an entire block returned by blockSolveStatus[].

Use cases

This interface supports a variety of use cases where where described, more or less, in the above sections. Here, we give specific examples for a number of important use cases and show how to use the non-member helper functions defined here.

ToDo: Finish documentation!

Notes to subclass developers

This interface assumes, by default, that subclasses will only support the forward solve operation in which case only a single virtual function solve() must be overridden. See LinearOpBase for what other virtual functions must be overridden to define a concrete subclass.

Definition at line 339 of file Thyra_LinearOpWithSolveBaseDecl.hpp.


Member Typedef Documentation

template<class RangeScalar, class DomainScalar = RangeScalar>
typedef Teuchos::PromotionTraits<RangeScalar,DomainScalar>::promote Thyra::LinearOpWithSolveBase< RangeScalar, DomainScalar >::PromotedScalar

Local typedef for promoted scalar type.

Definition at line 346 of file Thyra_LinearOpWithSolveBaseDecl.hpp.


Member Function Documentation

template<class RangeScalar, class DomainScalar = RangeScalar>
virtual void Thyra::LinearOpWithSolveBase< RangeScalar, DomainScalar >::solve ( const EConj  conj,
const MultiVectorBase< RangeScalar > &  B,
MultiVectorBase< DomainScalar > *  X,
const int  numBlocks = 0,
const BlockSolveCriteria< PromotedScalar blockSolveCriteria[] = NULL,
SolveStatus< PromotedScalar blockSolveStatus[] = NULL 
) const [pure virtual]

Request the forward solution of a block system with different targeted solution criteria.

Parameters:
conj [in] Determines if the elements are non-conjugate (NONCONJ_ELE) or conjugate (CONJ_ELE). For real valued operator, this argument is meaningless. Most ANAs will request NONCONJ_ELE.
B [in] The RHS multi-vector with m = B.domain()->dim() columns.
X [in/out] The LHS multi-vector with with m = X->domain()->dim() columns. On input, contains the initial guess for the solution (only significant for iterative solvers) and on output contains an estimate of the solution.
numBlocks [in] The number of blocks for which solve tolerances will be specified for. If numBlocks==0 then this is a flag that a default set of tolerances should be used for all the linear systems. Default numBlocks=0.
blockSolveCriteria [in] Array (length numBlocks) which gives the desired solution criteria for each of the numBlocks blocks of RHS. If numBlocks>0 then this argument must be non-NULL and point to a valid array of numBlocks entries.
blockSolveStatus [out] Array (length numBlocks) which gives the status of each set of block systems. A value of blockSolveStatus==NULL is allowed and means that the client is not interested in solution status of the linear systems.
Preconditions:

Postconditions:

See the above introduction for a more complete description of how this function behaves and the meaning of the arguments blockSolveCriteria[] and blockSolveStatus[].

template<class RangeScalar, class DomainScalar>
bool Thyra::LinearOpWithSolveBase< RangeScalar, DomainScalar >::solveSupportsConj ( EConj  conj  )  const [virtual]

Return if solve() supports the argument conj.

The default implementation returns true for real valued scalar types or when conj==NONCONJ_ELE for complex valued types.

Definition at line 38 of file Thyra_LinearOpWithSolveBase.hpp.

template<class RangeScalar, class DomainScalar>
bool Thyra::LinearOpWithSolveBase< RangeScalar, DomainScalar >::solveTransposeSupportsConj ( EConj  conj  )  const [virtual]

Return if solveTranspose() supports the argument conj.

The default implementation returns false.

Definition at line 44 of file Thyra_LinearOpWithSolveBase.hpp.

template<class RangeScalar, class DomainScalar>
bool Thyra::LinearOpWithSolveBase< RangeScalar, DomainScalar >::solveSupportsSolveMeasureType ( EConj  conj,
const SolveMeasureType solveMeasureType 
) const [virtual]

Return if solve() supports the given the solve measure type.

The default implementation returns true for solveMeasureType.inNone().

Definition at line 50 of file Thyra_LinearOpWithSolveBase.hpp.

template<class RangeScalar, class DomainScalar>
bool Thyra::LinearOpWithSolveBase< RangeScalar, DomainScalar >::solveTransposeSupportsSolveMeasureType ( EConj  conj,
const SolveMeasureType solveMeasureType 
) const [virtual]

Return if solveTranspose() supports the given the solve measure type.

The default implementation returns true for solveMeasureType.inNone().

Definition at line 56 of file Thyra_LinearOpWithSolveBase.hpp.

template<class RangeScalar, class DomainScalar>
void Thyra::LinearOpWithSolveBase< RangeScalar, DomainScalar >::solveTranspose ( const EConj  conj,
const MultiVectorBase< DomainScalar > &  B,
MultiVectorBase< RangeScalar > *  X,
const int  numBlocks = 0,
const BlockSolveCriteria< PromotedScalar blockSolveCriteria[] = NULL,
SolveStatus< PromotedScalar blockSolveStatus[] = NULL 
) const [virtual]

Request the transpose (or adjoint) solution of a block system with different targeted solution criteria.

Parameters:
conj [in] Determines if the elements are non-conjugate (NONCONJ_ELE) or conjugate (CONJ_ELE). For real valued operator, this argument is meaningless. The transpose solve is requested with conj==NONCONJ_ELE and the adjoint solve is requested with conj==CONJ_ELE.
B [in] The RHS multi-vector with m = B.domain()->dim() columns.
X [in/out] The LHS multi-vector with with m = X->domain()->dim() columns. On input, contains the initial guess for the solution (only significant for iterative solvers) and on output contains an estimate of the solution.
numBlocks [in] The number of blocks for which solve tolerances will be specified for. If numBlocks==0 then this is a flag that a default set of tolerances should be used for all the linear systems. Default numBlocks=0.
blockSolveCriteria [in] Array (length numBlocks) which gives the desired solution criteria for each of the numBlocks blocks of RHS. If numBlocks>0 then this argument must be non-NULL and point to a valid array of numBlocks entries.
blockSolveStatus [out] Array (length numBlocks) which gives the status of each set of block systems. A value of blockSolveStatus==NULL is allowed and means that the client is not interested in solution status of the linear systems.
Preconditions:

Postconditions:

See the above introduction for a more complete description of how this function behaves and the meaning of the arguments blockSolveCriteria[] and blockSolveStatus[].

Definition at line 62 of file Thyra_LinearOpWithSolveBase.hpp.


The documentation for this class was generated from the following files:
Generated on Wed May 12 21:26:41 2010 for Thyra ANA Operator Solve Interfaces by  doxygen 1.4.7