There is no point in testing assemblers that only exist in the test
itself.  Historically, they may have been useful when developing
the dune-gfe assembler framework because they were simpler (they
compute the Euclidean derivatives, not the Riemannian ones).
Nowadays, they just waste CPU cycles.

This is what dune-function mandates.  We don't actually use
dune-functions here a lot, but it is still nice to stay in the spirit.
Also, I am thinking about using dune-functions bases for *some*
indexing work in the future.

Plus, I hope that getting rid of the blocking will improve run-times
of debug builds a little bit, in particular in the
LocalIntegralStiffness class.

MixedRiemannianPNSolver

See merge request !145

Lisa Julia Nebel authored 4 years ago and Sander, Oliver committed 1 year 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.

Lisa Julia Nebel authored 1 year ago and Sander, Oliver committed 1 year ago

It is used by both TR and PN solvers, hence having it in a
separate file is a cleaner design.

While at it we also move it into the namespace Dune::GFE.

Implement GlobalP2Mapper for 3d grids even without dune-parmg

See merge request !146

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.

It is pretty confusing to have the behavior of the solvers depend
on the value of a preprocessor macro that is only used in this
module in only a very inconsistent way.

Unfortunately, this code is used even in sequential situations,
but previously the code only supported 1d- and 2d grids.
And as we still support installations without dune-parmg,
this commit adds an implementation for hypercube grids
of all dimensions.

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

There is no need to wrap the std::function that stores the
Neumann force density into a std::shared_ptr.

Steps towards using LocalIntegralEnergy instead of problem-specific energy classes

See merge request !144

... if dune-common is newer than 2.9

The current build system does not require this argument
anymore.

Plus some minor cleanup

This makes for a cleaner design.  Also, the density is identical
to the one in nonplanarcosseratenergy.hh.  Eventually, we will
replace the density code there with the new density class
introduced here.

The new density CosseratShellDensity does not implement a particular
interface yet.  It is not clear to me yet how such an interface
would look like, exactly.

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.

Rather than using preprocessor switches.  That's too fragile
and not extensible.

If the target manifold is a product space, then ProductManifold must be
used, and not a variadic list of the factor space types.

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.

Various cleanup patches

See merge request !143

CollectiveCommunication has been deprecated for a while, and has
recently been removed from dune-grid.

'thickness' and 'kappa' are parameters in Cosserat shell models.
They are not necessary for bulk models.  Hence remove them.

They do the same thing, essentially.

This is what the non-mixed ADOL-C assembler does, and I want to
merge the two.

Both classes are meant to do the same thing.

This makes the interface more consistent.

These two exist in base classes, and they are inherited anyway.

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.