![]() |
Reference documentation for deal.II version 9.6.0
|
#include <deal.II/lac/solver.h>
Classes | |
struct | StateCombiner |
Public Types | |
using | vector_type = VectorType |
Public Member Functions | |
SolverBase (SolverControl &solver_control, VectorMemory< VectorType > &vector_memory) | |
SolverBase (SolverControl &solver_control) | |
boost::signals2::connection | connect (const std::function< SolverControl::State(const unsigned int iteration, const double check_value, const VectorType ¤t_iterate)> &slot) |
template<class Archive > | |
void | serialize (Archive &ar, const unsigned int version) |
Subscriptor functionality | |
Classes derived from Subscriptor provide a facility to subscribe to this object. This is mostly used by the SmartPointer class. | |
void | subscribe (std::atomic< bool > *const validity, const std::string &identifier="") const |
void | unsubscribe (std::atomic< bool > *const validity, const std::string &identifier="") const |
unsigned int | n_subscriptions () const |
template<typename StreamType > | |
void | list_subscribers (StreamType &stream) const |
void | list_subscribers () const |
Static Public Member Functions | |
static ::ExceptionBase & | ExcInUse (int arg1, std::string arg2, std::string arg3) |
static ::ExceptionBase & | ExcNoSubscriber (std::string arg1, std::string arg2) |
Protected Attributes | |
GrowingVectorMemory< VectorType > | static_vector_memory |
VectorMemory< VectorType > & | memory |
boost::signals2::signal< SolverControl::State(const unsigned int iteration, const double check_value, const VectorType ¤t_iterate), StateCombiner > | iteration_status |
Private Types | |
using | map_value_type = decltype(counter_map)::value_type |
using | map_iterator = decltype(counter_map)::iterator |
Private Member Functions | |
void | check_no_subscribers () const noexcept |
Private Attributes | |
std::atomic< unsigned int > | counter |
std::map< std::string, unsigned int > | counter_map |
std::vector< std::atomic< bool > * > | validity_pointers |
const std::type_info * | object_info |
Static Private Attributes | |
static std::mutex | mutex |
A base class for iterative linear solvers. This class provides interfaces to a memory pool and the objects that determine whether a solver has converged.
In general, iterative solvers do not rely on any special structure of matrices or the format of storage. Rather, they only require that matrices and vectors define certain operations such as matrix-vector products, or scalar products between vectors. Consequently, this class as well as the derived classes and their member functions implementing concrete linear solvers are templated on the types of matrices and vectors. However, there are some common requirements a matrix or vector type must fulfill to qualify as an acceptable type for the solvers in this hierarchy. These requirements are listed below.
The classes we show below are not any concrete class. Rather, they are intended to form a "signature" which a concrete class has to conform to. Note that the matrix and vector classes within this library of course conform to this interface; therefore, SparseMatrix and Vector are good examples for these classes as they provide the necessary signatures of member functions (although they also provide many more interfaces that solvers do not in fact need – for example, element access). In addition, you may want to take a look at step-20, step-22, or a number of classes in the LinearSolvers namespace for examples of how one can define matrix-like classes that can serve as linear operators for linear solvers.
Concretely, matrix and vector classes that can be passed to a linear solver need to provide the following interfaces:
In addition, for some solvers there has to be a global function swap(VectorType &a, VectorType &b)
that exchanges the values of the two vectors.
Finally, the solvers also expect an instantiation of GrowingVectorMemory<VectorType>. These instantiations are provided by the deal.II library for the built-in vector types, but must be explicitly added for user-provided vector classes. Otherwise, the linker will complain that it cannot find the constructors and destructors of GrowingVectorMemory that happen in the SolverBase
class.
The preconditioners used must have the same interface as matrices, i.e. in particular they have to provide a member function vmult
which denotes the application of the preconditioner.
Several solvers need additional data, like the damping parameter omega
of the SolverRichardson
class or the maximum number of temporary vectors of SolverGMRES
. To have a standardized way of constructing solvers, each solver class has a struct AdditionalData
as a member, and constructors of all solver classes take such an argument. Some solvers need no additional data, or may not at the current time. For these solvers the struct AdditionalData
is empty and calling the constructor may be done without giving the additional structure as an argument as a default AdditionalData
is set by default.
With this, creating a solver looks like one of the following blocks:
Using a unified constructor parameter list for all solvers supports the SolverSelector
class; the unified interface enables us to use this class unchanged even if the number of types of parameters to a certain solver changes and it is still possible in a simple way to give these additional data to the SolverSelector
object for each solver which it may use.
The SolverBase class, being the base class for all of the iterative solvers such as SolverCG, SolverGMRES, etc, provides the facilities by which actual solver implementations determine whether the iteration is converged, not yet converged, or has failed. Typically, this is done using an object of type SolverControl that is passed to the solver classes's constructors and from them down to the constructor of this base class. Every one of the tutorial programs that solves a linear problem (starting with step-3) uses this method and it is described in detail there. However, the underlying mechanism is more general and allows for many other uses to observe how the linear solver iterations progress.
The basic approach is that the iterative solvers invoke a signal at the end of each iteration to determine whether the solution is converged. A signal is a class that has, conceptually, a list of pointers to functions and every time the signal is invoked, each of these functions are called. In the language of signals, the functions called are called slots and one can attach any number of slots to a signal. (The implementation of signals and slots we use here is the one from the BOOST.signals2 library.) A number of details may clarify what is happening underneath:
this
argument has been bound using a lambda function (see the example below).Given all this, it should now be obvious how the SolverControl object fits into this scheme: when a SolverControl object is passed to the constructor of the current class, we simply connect the SolverControl::check() function of that object as a slot to the signal we maintain here. In other words, since a SolverBase object is always constructed using a SolverControl object, there is always at least one slot associated with the signal, namely the one that determines convergence.
On the other hand, using the connect() member function, it is possible to connect any number of other slots to the signal to observe whatever it is you want to observe. The connect() function also returns an object that describes the connection from the signal to the slot, and the corresponding BOOST functions then allow you to disconnect the slot if you want.
An example may illuminate these issues. In the step-3 tutorial program, let us add a member function as follows to the main class:
The function satisfies the signature necessary to be a slot for the signal discussed above, with the exception that it is a member function and consequently requires a this
pointer. What the function does is to take the vector given as last argument and write it into a file in VTU format with a file name derived from the number of the iteration.
This function can then be hooked into the CG solver by modifying the Step3::solve()
function as follows:
The use of a lambda function here ensures that we convert the member function with its three arguments plus the this
pointer, to a function that only takes three arguments, by fixing the implicit this
argument of the function to the this
pointer in the current function.
It is well understood that the CG method is a smoothing iteration (in the same way as the more commonly used Jacobi or SSOR iterations are smoothers). The code above therefore allows to observe how the solution becomes smoother and smoother in every iteration. This is best observed by initializing the solution vector with randomly distributed numbers in \([-1,1]\), using code such as
Using this, the slot will then generate files that when visualized look like this over the course of iterations zero to five:
![]() | ![]() | ![]() |
![]() | ![]() | ![]() |
using SolverBase< VectorType >::vector_type = VectorType |
|
privateinherited |
The data type used in counter_map.
Definition at line 229 of file subscriptor.h.
|
privateinherited |
The iterator type used in counter_map.
Definition at line 234 of file subscriptor.h.
SolverBase< VectorType >::SolverBase | ( | SolverControl & | solver_control, |
VectorMemory< VectorType > & | vector_memory ) |
Constructor. Takes a control object which evaluates the conditions for convergence, and an object that allows solvers to allocate memory for temporary objects.
Of both objects, a reference is stored, so it is the user's responsibility to guarantee that the lifetime of the two arguments is at least as long as that of the solver object.
SolverBase< VectorType >::SolverBase | ( | SolverControl & | solver_control | ) |
Constructor. Takes a control object which evaluates the conditions for convergence. In contrast to the other constructor, this constructor designates an internal object of type GrowingVectorMemory to allocate memory.
A reference to the control object is stored, so it is the user's responsibility to guarantee that the lifetime of the argument is at least as long as that of the solver object.
boost::signals2::connection SolverBase< VectorType >::connect | ( | const std::function< SolverControl::State(const unsigned int iteration, const double check_value, const VectorType ¤t_iterate)> & | slot | ) |
Connect a function object that will be called periodically within iterative solvers. This function is used to attach monitors to iterative solvers, either to determine when convergence has happened, or simply to observe the progress of an iteration. See the documentation of this class for more information.
slot | A function object specified here will, with each call, receive the number of the current iteration, the value that is used to check for convergence (typically the residual of the current iterate with respect to the linear system to be solved) and the currently best available guess for the current iterate. Note that some solvers do not update the approximate solution in every iteration but only after convergence or failure has been determined (GMRES is an example); in such cases, the vector passed as the last argument to the signal is simply the best approximate at the time the signal is called, but not the vector that will be returned if the signal's return value indicates that the iteration should be terminated. The function object must return a SolverControl::State value that indicates whether the iteration should continue, has failed, or has succeeded. The results of all connected functions will then be combined to determine what should happen with the iteration. |
|
inherited |
Subscribes a user of the object by storing the pointer validity
. The subscriber may be identified by text supplied as identifier
.
Definition at line 135 of file subscriptor.cc.
|
inherited |
Unsubscribes a user from the object.
identifier
and the validity
pointer must be the same as the one supplied to subscribe(). Definition at line 155 of file subscriptor.cc.
|
inlineinherited |
Return the present number of subscriptions to this object. This allows to use this class for reference counted lifetime determination where the last one to unsubscribe also deletes the object.
Definition at line 300 of file subscriptor.h.
|
inlineinherited |
List the subscribers to the input stream
.
Definition at line 317 of file subscriptor.h.
|
inherited |
List the subscribers to deallog
.
Definition at line 203 of file subscriptor.cc.
|
inlineinherited |
Read or write the data of this object to or from a stream for the purpose of serialization using the BOOST serialization library.
This function does not actually serialize any of the member variables of this class. The reason is that what this class stores is only who subscribes to this object, but who does so at the time of storing the contents of this object does not necessarily have anything to do with who subscribes to the object when it is restored. Consequently, we do not want to overwrite the subscribers at the time of restoring, and then there is no reason to write the subscribers out in the first place.
Definition at line 309 of file subscriptor.h.
|
privatenoexceptinherited |
Check that there are no objects subscribing to this object. If this check passes then it is safe to destroy the current object. It this check fails then this function will either abort or print an error message to deallog (by using the AssertNothrow mechanism), but will not throw an exception.
Definition at line 52 of file subscriptor.cc.
|
mutableprotected |
|
protected |
|
protected |
A signal that iterative solvers can execute at the end of every iteration (or in an otherwise periodic fashion) to find out whether we should continue iterating or not. The signal may call one or more slots that each will make this determination by themselves, and the result over all slots (function calls) will be determined by the StateCombiner object.
The arguments passed to the signal are (i) the number of the current iteration; (ii) the value that is used to determine convergence (oftentimes the residual, but in other cases other quantities may be used as long as they converge to zero as the iterate approaches the solution of the linear system); and (iii) a vector that corresponds to the current best guess for the solution at the point where the signal is called. Note that some solvers do not update the approximate solution in every iteration but only after convergence or failure has been determined (GMRES is an example); in such cases, the vector passed as the last argument to the signal is simply the best approximate at the time the signal is called, but not the vector that will be returned if the signal's return value indicates that the iteration should be terminated.
|
mutableprivateinherited |
Store the number of objects which subscribed to this object. Initially, this number is zero, and upon destruction it shall be zero again (i.e. all objects which subscribed should have unsubscribed again).
The creator (and owner) of an object is counted in the map below if HE manages to supply identification.
We use the mutable
keyword in order to allow subscription to constant objects also.
This counter may be read from and written to concurrently in multithreaded code: hence we use the std::atomic
class template.
Definition at line 218 of file subscriptor.h.
|
mutableprivateinherited |
In this map, we count subscriptions for each different identification string supplied to subscribe().
Definition at line 224 of file subscriptor.h.
|
mutableprivateinherited |
In this vector, we store pointers to the validity bool in the SmartPointer objects that subscribe to this class.
Definition at line 240 of file subscriptor.h.
|
mutableprivateinherited |
Pointer to the typeinfo object of this object, from which we can later deduce the class name. Since this information on the derived class is neither available in the destructor, nor in the constructor, we obtain it in between and store it here.
Definition at line 248 of file subscriptor.h.
|
staticprivateinherited |
A mutex used to ensure data consistency when accessing the mutable
members of this class. This lock is used in the subscribe() and unsubscribe() functions, as well as in list_subscribers()
.
Definition at line 271 of file subscriptor.h.