It is only used by `film-on-substrate.cc` which many people
do no use.

The NonplanarCosseratShellEnergy class contains a reimplementation of
the energy density of CosseratShellDensity.  The code is much easier
to understand and maintain if the density implementation of
CosseratShellDensity is used instead.

That is one step towards splitting off the energy density
into a separate class.

Also, it helps to unify the code paths for the different grid dimensions
in cosserat-continuum.cc

For this test to be really helpful it has to use curved grids.

In particular, there is a directory dune/elasticy/densities now.

The BulkCosseratDensity class implements three types of curvature
tensors. Previously, the preprocessor was used to select the one
to be actually used.  This patches removes the preprocessors checks
and implements run-time switches instead.

The test used CosseratEnergyLocalStiffness, which I am in the
process of getting rid of.  And since I eventually want to
get rid of GeodesicFEAssemblerWrapper too, it is not worth the time
to port the test.

... instead of the class CosseratEnergyLocalStiffness.  This is
one step in the quest to get rid of CosseratEnergyLocalStiffness
entirely.

* I did not really test a lot of useful stuff.
* The class CosseratLocalEnergyStiffness is deprecated anyway.
* It stopped compiling and I don't know why.

This removes one use of the CosseratEnergyLocalStiffness class,
which is scheduled for complete removal.

Energies of particular models should not implement external loads
themselves, because that would lead to a lot of code duplication
(and possible inconsistencies).  A one step towards that goal,
allow to construct a CosseratEnergyLocalStiffness object
without external loads.

Rather than the grid itself.  Because the grid view is all that
a writer needs to know about.

Instead of with LocalGeodesicFEADOLCStiffness.

The latter should be faster.

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.

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.

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.

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.

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.

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.

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.