Add first version of the Riemannian Proximal Newton solver, as an alternative to the Trust-Region Solver.

In each step of these two iterative solvers, we try to find a correction
that decreases the energy of the nonlinear functional of the current iterate x.
The correction is calculated using the Taylor expansion around x,
resulting in the problem: Hessian(x) * correction = -gradient(x).
Within a certain radius around x, the functional can be approximated correctly and then
the corrections causes an energy decrease.
1) The trust-region algorithm ensures this using a trust-region.
2) The proximal newton method ensures this by punishing
   large corrections using a regularization factor.

In case the solve step (which is only done on process 0) goes wrong
communicate it to all processes.

Print out assembly time for each process on each process and
print out the gradient norms only on one process.

This array contains the global numbering for the degrees of freedom
on the whole grid hierarchy, not only on the coarsest level.

This actually enforced writing of three tape files of ADOL-C (see taping.h)!

Reduce quadrature order, before 16 quadrature points were used, an amount that's sufficient to integrate over a 3D-element, but as the integral is on the boundary, now 9 quadrature points, which are enough for 2D, are used.

Add option to read in a displacement file that will be used for the stress-free configuration of the shell elements
When startFromFile is set to true, then the stress-free configuration is read from the given file - this file needs to match the *finest* level of the grid
When startFromFile is set to false, the stress-free configuration can be given in as a function

Catch an exception that might be thrown by the localEnergy_ and solve the problem again using a smaller trust region.
Also make sure the ADOLC-Tape gets closed properly

Print total time, total assembly time and total time needed for solving at the end of the trust-region solver run

WHITESPACES: Continue with Trust-Region-Algorithm if IPOPT threw an error while solving, treat this case as an 'unsuccessful iteration'

Continue with Trust-Region-Algorithm if IPOPT threw an error while solving, treat this case as an 'unsuccessful iteration'

Lisa Julia Nebel authored 5 years ago and Sander, Oliver committed 5 years ago

This class will gradually replace the current implementations
GlobalP1Mapper and GlobalP2Mapper, because dune-gfe is not
the proper place for infrastructure for distributed computing.
Plus, the stuff in dune-parmg already is more flexible and
powerful.

Up until dune-common 2.7, the Dune namespace contained shared_ptr:
First as an actual implementation, later simply as a namespace
import.  Dune-common post-2.7 has removed that import,
and users of shared_ptr really have to explicitly specify
the std:: namespace prefix.

The svd code contains some index trickery, because the original code
was written in fortran, which numbers arrays starting from '1'
rather than from '0'.  This trickery included having a pointer point
1 int in front of an allocated array, implicitly relying on the
fact that pointer[0] would never be called.  The llvm sanitizer
complains nevertheless, so this patch improves the trickery a little
to avoid the objected pointer.

Do this by making RodAssembler more similar to the generic
GeodesicFEAssembler: the constructor argument is now a
general LocalGeodesicFEStiffness, and not something particular
to rod problems.

Automatic testing of the RiemannianTrustRegionSolver class requires
to know what it did on the previous run.  This patch adds
some infrastructure to collect this information.

I wrote it without a clear idea of what is needed of such a
test function, and I never finished it.  Now it is unclear
what the code does or is supposed to do, so let's just
remove it.

This avoids 'implicit narrowing' errors/warnings.

For some reason only clang complains about this.

Using LocalIndexSet objects was mandatory with dune-functions-2.5
and earlier.  However, we only support 2.6 and later anyway,
so let's get rid of the backward-compatibility code.

In principle, a serious bug: but for dimworld=3d (i.e., the standard)
this loop was never executed anyway.  Hence there were no serious
consequences.

Because it really is a functionality of rotation matrices in quaternion
representation.  Only the Cosserat energies use it at the moment, but
this is coincidental.

In the same process, the method is renamed to quaternionTangentToMatrixTangent.
That seems to be a more telling name.

Assignment from initializer lists makes this much shorter.

Previously, this test used a situation with geodesic interpolation
between two points on the sphere that are almost antipodal.
This made the TargetSpaceRiemannianTRSolver crash, because the
weighted sum of squared distances can have indefinite second
derivatives in such a situation.  In principle, the
TargetSpaceRiemannianTRSolver should handle this, but nowadays
it is not actually a TR solver anymore, but a plain local
Newton method.  Maybe I should revert back to trust-region.

I added a comment to targetspacetrsolver.cc that explains the
situation a little.

The computation of the A-orthogonal matrices was wrong,
and for some reason nobody ever really noticed this.
One reason could be that in GFE applications A is frequently
very close to the identity, and then you wouldn't notice
the bug that much.

Anyway, localgeodesicfefunctiontest.cc passes now.

In favor of the new ones in dune-common.

Because it really is only an energy.