I don't think it is worth keeping it, even if it may be
a bit faster than the general code.

The class LocalGfeTestFunctionBasis was removed in a recent commit,
and I forgot to remove a friend declaration for it.

This patch contains only whitespace changes.

Previously, some code was in Dune::GFE, some was in Dune::,
and a lot of it was in the global namespace.

I wrote them years ago mainly because I thought they should exist.
But they were never actually used them for anything, and I don't
really know were they could be used either.  Supposedly they
could be useful for implementing problems without a minimization
formulation, but that's not currently planned, and I don't know
what the precise requirements would be, either.

Since the code is short and almost trivial, and easily resurrected,
this commit removes the two files.  For newcomers this will mean
two less files to wonder about.

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.

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

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.

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.

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.

Using FieldMatrix<,1,1> for scalars has been the standard Dune way
for a long time, but since dune 2.7 using scalars directly works
just as well.

So far, the Cosserat rod energy implementation hat a first-order
finite element space hardcoded.  This patch removes that restriction.
As for the other models in this Dune module, the finite element basis
is now a template parameter of the model energy, and can be set to
any reasonable basis.

I found those wrong types when trying to use a HarmonicEnergyStiffness
with a RigidBodyMotion.

Running the test aborts with an error, because the error is exactly
the same as before this patch.

In theory this is dangerous, because a pure Newton method will
only converge locally.  However, the trust-region part had been
partially disabled anyway, and I have not noticed any problems.
Also, I think that from my well-posedness result for higher-order
GeoFEs follows that a Newton method will always converge if the
problem is well-posed (that is how the proof works, after all).

On the plus side, this patch brings roughly 5% speed increas.

Introduce a dedicated class LocalQuickAndDirtyFEFunction to produce initial iterates for the GFE minimization problems

Previously, a LocalProjectedFEFunction was used for this.  This turned out to be a bad idea for two reasons:
- Evaluating such a function can actually pretty expensive.  For example,
  to project onto SO(3), the polar decomposition needs to be evaluated by
  an iterative method.
- Screwing up the LocalProjectedFEFunction implementation can actually screw up
  the GFE implementation as well in very subtle ways.  Specifically, if the
  LocalProjectedFEFunction is not ADOL-C-differentiable, then the GFE function
  will not be differentiable, either.  This fact cost me a few hours searching...

[cleanup] Move the FD approximation of the GFE function gradient from the GFE function into the test

It is a part of the test harness, and should not clutter the implementation of the
GFE functions themselves.

Patch by Jonathan Youett

[[Imported from SVN: r10056]]

It sometimes creates problems with ADOL-C.

[[Imported from SVN: r9841]]

Amazingly, this really does have a measurable effect on the overall computation
speed.  Assembly times for the global Hessian and gradient for the Cosserat shell
energy problem drop by about 5% (!)

[[Imported from SVN: r9837]]

[[Imported from SVN: r9813]]

This has two advantages:
- The two matrices use different number types (adouble vs. double),
  but the generic multiplication in dune/istl/matrix.hh doesn't support
  that.  Hence before this change I had to patch dune-istl.
- It avoids one extra copying operation

[[Imported from SVN: r9703]]

The new initial iterate is constructed by interpolating the values in Euclidean
space, and projecting back onto TargetSpace.  This has two advantages:
1) It's a better initial iterate, so we should converge faster than starting
   from coefficients_[0]
2) It makes it easier for ADOL-C to pick up correct second derivatives.
   Hence we are able to reduce the minimum number of iterations of the
   target space tr solver.

[[Imported from SVN: r9683]]

[[Imported from SVN: r9588]]

[[Imported from SVN: r9404]]

[[Imported from SVN: r9403]]

[[Imported from SVN: r9381]]

[[Imported from SVN: r9380]]

[[Imported from SVN: r9378]]

[[Imported from SVN: r9309]]

[[Imported from SVN: r9306]]

[[Imported from SVN: r9299]]

[[Imported from SVN: r9298]]

[[Imported from SVN: r9297]]