spconfig.h

DTMK软件开发包,此为开源软件,是一款很好的医学图像开发资源.

/* CONFIGURATION MACRO DEFINITIONS for sparse matrix routines */
/*!
 *  \file
 *
 *  This file contains macros for the sparse matrix routines that are used
 *  to define the personality of the routines.  The user is expected to
 *  modify this file to maximize the performance of the routines with
 *  his/her matrices.
 *
 *  Macros are distinguished by using solely capital letters in their
 *  identifiers.  This contrasts with C defined identifiers which are
 *  strictly lower case, and program variable and procedure names which use
 *  both upper and lower case.
 *
 *  Objects that begin with the \a spc prefix are considered private
 *  and should not be used.
 *
 *  \author
 *  Kenneth S. Kundert <[e-mail]>
 */


/*
 *  Revision and copyright information.
 *
 *  Copyright (c) 1985-2003 by Kenneth S. Kundert
 *
 */


#ifndef spCONFIG_DEFS
#define spCONFIG_DEFS


#ifdef spINSIDE_SPARSE
/*
 *  OPTIONS
 *
 *  These are compiler options.  Set each option to one to compile that
 *  section of the code.  If a feature is not desired, set the macro
 *  to NO.
 */

/* Begin options. */

/* Arithmetic Precision
 *
 * The precision of the arithmetic used by Sparse can be set by
 * changing changing the spREAL macro.  This macro is
 * contained in the file spMatrix.h.  It is strongly suggested to
 * used double precision with circuit simulators.  Note that
 * because C always performs arithmetic operations in double
 * precision, the only benefit to using single precision is that
 * less storage is required.  There is often a noticeable speed
 * penalty when using single precision.  Sparse internally refers
 * to a spREAL as a RealNumber.
 */

/*!
 * This specifies that the routines are expected to handle real
 * systems of equations.  The routines can be compiled to handle
 * both real and complex systems at the same time, but there is a
 * slight speed and memory advantage if the routines are complied
 * to handle only real systems of equations.
 */
#define  REAL                           YES

/*!
 * Setting this compiler flag true (1) makes the matrix
 * expandable before it has been factored.  If the matrix is
 * expandable, then if an element is added that would be
 * considered out of bounds in the current matrix, the size of
 * the matrix is increased to hold that element.  As a result,
 * the size of the matrix need not be known before the matrix is
 * built.  The matrix can be allocated with size zero and expanded.
 */
#define  EXPANDABLE                     YES

/*!
 * This option allows the set of external row and column numbers
 * to be non-packed.  In other words, the row and column numbers
 * do not have to be contiguous.  The priced paid for this
 * flexibility is that when \a TRANSLATE is set true, the time
 * required to initially build the matrix will be greater because
 * the external row and column number must be translated into
 * internal equivalents.  This translation brings about other
 * benefits though.  First, the spGetElement() and
 * spGetAdmittance() routines may be used after the matrix has
 * been factored.  Further, elements, and even rows and columns,
 * may be added to the matrix, and row and columns may be deleted
 * from the matrix, after it has been factored.  Note that when
 * the set of row and column number is not a packed set, neither
 * are the \a RHS and \a Solution vectors.  Thus the size of these
 * vectors must be at least as large as the external size, which
 * is the value of the largest given row or column numbers.
 */
#define  TRANSLATE                      YES

/*!
 * Causes the spInitialize(), spGetInitInfo(), and
 * spInstallInitInfo() routines to be compiled.  These routines
 * allow the user to store and read one pointer in each nonzero
 * element in the matrix.  spInitialize() then calls a user
 * specified function for each structural nonzero in the matrix,
 * and includes this pointer as well as the external row and
 * column numbers as arguments.  This allows the user to write
 * custom matrix initialization routines.
 */
#define  INITIALIZE                     YES

/*!
 * Many matrices, and in particular node- and modified-node
 * admittance matrices, tend to be nearly symmetric and nearly
 * diagonally dominant.  For these matrices, it is a good idea to
 * select pivots from the diagonal.  With this option enabled,
 * this is exactly what happens, though if no satisfactory pivot
 * can be found on the diagonal, an off-diagonal pivot will be
 * used.  If this option is disabled, Sparse does not
 * preferentially search the diagonal.  Because of this, Sparse
 * has a wider variety of pivot candidates available, and so
 * presumably fewer fill-ins will be created.  However, the
 * initial pivot selection process will take considerably longer.
 * If working with node admittance matrices, or other matrices
 * with a strong diagonal, it is probably best to use
 * \a DIAGONAL_PIVOTING for two reasons.  First, accuracy will be
 * better because pivots will be chosen from the large diagonal
 * elements, thus reducing the chance of growth.  Second, a near
 * optimal ordering will be chosen quickly.  If the class of
 * matrices you are working with does not have a strong diagonal,
 * do not use \a DIAGONAL_PIVOTING, but consider using a larger
 * threshold.  When \a DIAGONAL_PIVOTING is turned off, the following
 * options and constants are not used: \a MODIFIED_MARKOWITZ,
 * \a MAX_MARKOWITZ_TIES, and \a TIES_MULTIPLIER.
 */
