New Conjugate Gradient Solvers
Metadata
Property | Value |
---|---|
Reported by | Lars Lubkoll (lars.lubkoll@posteo.de) |
Reported at | Oct 13, 2015 13:24 |
Type | Discussion |
Version | Git (pre2.4) [autotools] |
Operating System | Unspecified / All |
Description
As promised at the User Meeting I want to share my CG-implementations. Now I need you!
Questions
-
C++11 will be supported with Dune v3.0, so I can use it, right?
-
I was always wondering how relevant the Operator::category is. If it is required, wouldn't it make sense to treat it dynamically with exceptions?
-
I tested the cg-implementation against the version that is currently in Dune. Do you have some set of test-problems or tests for ISTL?
-
Any feedback is welcome. I did spent some effort to provide a clean, efficient and robust implementation, but probably you have some requirements that I did ignore. So tell me if there is something that you want to be improved.
-
There is some literature that I cite in the documentation. I personally like to have that in the doxygen documentation for being able to look up details. Thumbs up/down?
-
I believe that there are some parts of the code that should be better placed somewhere outside istl. In particular there is a compile-time sequence and some elementary operations on it. Moreover I typically use a set of mixin classes for adding parameters such as (absolute,relative) accuracy, number of steps, verbosity level... . These may also be better located at a more general place. The mixin approach I did not see in Dune, but I assume that you already have a place where you collect template meta-programming tools, right?
Short Intro
Currently I implemented the conjugate gradient method and three versions that are relevant in nonconvex optimization (truncated CG, regularized CG, truncated regularized CG). Moreover there is a Chebyshev semi-iteration. As termination criterion there is a residual-based (as before) and one that is essentially based on the relative energy error.
The rough structure of the implementation is as follows:
There is a generic iterative method and a generic step as basic building blocks for iterative methods.
a. The generic iterative method takes a step and a termination criterion and manages step computation, evaluation of the termination criterion and optionally restarts the computation.
b. The generic step allows to specify the details of the implementation of one step as well as additional interface functions and a data object. It seems that the structure of the generic step could be made cleaner. Any ideas are welcome.
Get code
See attachment or here:
git clone https://github.com/lubkoll/dune-istl-cg.git