[[Imported from SVN: r9660]]

[[Imported from SVN: r9659]]

[[Imported from SVN: r9658]]

[[Imported from SVN: r9657]]

This prepares for a later switch to a second-order basis

[[Imported from SVN: r9656]]

[[Imported from SVN: r9655]]

[[Imported from SVN: r9654]]

[[Imported from SVN: r9653]]

Use its size rather than the number of grid vertices

[[Imported from SVN: r9652]]

Adjust values of the shearing/wrinkling problem to the values given in the Taylor/Bertoldi/Steigmann paper

[[Imported from SVN: r9651]]

This move more than halfs the size of this file, and makes it *much* easier
to understand.  If we ever need the gradient code we can still recover it
from the 2.3-2 branch.

[[Imported from SVN: r9650]]

[[Imported from SVN: r9649]]

[[Imported from SVN: r9648]]

[[Imported from SVN: r9618]]

[[Imported from SVN: r9617]]

[[Imported from SVN: r9616]]

[[Imported from SVN: r9615]]

[[Imported from SVN: r9614]]

[[Imported from SVN: r9601]]

[[Imported from SVN: r9588]]

[[Imported from SVN: r9587]]

[[Imported from SVN: r9586]]

Assuming that the AverageDistanceAssembler can provide it.

This is for the Gram-Schmidt solver only.  The old Gauss-Seidel
code will still use a full matrix.

[[Imported from SVN: r9585]]

[[Imported from SVN: r9584]]

viz.:

field_type
blocklevel
operator=(scalar)

[[Imported from SVN: r9583]]

[[Imported from SVN: r9582]]

CG seems to converge to quickly.  If too few iterations are performed,
then ADOL-C has trouble determining the correct second derivatives.
Since the Gram-Schmidt solver is a direct solver, OTOH, the derivatives
should be perfect.  It is also faster than the Gauss-Seidel solver I
was previously using.

[[Imported from SVN: r9581]]

Nice, because it works for rank-deficient matrices.

And still fast enough for the systems I am considering here.

[[Imported from SVN: r9580]]

[[Imported from SVN: r9579]]

I hoped that this would be faster.  However, it seems to deterioate the
convergence of the outer trust region algorithm.  Apparently, the steps
taken by a CG make it difficult for ADOL-C to compute the correct
derivatives.

[[Imported from SVN: r9576]]

We have the correct value in the variable 'oldEnergy' anyway.

[[Imported from SVN: r9575]]

We normalize unit vectors again in the constructor and the assignment operator.
This makes sure we never drift away from the unit sphere, and it also allows
us to init unit spheres with any value in R^n and be sure we obtain a unit
vector.  This makes the test pass again.  Leaving the projection out didn't
really make a measurable difference anyway.

[[Imported from SVN: r9574]]

[[Imported from SVN: r9573]]

[[Imported from SVN: r9572]]

[[Imported from SVN: r9571]]

[[Imported from SVN: r9563]]

The old implementation used quaternion multiplication to transport
the argument to the Lie algebra, and use the standard formula there.
However, one may as well use the formula for the unit sphere in R^4,
which is much simpler, and also faster.  I fact, this patch gives
a few percent of speedup for the overall code.

[[Imported from SVN: r9562]]

There is one copy which takes FieldVector<T,4> as its second argument.
Since EmbeddedTangentVector ( = Quaternion<T>) derives from FieldVector<T,4>,
that second implementation should work in all cases.

[[Imported from SVN: r9560]]

The methods 

Rotation<T,3> exp(const Rotation<T,3>& p, const EmbeddedTangentVector& v) 

and

otation<T,3> exp(const Rotation<T,3>& p, const Dune::FieldVector<T,4>& v)

do literally the same.  So they should be next to each other in the code.

[[Imported from SVN: r9559]]

This effectively means that we use another prolongation of the distance 
function on M into the surrounding space.  Since the prolongation does not
matter this patch should not change the algorithm behavior.  However, it
shaves off a few norm calculations and division.  I cannot really measure
any difference though.

A possible effect of this is that while all values should remain on the
manifold, they may start to 'drift away' due to numerical artifacts.
So we may have to add an occasional renormalization step eventually.

[[Imported from SVN: r9558]]