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.

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.

They do the same thing, essentially.

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

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.

This is needed to actually compare the 3D-model with the 2D-approximation

Use correct vector type for the combination of displacement and rotation in geodesicfeassemblerwrappertest

Virtual Function is deprecated after dune 2.7.

Add a GeodesicFEAssemblerWrapper - it wraps a MixedGFEAssembler so it can be used like a GeodesicFEAssembler

The GeodesicFEAssemblerWrapper assembles the Gradient and the Hessian using the MixedGFEAssembler and then
resturctures them so they can be used with the normal RiemannianTRSolver.
This only works, if the FE spaces have the same order.