[[Imported from SVN: r9734]]

[[Imported from SVN: r9733]]

[[Imported from SVN: r9732]]

[[Imported from SVN: r9731]]

Those do many-to-one communication with a single method call.
Previously, two subsequent calls were needed.  There is no reason
why the interface has to consist of two calls.  A single one is
much easier to use.

[[Imported from SVN: r9730]]

[[Imported from SVN: r9729]]

After much back and forth: this is the correct way.  This size cannot
be taken from the transfer operators, because these operators exist
only if there is more than one level.

[[Imported from SVN: r9728]]

[[Imported from SVN: r9727]]

[[Imported from SVN: r9726]]

That works for fe spaces of all orders.

[[Imported from SVN: r9725]]

[[Imported from SVN: r9724]]

[[Imported from SVN: r9723]]

[[Imported from SVN: r9721]]

Christian Engwer told me a trick how to get the mpiHelper instance without
known argc and argv.

[[Imported from SVN: r9720]]

That way we can handle multigrid transfer matrices as well.

[[Imported from SVN: r9719]]

The globalindex.hh and uniqueentitypartition.hh is from Benedikt Oswald.
The rest is from Benjamin Bykowski, with a few fixes from me.

The globalindex stuff should go into dune-grid eventually, but it needs
some polishing first.

[[Imported from SVN: r9718]]

[[Imported from SVN: r9710]]

[[Imported from SVN: r9708]]

This does what we want both on one and on many processors.

[[Imported from SVN: r9707]]

This has two advantages:
- The two matrices use different number types (adouble vs. double),
  but the generic multiplication in dune/istl/matrix.hh doesn't support
  that.  Hence before this change I had to patch dune-istl.
- It avoids one extra copying operation

[[Imported from SVN: r9703]]

[[Imported from SVN: r9693]]

With the better initial iterate introduced in the previous patch,
this lower number seems to be sufficient.

[[Imported from SVN: r9684]]

The new initial iterate is constructed by interpolating the values in Euclidean
space, and projecting back onto TargetSpace.  This has two advantages:
1) It's a better initial iterate, so we should converge faster than starting
   from coefficients_[0]
2) It makes it easier for ADOL-C to pick up correct second derivatives.
   Hence we are able to reduce the minimum number of iterations of the
   target space tr solver.

[[Imported from SVN: r9683]]

[[Imported from SVN: r9682]]

[[Imported from SVN: r9666]]

That way, they can at least be looked at.  You won't see the intra-element
details, but frequently they are not even all this important.  Proper
subsampling of higher-order functions is more difficult and has to wait
for another day.

[[Imported from SVN: r9665]]

[[Imported from SVN: r9663]]

This will be generalized to take any Lagrange basis, to allow some form
of visualization for higher-order functions.

[[Imported from SVN: r9662]]

This move more than halfs the size of this file, and makes it *much* easier
to understand.  If we ever need the gradient code we can still recover it
from the 2.3-2 branch.

[[Imported from SVN: r9650]]

[[Imported from SVN: r9648]]

[[Imported from SVN: r9614]]

[[Imported from SVN: r9601]]

[[Imported from SVN: r9588]]

[[Imported from SVN: r9587]]

[[Imported from SVN: r9586]]

Assuming that the AverageDistanceAssembler can provide it.

This is for the Gram-Schmidt solver only.  The old Gauss-Seidel
code will still use a full matrix.

[[Imported from SVN: r9585]]

[[Imported from SVN: r9584]]

viz.:

field_type
blocklevel
operator=(scalar)

[[Imported from SVN: r9583]]

[[Imported from SVN: r9582]]

CG seems to converge to quickly.  If too few iterations are performed,
then ADOL-C has trouble determining the correct second derivatives.
Since the Gram-Schmidt solver is a direct solver, OTOH, the derivatives
should be perfect.  It is also faster than the Gauss-Seidel solver I
was previously using.

[[Imported from SVN: r9581]]