#define  DIAGONAL_PIVOTING              YES

/*!
 * This determines whether arrays start at an index of zero or one.
 * This option is necessitated by the fact that standard C
 * convention dictates that arrays begin with an index of zero but
 * the standard mathematic convention states that arrays begin with
 * an index of one.  So if you prefer to start your arrays with
 * zero, or your calling Sparse from FORTRAN, set ARRAY_OFFSET to
 * NO or 0.  Otherwise, set ARRAY_OFFSET to YES or 1.  Note that if
 * you use an offset of one, the arrays that you pass to Sparse
 * must have an allocated length of one plus the size of the
 * matrix.  ARRAY_OFFSET must be either 0 or 1, no other offsets
 * are valid.
 */
#define  ARRAY_OFFSET                   NOT FORTRAN

/*!
 * This specifies that the modified Markowitz method of pivot
 * selection is to be used.  The modified Markowitz method differs
 * from standard Markowitz in two ways.  First, under modified
 * Markowitz, the search for a pivot can be terminated early if a
 * adequate (in terms of sparsity) pivot candidate is found.
 * Thus, when using modified Markowitz, the initial factorization
 * can be faster, but at the expense of a suboptimal pivoting
 * order that may slow subsequent factorizations.  The second
 * difference is in the way modified Markowitz breaks Markowitz
 * ties.  When two or more elements are pivot candidates and they
 * all have the same Markowitz product, then the tie is broken by
 * choosing the element that is best numerically.  The numerically
 * best element is the one with the largest ratio of its magnitude
 * to the magnitude of the largest element in the same column,
 * excluding itself.  The modified Markowitz method results in
 * marginally better accuracy.  This option is most appropriate
 * for use when working with very large matrices where the initial
 * factor time represents an unacceptable burden. \a NO is recommended.
 */
#define  MODIFIED_MARKOWITZ             NO

/*!
 * This specifies that the spDeleteRowAndCol() routine
 * should be compiled.  Note that for this routine to be
 * compiled, both \a DELETE and \a TRANSLATE should be set true.
 */
#define  DELETE                         YES

/*!
 * This specifies that the spStripFills() routine should be compiled.
 */
#define  STRIP                          YES

/*!
 * This specifies that the routine that preorders modified node
 * admittance matrices should be compiled.  This routine results
 * in greater speed and accuracy if used with this type of
 * matrix.
 */
#define  MODIFIED_NODAL                 YES

/*!
 * This specifies that the routines that allow four related
 * elements to be entered into the matrix at once should be
 * compiled.  These elements are usually related to an
 * admittance.  The routines affected by \a QUAD_ELEMENT are the
 * spGetAdmittance(), spGetQuad() and spGetOnes() routines.
 */
#define  QUAD_ELEMENT                   YES

/*!
 * This specifies that the routines that solve the matrix as if
 * it was transposed should be compiled.  These routines are
 * useful when performing sensitivity analysis using the adjoint
 * method.
 */
#define  TRANSPOSE                      YES

/*!
 * This specifies that the routine that performs scaling on the
 * matrix should be complied.  Scaling is not strongly
 * supported.  The routine to scale the matrix is provided, but
 * no routines are provided to scale and descale the RHS and
 * Solution vectors.  It is suggested that if scaling is desired,
 * it only be preformed when the pivot order is being chosen [in
 * spOrderAndFactor()].  This is the only time scaling has
 * an effect.  The scaling may then either be removed from the
 * solution by the user or the scaled factors may simply be
 * thrown away. \a NO is recommended.
 */
#define  SCALING                        YES

/*!
 * This specifies that routines that are used to document the
 * matrix, such as spPrint() and spFileMatrix(), should be
 * compiled.
 */
#define  DOCUMENTATION                  YES

/*!
 * This specifies that routines that are used to multily the
 * matrix by a vector, such as spMultiply() and spMultTransposed(), should be
 * compiled.
 */
#define  MULTIPLICATION                 YES

/*!
 * This specifies that the routine spDeterminant() should be complied.
 */
#define  DETERMINANT                    YES

/*!
 * This specifies that spLargestElement() and spRoundoff() should
 * be compiled.  These routines are used to check the stability (and
 * hence the quality of the pivoting) of the factorization by
 * computing a bound on the size of the element is the matrix
 * \f$ E = A - LU \f$.  If this bound is very high after applying
 * spOrderAndFactor(), then the pivot threshold should be raised.
 * If the bound increases greatly after using spFactor(), then the
 * matrix should probably be reordered. Recomend \a NO.
 */
#define  STABILITY                      YES

/*!
 * This specifies that spCondition() and spNorm(), the code that
 * computes a good estimate of the condition number of the matrix,
 * should be compiled. Recomend \a NO.
 */
#define  CONDITION                      YES

/*!
 * This specifies that spPseudoCondition(), the code that computes
 * a crude and easily fooled indicator of ill-conditioning in the
 * matrix, should be compiled. Recomend \a NO.
 */
#define  PSEUDOCONDITION                YES

/*!
 * This specifies that the \a FORTRAN interface routines should be
 * compiled.  When interfacing to \a FORTRAN programs, the \a ARRAY_OFFSET
 * options should be set to NO.