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.

Fix nonconforming interpolation

See merge request !153

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 avoid two unsuccessful iterations at the beginning,
and hence reduces the overall time to run the test somewhat.

This is needed to support nonconforming discretizations.

Fix: Consistent naming of parameter strings

See merge request !152

Add option to choose a different Regularization-Norm for the Riemannian Newton with Hessian modification

See merge request !150

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

MixedGFEAssembler: Pass local stiffness by r-value, l-value, shared_ptr

See merge request !151

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.

Make BulkCosseratDensity interface more standard-like

See merge request !149

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.

I don't see why this has to be kept after the migration.

Add missing regularization term in the quality measurement for step acceptance

See merge request !147

Use plain std::vector<double> for element energy gradients

See merge request !148

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.

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 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.