#include <LinEqAdm.h>
Inheritance diagram for LinEqAdm::

NAME: LinEqAdm - user-friendly interface to the "LinEq*" classes for linear systems
DESCRIPTION:
This base class provides the basics of a user-friendly interface the various modules involved when solving a linear system of equations. In case of finite element solution of some partial differential equation, one should use the derived class "LinEqAdmFE" which contains functionality for assembly of the coefficient matrix and the right-hand side. There is also a derived class "LinEqAdmFD" specialized for finite difference cases.
|
|
The class can be used in three ways: Storage mode 1, "EXTERNAL_STORAGE" - All system data are allocated and assigned proper values outside the class. The quantities "A", "x", "b" and eventual preconditioners must be attached to class "LinEqAdm" by using the "attach" function. This mode is the most common when working with finite difference methods. Storage mode 2, "EXTERNAL_SOLUTION" - All system data, except the solution vector "x" are allocated internally. The solution vector must then be attached. This mode is used if the user has a field and want the grid point values of this field to be the solution vector in the system. Storage mode 3, "INTERNAL_STORAGE" - All system data ("A", "x", "b" and eventual preconditioners) are allocated internally. When using class "LinEqAdm" in finite element solvers, this is often the preferred mode. The constructor of class "LinEqAdm" takes the storage mode as argument. The menu and "scan" functions depend on the mode. For mode 1, there are no menu items and no scanning for parameters regarding the matrix type. |
|
|
See documentation of one of the overloaded constructor. |
|
|
|
|
|
returns the coefficient matrix as a "Matrix(NUMT)" object. |
|
|
returns the coefficient matrix as a "LinEqMatrix" object. |
|
|
tells the "LinEqAdm" object whether menu changes are allowed, i.e., if calls to "fullMenu" is allowed. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
function. It can be used to insert a user-supplied coefficient matrix, solution vector and right-hand side, depending on the chosen storage mode. In addition, there are "attach" function dealing with the insertion of preconditioner(s). When attaching a preconditioner, the user may do so explicitly or by handing over a "Precond_prm" object. In this latter case, the preconditioner is allocated internally. The optional parameters "Apb" or "Apb_mat" denote the basis for the construction of the preconditioner. Usually,this is the coefficient matrix "A" itself, for which the flag "Apb_is_A" should be set to "true". If the preconditioning basis is left out, it is assumed to be a user defined preconditioner with a trivial "PrecBasis" (that is, no matrix at all). This latter "attach" function aims at, e.g., user defined procedures ("PrecAction" functors) like FFT etc. There is also an "attach" function for insertion of a list of convergence monitors. |
|
|
|
|
|
returns the right-hand side as a "Vector(NUMT)" object. |
|
|
returns the right-hand side as a "LinEqVector" object. |
|
|
returns "true" if the coefficient matrix is to be computed, otherwise the return value will be "false". |
|
|
|
|
|
returns "true" if the preconditioner(s) is to be computed, otherwise the return value will be "false". |
|
|
returns "true" if the right-hand side is to be computed, otherwise the return value will be "false". |
|
|
|
|
|
prints all relevant information on the current "LinEqAdm" object. Its primary use is for debugging. If the argument "printMatVec" is true, the whole linear system is printed. This can be convenient for debugging the results of setting up the linear system. The information on preconditioners in the "LinEqAdm" object is not available before "solve" is called. Hence, calling "debugPrint" before "solve" may lead to output saying that there is no preconditioner etc. even though the user has chosen a preconditioner on the menu. A normal way of calling "debugPrint" is therefore to have "printMatVec" as true before "solve" is called, and false after "solve" is called. |
|
|
builds the "LinEqAdm" submenu and adds it to the specified menu system. The behaviour of "define" depends on the use of"fullMenu". Notice that there is also a static version of this function callled "defineStatic". Reimplemented in LinEqAdmFD, LinEqAdmFE, and LinEqAdmFV. |
|
|
Reimplemented in LinEqAdmFD, LinEqAdmFE, and LinEqAdmFV. |
|
|
|
|
|
|
|
|
The argument "onoff" determines whether use of full menus is "ON" or "OFF", i.e., whether menu items concerning preconditioners and convergence monitors should be displayed in the menu. These items are relevant only for iterative solvers. If not using full menus, the "scan" function will pop up an additional menu window for these items when an iterative solver has been requested. The second argument "maxNoMonitors" sets the number of "ConvMonitor_prm" submenus used to compose the "ConvMonitorList_prm" menu. This value has no meaning unless full menus are used. The default value is now 0 which means that there will not be any subsubmenu for controlling the convergence criterion of iterative solvers. Please note that "maxNoMonitors" only affects the building of menus. To actually use the corresponding convergence monitors, the menu item "no of external convergence monitors" in the "LinEqSolver_prm" submenu has to be set. If this parameter is set to some value "n" smaller than "maxNoMonitors", the "n" first "ConvMonitor_prm" submenus are scanned. |
|
|
returns "true" or "false" depending on whether full or short menu is requested. |
|
|
|
|
|
returns (as reference argument "monitors") a handle to the current list of convergence monitors. If there are no monitors at hand, i.e., no monitors have been attached or the user has chosen a direct solver, the returned handle is empty. The return value of type "bool" is true if monitors have been encountered and false otherwise. |
|
|
returns the current "LinEqSystem" object containing "A", "x", "b" and eventual preconditioners. |
|
|
|
|
|
|
|
|
returns access to a "LinEqStatBlk" object that contains detailed information about the performance of the linear solver. The function must be called after "solve" and gives results regarding the solver used in the last "solve" call. Notice that the computation of the "LinEqStatBlk" may involve the computation of a residual, which may be expensive relative to the total work by the linear solver if the number of iterations is low. The "getPerformance" function will itself check whether the "LinEqStatBlk" object ("performance_info") is updated or not and make the necessary computations. If you never call "getPerformance", you avoid all the overhead associated with the "LinEqStatBlk" object. |
|
|
See documentation of one of the overloaded functions. |
|
|
(depending on whether the argument "left" is true or false), either as a "Precond" object or as a "LinEqMatrix". The latter version is only useful when employing an algebraic preconditioner. |
|
|
|
|
|
|
|
|
|
|
|
efficient function for inquiring about the number of iterations of an iterative linear solver and a boolean argument indicating whether the solver reached the convergence criteria or not. The boolean return value is true if the solver really was iterative (and it makes sense to, e.g., write out the number of iterations), for direct solvers the return value is false. Here is an example of the usage of "getStatistics":
// given LinEqAdm lineq
if (lineq.getStatistics(niterations,c))
s_o << oform("solver%sconverged in %d iterations\n",
c ? " " : " not ",niterations);
Note that "getStatistics" is much more efficient than calling, e.g., "getPerformance().print(s_o)", since the latter call implies that a "LinEqStatBlk" object must be computed (see the documentation of "getPerformance"). |
|
|
|
|
|
returns "true" if the data members in "LinEqAdm" are correctly initialized. Principally, "ok" cannot be called before "solve" has finished since some initialization of preconditioners and convergence monitors are performed from within the "solve" function in the linear solver objects. However, if the "after_solve" argument is "true", "ok" omits the check on the linear system/solver and in this case "ok" can be called before "LinEqAdm solve". Frequently, "ok" has no meaning before the linear system is made (that is, in the finite element case, after the "LinEqAdmFE initAssemble" has been called to redimension the linear system). Consequently, "ok" should be called after the system is built (in the finite element case, after "FEM makeSystem"). If the argument "after_solve" is true (which means that "ok" is called after "LinEqAdm solve"), "ok" performs a total test on the state of the "LinEqAdm" data members, including the linear system/solver. |
|
|
|
|
|
print the current parameters to an output stream. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. Reimplemented in LinEqAdmFD. |
|
|
reads parameters and initializes the "LinEqAdm" object depending on input from an input stream or a menu system. If an iterative method is requested and the user has not asked for full menus (see "fullMenu" below), an additional menu for preconditioner and convergence monitor parameters will be presented. In case of full menus, all items are located in the same "LinEqAdm" submenu. Please notice that simulators that use a "LinEqAdm" object that is updated inside a call to "MenuSystem multipleLoop" are forced to employ full menus. |
|
|
|
|
|
invokes the "solve" function of the chosen "LinEqSolver" object, thus causing the solution of the linear algebraic system. Through the argument "A_has_changed", the solver can be told whether a new preconditioner (in case of iterative methods) or a new LU factorization (in case of a direct method) has to be computed. In time dependent problems where the stiffness matrix may be constant, the "A_has_changed" argument can be used to avoid unnecessary recomputation of (complete or incomplete) matrix factorizations. Note that a similar "bool" argument is present in "FEM makeSystem" to avoid recomputation of the stiffness matrix (and/or the right hand side). Notice that these "bool" arguments must match: It does not help to tell "solve" that the old factorization of the matrix is to be used if "makeSystem" distroys the old matrix content and computes a new matrix. |
|
|
returns the solution as a "Vector(NUMT)" object. |
|
|
returns the solution as a "LinEqVector" object. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|