In the code that takes the initial iterate from a while, a call
to 'interpolate' was out-commented, because interpolating an
'EmbeddedGlobalGFEFunction' was not possible back in the days.

That has changed so, and 'interpolate' can now be called.
I still doubt that the code ever worked or works now.
How could it ever be tested?

'#	geändert:       src/cosserat-continuum.cc

It is required by dune-fufem anyway.

Instead, use LocalIntegralEnergy and the newly introduced densities
for bulk models or planar shell models.

While doing so, give an error message when non-trivial volume loads
are requested.  I have no example file that actually uses them
at the moment, and just by looking at the code I find it hard to believe
that they actually worked.  Getting them to work will mean having
introduce a density for volume loads, which don't want to do
until I need them.

Since this is the last use of the CosseratEnergyLocalStiffness class,
this patch remove the entire class as well.

That way, we can also set the initial microrotation -- previously
it was hard-wired to the identity matrix.

Being able to explicitly choose the initial microrotation allows
to start, in particular, from a twisted strip.

Previously, the method basically hand-implemented a writer for
VTK files.  Using dune-vtk instead leads to much shorter and
simpler code, and gives us access to all the dune-vtk niceties,
like binary files and high-order grid cells.

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

That way, a single Python file is enough to describe the entire
boundary value problem.

Rather than as our homegrown .parset.  That way, after more changes
this will allow to have the entire problem description in a single
file, including the boundary data.

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.

They do the same thing, essentially.

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

The new method is Fufem::markBoundaryPatchDofs, which apparently
works in just the same way.

The ProductManifold class generalizes RigidBodyMotion, and can do
everything that the RigidBodyMotion class can.  Therefore there is
no point in keeping RigidBodyMotion any longer.  Having two
implementations for the same thing will just confuse people.

In particular:
- Use the CosseratVTKWriter also for MIXED_SPACE = 1, only print out the deformation though
- Use a SubsamplingVTKWriter only for dim==gridDim==3

Use the grid function provided by the gmsh4-reader as the stressfreegridfunction in nonplanarcosseratshellenergy

This only works for gmsh-files with version 4 or 5, but this is what we want

Add option to define deformation Dirichlet values for each direction separately in cosserat-continuum

Make GFE_ORDER and LFE_ORDER compiler macros and build the necessary combinations of cosserat-continuum-Xd-in-Xd

To build these combinations with the CI-system, install foamgrid for the tests with parmg, vtk, curvedgeometry and curvedgrid

Instead of loading the volume load as a fixed (x,y,z) vector, load it as a space-dependent Python function

Correct the dimension of the rotation and the deformation in the compositeBasis, it needs to be 3, independent of dim