[Dune] DUNE Usage as a 'normal' library

[Christian Engwer]

Hi Lukas,

as DUNE is an international project, I hope it is OK, if I answer in
english.

> Nun zu den eigentlichen Fragen:
> 1. Würden Sie mir die Verwendung von DUNE für diesen Fall raten, oder bin
> ich besser mit einer kleineren PDE Library aufgehoben, die leichter zu
> handlen ist (wenn man sie selber handlen soll wie wir in dem Fall).

There is no particular reason why not to use DUNE. Later, in industry,
you might also have to familiarize yourself with existing large
codes. So this is a good chance to get experience working with larger
projects.

> 2. Gibt es Dokumentation wie man DUNE als normale Library verwenden kann,
> also als statische oder dynamische Library die man dann als .a / .so in das
> Projekt einfügt?

It is not possible to use the complete DNUE stack as a shared lib, as
many interfaces are fine-grained and the overhead of a library call or
a virtual function lookup would be too costly. On the other hand, if
you decide on certain implementations of the interfaces, you can most
often create shared-libs for your particular interfaces.

If you want it swift and simple and performance is not that much of an
issue, you might also consider using the python bindings.

What will not be possible, is calling iterators and similar via a
function call, but I'm almost sure that is not what you want. If you
want to expose the functionality of solving Poisson equation from a
library, the actual interface would be coarse grined, i.e. few calls
to expensive functions. I imagine, you would have a function to
initialize a solver with a given mesh, then you get an object that can
solve for a given rhs function and return the solution. For
visualization this solution would then need to be written to a vtk or
somethign else would need to be done... If you rely on a particular
grid-manager and a given discretization (or few), it is no problem to
precompile these variants.

Hope this helps a bit...

Ciao
Christian