Epetra_CrsKundertSparse Class Reference
Epetra_CrsKundertSparse: Solves an Epetra_LinearProblem using the solver "Sparse" from ChiliSpice.
More...
#include <Epetra_CrsKundertSparse.h>
Collaboration diagram for Epetra_CrsKundertSparse:
[legend]List of all members.
Detailed Description
Epetra_CrsKundertSparse: Solves an Epetra_LinearProblem using the solver "Sparse" from ChiliSpice.
Epetra_CrsKundertSparse solves a fullydefined Epetra_LinearProblem (see the Epetra user documentation) using an optimized version of Ken Kundert's sparse solver called Sparse.
A fullydefined Epetra_LinearProblem is an Epetra_LinearProblem instance with the Epetra_RowMatrix and the RHS and LHS Epetra_MultiVectors defined and compatible with each other. If one or more of these attributes is not defined, indeterminant behavior may occur.
Kundert's sparse solver was developed as part of the circuit simulation code called Spice. Sandia National Labs has developed an optimized version of this code called ChiliSpice. As part of the development of ChiliSpice, Kundert's solver was also optimized, with most of the work being done by Dave Shirley. Questions about the C code in this directory are probably best answered by Dr. Shirley (dnshirl@sandia.gov).
Epetra_CrsKundertSparse is a wrapper around Sparse that takes an Epetra_LinearProblem and solves it. This class is designed to support repeated calls to the Solve() method where each time Solve() is called the matrix has identical structure to the initial matrix that was passed in to the Epetra_CrsKundertSparse constructor. The first call to Solve() tends to be very expensive relative to subsequent calls. This is because solver data structures are being allocated and because the initial (Markowitz) reordering is being computed. Occasionally, a subsequent call may be expensive because Sparse compares the diagonal values of the incoming matrix with values from the matrix for which the reordering was computed. If the incoming matrix values have changed "too much" then matrix reordering is computed again, and again the overhead cost is paid.
Epetra_CrsKundertSparse provides access to Sparse because Sparse has been proven a valuable solver for small matrices (order 1005000). Initial results show that SuperLU may be more effective than Sparse for larger problems.
Epetra_CrsKundertSparse is a serialonly solver. A shared memory parallel version of Sparse exists, but we do not support it at this time. It is possible to use Epetra_CrsKundertSparse for distributed memory linear problems by first collapsing the problem to one processor (easy to do with an Epetra_Import object). We will add this capability if needed in the future.
Constructor & Destructor Documentation
Epetra_CrsKundertSparse::Epetra_CrsKundertSparse 
( 
Epetra_LinearProblem * 
Problem, 


const double 
RelThreshold = 0.001 , 


const double 
AbsThreshold = 1.0E13 , 


const int 
DiagPivoting = 1 

) 



Construct an Epetra_CrsKundertSparse using a fullydefined Epetra_LinearProblem.
This constructor takes a fullydefined Epetra_LinearProblem and, optionally, values for the relative and absolute thresholds and diagonal pivots. The optional parameters are defined below using an excerpt from the internal documentation for Sparse.
 Parameters:

 Problem  (InOut)  An Epetra_LinearProblem with a welldefined Epetra_RowMatrix, RHS and LHS. 
 RelThreshold  (In)  This number determines what the pivot relative threshold will be. It should be between zero and one. If it is one then the pivoting method becomes complete pivoting, which is very slow and tends to fill up the matrix. If it is set close to zero the pivoting method becomes strict Markowitz with no threshold. The pivot threshold is used to eliminate pivot candidates that would cause excessive element growth if they were used. Element growth is the cause of roundoff error. Element growth occurs even in wellconditioned matrices. Setting the RelThreshold large will reduce element growth and roundoff error, but setting it too large will cause execution time to be excessive and will result in a large number of fillins. If this occurs, accuracy can actually be degraded because of the large number of operations required on the matrix due to the large number of fillins. A good value seems to be 0.001. The default is chosen by giving a value larger than one or less than or equal to zero. This value should be increased and the matrix resolved if growth is found to be excessive. Changing the pivot threshold does not improve performance on matrices where growth is low, as is often the case with illconditioned matrices. Once a valid threshold is given, it becomes the new default. The default value of RelThreshold was choosen for use with nearly diagonally dominant matrices such as node and modifiednode admittance matrices. For these matrices it is usually best to use diagonal pivoting. For matrices without a strong diagonal, it is usually best to use a larger threshold, such as 0.01 or 0.1. 
 AbsThreshold  (In)  The absolute magnitude an element must have to be considered as a pivot candidate, except as a last resort. This number should be set significantly smaller than the smallest diagonal element that is is expected to be placed in the matrix. If there is no reasonable prediction for the lower bound on these elements, then AbsThreshold should be set to zero. AbsThreshold is used to reduce the possibility of choosing as a pivot an element that has suffered heavy cancellation and as a result mainly consists of roundoff error. Once a valid threshold is given, it becomes the new default. 
 DiagPivoting  (In)  A flag indicating that pivot selection should be confined to the diagonal if possible. If DiagPivoting is nonzero and if DIAGONAL_PIVOTING is enabled pivots will be chosen only from the diagonal unless there are no diagonal elements that satisfy the threshold criteria. Otherwise, the entire reduced submatrix is searched when looking for a pivot. The diagonal pivoting in Sparse is efficient and well refined, while the offdiagonal pivoting is not. For symmetric and near symmetric matrices, it is best to use diagonal pivoting because it results in the best performance when reordering the matrix and when factoring the matrix without ordering. If there is a considerable amount of nonsymmetry in the matrix, then offdiagonal pivoting may result in a better equation ordering simply because there are more pivot candidates to choose from. A better ordering results in faster subsequent factorizations. However, the initial pivot selection process takes considerably longer for offdiagonal pivoting. 

Member Function Documentation
int Epetra_CrsKundertSparse::Solve 
( 
const bool 
ComputeFactor = true 
) 



Solves the current Epetra_LinearProblem using the Sparse solver from ChiliSpice.
Given a welldefined Epetra_LinearProblem, this method will return the solution in the LHS multivector (currently only works with a multivector containing one vector). Typically Solve() is called many times, each time with a new Epetra_LinearProblem where the pattern of the matrix is identical but the values have changed. The first call to Solve() is typically very expensive relative to subsequent calls, because a onetime reordering is performed.  Parameters:

 ComputeFactor  (In)  A bool flag. If true, factorization will be computed prior to computing forward/back solve for the given RHS/LHS. If false and a factorization has already been computed, only the forward/back solve will be performed for the given RHS/LHS. If a factorization has never been performed, the factorization will be computed regardless of the value of this parameter. The default value for this parameter is true. 

The documentation for this class was generated from the following files:
 Epetra_CrsKundertSparse.h
 Epetra_CrsKundertSparse.cpp
Generated on Thu Sep 18 12:39:26 2008 for Amesos by 1.3.9.1