dealii/dealii — pull request #204 by bangerth (2014-10-21 12:10:35+00:00)
Title: [WIP] Use signals in solvers

This is work in progress, but I'm interested in getting feedback whether people think this is a worthwhile direction to go into.

The motivation for this is that we currently do not have much insight into what happens in our linear solvers. The only information that gets out is the call to `SolverControl::check()` that gets the iteration number and the residual. This patch converts this as follows:

- Instead of calling this one function, it calls a boost::signal that returns whether the iteration should continue, has succeeded, or has failed (just like before).
- Currently, the only function associated with this signal is `SolverControl::check()`.

The signal also receives the current iterate `x` as an argument (which is discarded when calling `SolverControl::check()`). In follow-up patches I will add a way how a user can add other functions to the signal that will then get called whenever `SolverControl::check()` is called. The idea is that this way one can observe convergence, for example by tracking how individual components of `x` converge, etc. The real reason I want a patch like this is because I am thinking about the missing multigrid video lecture and want to call a function that just outputs the current iterate `x` in each iteration, showing that SSOR, CG, etc, are all smoothers that form one half of a functioning multigrid algorithm.

Feedback welcome!

(For review: the first of the two commits contains all of the changes to the code; the second one is just adjustments to testcase -- all just minor adjustments, but with the exact same output as before. You will see that the previous version of the code was doing lots of things I don't, in hindsight, think are good coding practices. For example, practically all solvers did not track the number of iterations themselves, but instead query the `SolverControl` object via `this->control().last_step()`. In other words, they store temporary variables in a separate object. I think the code becomes clearer when each function tracks its own information.)