Lisa Julia Nebel authored 4 years ago and Sander, Oliver committed 11 months ago

The MixedRiemannianPNSolver can assemble when different finite element
spaces are used for deformations and rotations (in, e.g., a Cosserat
model).  CHOLMOD is used for the inner solver.

This can be much faster than the MixedRiemannianTRSolver.

Previously this wouldn't compile, because GlobalP2Mapper only supported
1d and 2d grids when used without dune-parmg.  This has now been fixed,
so we can enable filmonsubstratetest and filmonsubstratetest-mixed
(which involve a 3d grid) also for the situation without dune-parmg.

Strangely, the test without the -mixed produces different results
depending on whether the dune-parmg version of GlobalP2Mapper is used
or not. Minor differences are to be expected because the precise
behavior of multigrid methods (which are used by the TR solver) depends
on the dof ordering.  But the difference seen here is a bit large
for my taste.

I don't quite understand this, so this commit introduces some
subcasing to make CI pass, and document the current behavior.

These tests have started to time out. I have no idea why.

This replaces the dedicated implementation of the quadrature loop
for harmonic energies -- that is not needed anymore.

In particular this means that the test for it can be removed.
In theory it should be replaced with a test for the harmonic
energy *density*, but that density implementation is so short
that it doesn't really require a separate test.

Together with the new test, this commit also contains a number
of fixes for the SurfaceCosseratEnergy class.  This class was
not unit-tested previously, and unintentionally I messed it up
badly during my recent modernization work.

Finally, SurfaceCosseratEnergy had apparently never been tested
without dune-curvedgeometry, which is however only an optional
dependency.  The commit therefore also adds the necessary
conditionals.

Then problem then is that the derivative of the outer normal
of an intersection is not available from the standard grid interface.
If dune-curvedgeometry is not available, this derivative is
simply set to a zero matrix.  Depending on the grid manager
this may not actually be correct, though.

ADOL-C can compute all derivatives with two different modes:
scalar- and vector mode.  In theory they should produce exactly
the same results, but sometimes there are bugs (I have found
a few of those myself).  adolctest-scalar-and-vector-mode tested
whether the two modes produced the same result for a particular
Cosserat configuration.

I do not think that dune-gfe is the right place for such a test.
It tests for bugs in ADOL-C itself, and that is the job of
ADOL-C's own test suite.  Consequently, I am removing the test.

The ProductManifold class generalizes RigidBodyMotion, and can do
everything that the RigidBodyMotion class can.  Therefore there is
no point in keeping RigidBodyMotion any longer.  Having two
implementations for the same thing will just confuse people.

Previously, the test mysteriously failed on the CI system, but not locally.
I recently tried again and the CI test passed again.  I don't understand
what was going on, but for the time being let's enable the test again.

It run-time fails on the CI system for unknown reasons.
I don't currently have the time to spend more time debugging this.
Therefore, this patch simply disables the test and leaves a note.

Move the polar decomposition to a separate file and add the algorithm by Higham and Noferini (from Robin Fraenzel)

In the test for the Higham and Noferini algorithm, we see:
Unfortunately, for matrices that are close to an orthogonal matrix, this algorithm is
about 2x slower. One can benefit from the Higham and Noferini algorithm only if the
matrix is quite far away from an orthogonal one.

Add a simple test with a grid containing one element testing if the energy is invariant of the number of grid refinements.

This test assembles and solves a prototype Cosserat problem.
In then checks whether the required number of iterations and the
final energy match given (hard-coded) values.

This reflect the current purpose of the test much better.

GeodesicFEAssembler can replace it without problems.

Only compile geodesicfeassemblerwrappertest if the version of dune-elasticity is greater or equal 2.7

Add a GeodesicFEAssemblerWrapper - it wraps a MixedGFEAssembler so it can be used like a GeodesicFEAssembler

The GeodesicFEAssemblerWrapper assembles the Gradient and the Hessian using the MixedGFEAssembler and then
resturctures them so they can be used with the normal RiemannianTRSolver.
This only works, if the FE spaces have the same order.

This new test computes a harmonic map from a square to a sphere.
In other words, rather than testing some specific aspect of some
class, it does a whole simulation.  It should therefore cover
much more of the dune-gfe code.

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.

In particular, we move the test for the computeDR method from
cosseratenergytest.cc to here.  It is a method that does not
have anything to do with Cosserat mechanics directly.

The test still seems overly complicated.  Do I really need
a LocalGeodesicFEFunction?  Maybe I can simplify it later.

It's not clear what it is supposed to be testing at all.

It is no test.  Rather, it is a program I used to create illustrations
for the paper on GFE test functions (arXiv:1607.07479).  I moved the
program into the git repository of that paper.

This was never a real test.  Rather, it was I toy for me to test
a mathematical property of GFE functions which is known to be
false anyway.