Cleanup AMG

In order to improve maintainability and flexibility of the AMG I would like to see some code clean-up and modernization.

This issue should is a wish-list/feature request and a note to myself.

Here follows an incomplete list, which might grow while working on it...

• replace manual memory management with smart pointers
• the iterator of Hierarchy currently has some additional methods. These should be moved to the Element so that element can be stored in an other container.
• replace the manually implemented linked-list in Hierarchy by either std::deque or std::vector. The push_front feature isn't used anywhere.
• I don't see a reason for a deep copy in the AMG and the Hierarchy. We should try to keep this copy as shallow as possible. (see #64 (closed))
• The element-allocator of the Hierarchy is not used at all. This is at least surprising, as it is used as a rebound allocator.
• Why do we also clone the lhs, rhs, update vectors in the AMG copy-constrcor? The are recreated in pre(...) anyway.
• Remove construction traits.

And some strange features I'm unsure about...

• graph.hh:123 why should the internal type of the weight change, depending on the constness of the matrix?
• matrixhierarchy.hh:334 shouldn't origComm be const?

And some further wishes...

• factor out aggregation so far, that we pass in prolongation/restriction operators constructed somewhere else
• make restriction/prolongation fulfil the operator interface
• can we replace graph.hh with a modern graph implementation, perhaps maintained outside of Dune?
• twolevelsolver has a LevelContext while the AMG keep different hierarchies. Can we unify this?

@markus.blatt do you use the push_front of Hierarchy somewhere? It is not used in dune-istl.

@christi Do you mean the method from SLList? In example/without-sllist I replaced SLList by std::forward_list and the compiler told me where push_front was used. The code compiles but is broken. Maybe it helps to answer your question. Feel free to delete my branch if it is of no more use for you.

@christi I hope this is the appropriate place to comment. I noticed that several pointers changed to be shared_ptr in dune-istl, and I think it is good to use smart pointers as much as possible! However I would think unique_ptr is a better fit in most or all places? If shared_ptr is required in a particular spot one can construct a shared_ptr from a unique_ptr.

unique_ptr is typed on the deleter and this not suitable for our use of virtual interfaces. Also the performance overhead of shared_ptr seems negligible in this course grained interface. Also regarding the concept I'm not sure. We really want to shared state between different components, so shared_ptr seems quite adequate to me.

marked the checklist item replace manual memory management with smart pointers as completed

marked the checklist item I don't see a reason for a deep copy in the AMG and the Hierarchy. We should try to keep this copy as shallow as possible. (see #64 (closed)) as completed

marked the checklist item Why do we also clone the lhs, rhs, update vectors in the AMG copy-constrcor? The are recreated in pre(...) anyway. as completed

changed the description

Nope push_front is not used. Conceptionally it is there if one would refine the problem (Matrix representation of Geometric multigrid). That should make sense.