This is faster than using ADOL-C, and does not add much code.

This will allow derived densities to implement the derivatives by hand.
In some cases (e.g. the harmonic energy) these derivatives are so simple
that there is no need to accept the AD overhead for this.

Currently the user code that plugs together the assembler for a
particular problems has to know that ADOL-C is used internally
to compute certain derivatives.  In shows because certain objects
need to be instantiated with adouble as the number type.  One such
example is all objects derived from LocalDensity.

However, if this is to be avoided, then assemblers need to have
a way to turn a (e.g.) 'double' version of a density into an
'adouble' one.  This commit provides this way, by adding a
'makeActiveDensity' method.

Really more of a set of notes, currently.  In particular, it describes
how the element assembler works, which seems to complicated to me for
having only in-code documentation.

That construction method is simply enough that the derivatives
can be computed manually.  This avoids the overhead of using
an AD system.

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

The LocalIntegralStiffness assembles a tangent matrix by
suitably combining derivatives of the energy density with
derivatives of the geometric FE interpolation.  See the
detailed description in dune-gfe-manual.pdf.

This patch also includes a new test in localintegralstiffnesstest.cc.
It checks if the assembled matrix is the same as the one computed
by LocalGeodesicFEADOLCStiffness.

For a 3d Cosserat material I get a speedup of about 3x.

I am not too happy about this method, because for the scalar finite
element is an implementation detail.  But for the time being I need
this method for the upcoming LocalIntegralStiffness.

It is used by the upcoming LocalIntegralStiffness.

It is called 'geodesic interpolation' nowadays, no matter what domain.

Various minor fixes and improvements

See merge request osander/dune-gfe!154

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.

Fix nonconforming interpolation

See merge request osander/dune-gfe!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 osander/dune-gfe!152

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

See merge request osander/dune-gfe!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 osander/dune-gfe!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 osander/dune-gfe!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.