Remove whitespace in maxProximalNewtonSteps-string @Riemannianpnsolver (causes problem with get-method of parameterTree)

Previously they were returned by value, but I do not remember any
actual reason for that.  Return by const reference leads to a
measurable speed increase when computing the derivatives of
projection-based FE onto the sphere.  It also fixed some
undefined behavior in that code, which took const-references
of the returned temporaries.

Returning the coefficients by const reference is more difficult
for product manifolds, because previously the interpolation rules
stored the coefficients separately for each factor space.
With this patch, these rules now store the coefficients twice:
once in the old separate format, and once as needed for returning
them by reference.  Interpolation rules are not meant to exist
in large numbers, and therefore I do not think that this
extra space consumption matters.

They were 'field_type' before, which is 'adouble' when used
together with ADOL-C (the typical case).  But using 'adouble'
for parameters is unnecessary and wasteful.

This broke recently (or never worked), because nonconforming
discretizations were not tested anywhere.  This patch therefore
also generalizes harmonicmaptest to also test with a
nonconforming discretization.

As part of the fix, the interpolation rules get a new method
`evaluateValueAndDerivative`, because the previous way to get
the value and the derivative in a single call (the `evaluateDerivative`
method that takes a value as an argument) only worked for the
conforming case.

This is needed to support nonconforming discretizations.

	The h1SemiNorm was only setup when the instrumented-flag was true.
	These are however independent functionalities.

They were expected to be the factors of a ProductManifold which is
also a template parameter.

Expecting the product and the factors is redundant.  We simply
extract the factors from the product now.

Previously, it expected two factor spaces, as separate template
parameters.  Taking a single ProductManifold type is more consistent
with GeodesicFEAssembler, and it allows to eventually generalize
the code to more factors, if desired.

... but disallow a plain pointer.  This increases consistency with the
GeodesicFEAssembler class.

In the wake of this, remove all Cosserat nomenclature.

We keep the restriction to two factor spaces, because I see no
short-time need for more generality.

Not all densities depend on the function value (e.g., elasticity),
and not all of them depend on the derivative (e.g., dead volume loads).
If the TargetSpace is a product manifold, not every density depends
on all factors.  This commit introduces an interface that allows
the assembler to query what quantities of what factor a density
depends on, to skip GFE interpolation that are later unused.

dune-elasticity also has densities, but they implement a slightly
different interface.  Instead of having special code for such
densities in the LocalIntegralAssembler, add a wrapper that
makes densities from dune-elasticity look like dune-gfe densities.

Use the standard operator() method instead.

Non-composite settings use Dune::Matrix<double>,
composite settings use a FieldMatrix where each entry
is Dune::Matrix<double>.

This is not quite as simple as the dune-functions convention,
which is to use Dune::Matrix in all cases.  But it is still
simpler than before.

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.

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.

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

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.

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.