Abort CGSolver when the defect is invalid

The first commit introduces the exception SolverAbort, derived from ISTLError.

The second commit makes CGSolver abort by throwing SolverAbort when the defect becomes invalid (infinite or NaN). The check is done in every iteration before the convergence check.

These two commits fix #12 (closed).

The third and fourth commit make BiCGStab and GMRes throw SolverAbort when they detect a breakdown. SolverAbort seemed more specific when the ISTLError they were throwing before.

The fifth commit documents when SolverAbort is thrown at the moment.

The sixth commit adds a unit tests that tries to trigger SolverAbort and makes sure that it is actually thrown. It does this for the NaN-check in CGSolver and for the "abs(h) < EPSILON"-check in BiCGSTABSolver -- there a more conditions in BiCGSTABSolver and RestartedGMResSolver that throw, but I don't know how to trigger them.

Unit tests compiled and passed (or skipped). The tests were done on a merge of this branch and !35 (merged) to get fastamg to compile.

mentioned in issue #12 (closed)

Added 1 commit:

• 87022110 - [doc] Update doxygen documentation with regard to SolverAbort.

Documentation is now checked. Documented that BiCGSTABSolver and RestartedGMResSolver may throw SolverAbort when they detect breakdown.

I forgot to mention earlier, and it hasn't been discussed so far: This patch triggers a SolverAbort exception not only when the defect is NaN, but also when the defect is inf.

Concerning the remove-autotools branch: Just go ahead with merging and you or I rebase the branch.

Added 1 commit:

• c024db84 - [test][SolverAbort] Check that the solver aborts when given an unsolvable system to solve.

@gruenich So, that means, if I have to add a test to the buildsystem, I should add it to the autotools buildsystem too? Since that is only used for dune-web, if at all, that seems like wasted effort. In particular since I have to test it if I touch it.

There is now a unit test (CMake buildsystem only, currently). It uses the matrix from #12 (comment 15879) to trigger solver-aborts in CGSolver and BiCGSTABSolver, and checks for the resulting SolverAbort exception.

With gcc-4.9 on amd64, this works with -Ofast too (which includes -ffast-math). There is the possibility to check for the define __FAST_MATH__, which is set by gcc at least. If that is set we can skip the test instead of failing. The problem is that the problematic optimization -ffinite-math-only can be set independently of -ffast-math, and does not appear to have a separate define we can check for. There are hacky runtime checks that we could employ, but let's not overdo the hackyness. Let me know if you want me to include a check for __FAST_MATH__.

BiCGSTABSolver and RestartedGMResSolver can also detect "breakdown"-conditions, which will also generate SolverAbort exceptions. The unit test does not test for them, since I don't know how to trigger them, and there was no unit test for those conditions before.

I meant it the other way round: If you don't need make changes, everything is fine. If you need to make changes, go ahead and we rebase the remove-autotools branch afterwards.

@gruenich I'm still not sure whether I understand you comments regarding autotools correctly. I'll interpret them as 'do whatever you like', and that means I won't adapt the autotools build system unless someone complains.

Yes, your interpretation accords with my speech intention.

@all: I want to be done with this, so I will merge in about a week unless there is strong opposition or there are any problems discovered. Please comment!

We don't seem to do formal voting these days (we seem to lack the infrastructure), and I'm uncertain whether this constitutes an interface change (since I'm uncertain what constitutes the official interface). So If you think this requires an official vote, please say so.

A week has gone by without comments, merging...

Unmarked this merge request as a Work In Progress

Status changed to merged

mentioned in commit 538d99fa