Lisa Julia Nebel authored 5 years ago and Sander, Oliver committed 5 years ago

This class will gradually replace the current implementations
GlobalP1Mapper and GlobalP2Mapper, because dune-gfe is not
the proper place for infrastructure for distributed computing.
Plus, the stuff in dune-parmg already is more flexible and
powerful.

Lisa Julia Nebel authored 5 years ago and Sander, Oliver committed 5 years ago

dune-gfe contains a bit of home-grown infrastructure for distributed
assembly of the tangent stiffness matrix.  This will now be removed
in favour of dune-parmg code, for better maintainability.  Also,
eventually we want the parallel solver of dune-parmg in addition to
the parallel assembly.

The new dependency is optional, to cater for people without interest
in distributed computing.

Add missing std prefixes

See merge request !30

Up until dune-common 2.7, the Dune namespace contained shared_ptr:
First as an actual implementation, later simply as a namespace
import.  Dune-common post-2.7 has removed that import,
and users of shared_ptr really have to explicitly specify
the std:: namespace prefix.

Fix a few issues that I found using the clang sanitizer

See merge request !28

The svd code contains some index trickery, because the original code
was written in fortran, which numbers arrays starting from '1'
rather than from '0'.  This trickery included having a pointer point
1 int in front of an allocated array, implicitly relying on the
fact that pointer[0] would never be called.  The llvm sanitizer
complains nevertheless, so this patch improves the trickery a little
to avoid the objected pointer.

Scalar bases used to work for that, but that feature got
removed a long time ago.

Do this by making RodAssembler more similar to the generic
GeodesicFEAssembler: the constructor argument is now a
general LocalGeodesicFEStiffness, and not something particular
to rod problems.

Harmonicmap integration test

See merge request !25

The predicates do implement operator(), so let's use that.

This is needed to test against the 2.6 core modules.

This new test computes a harmonic map from a square to a sphere.
In other words, rather than testing some specific aspect of some
class, it does a whole simulation.  It should therefore cover
much more of the dune-gfe code.

Automatic testing of the RiemannianTrustRegionSolver class requires
to know what it did on the previous run.  This patch adds
some infrastructure to collect this information.

I wrote it without a clear idea of what is needed of such a
test function, and I never finished it.  Now it is unclear
what the code does or is supposed to do, so let's just
remove it.

.gitlab-ci.yml: test with dune-parmg installed and other configurations

See merge request !24

Use only LocalView objects, no LocalIndexSet ones

See merge request !23

This avoids 'implicit narrowing' errors/warnings.

For some reason only clang complains about this.

Using LocalIndexSet objects was mandatory with dune-functions-2.5
and earlier.  However, we only support 2.6 and later anyway,
so let's get rid of the backward-compatibility code.

In the test, the grid dimension was defined twice:  Once globally
at the top of the file, and once through a chain of template parameters.
This patch removes the global variable.

In principle, a serious bug: but for dimworld=3d (i.e., the standard)
this loop was never executed anyway.  Hence there were no serious
consequences.

Because it really is a functionality of rotation matrices in quaternion
representation.  Only the Cosserat energies use it at the moment, but
this is coincidental.

In the same process, the method is renamed to quaternionTangentToMatrixTangent.
That seems to be a more telling name.

Assignment from initializer lists makes this much shorter.

In particular, we move the test for the computeDR method from
cosseratenergytest.cc to here.  It is a method that does not
have anything to do with Cosserat mechanics directly.

The test still seems overly complicated.  Do I really need
a LocalGeodesicFEFunction?  Maybe I can simplify it later.

* Do not test with configurations that result in zero-area elements
  (because the energy is inf in these cases).
* Test for the relative energy difference, rather than the absolute one,
  because the energy values can get very large.

Previously, this test used a situation with geodesic interpolation
between two points on the sphere that are almost antipodal.
This made the TargetSpaceRiemannianTRSolver crash, because the
weighted sum of squared distances can have indefinite second
derivatives in such a situation.  In principle, the
TargetSpaceRiemannianTRSolver should handle this, but nowadays
it is not actually a TR solver anymore, but a plain local
Newton method.  Maybe I should revert back to trust-region.

I added a comment to targetspacetrsolver.cc that explains the
situation a little.

There is really no point in having this method.  Before it is called,
localgeodesicfefunctiontest already checks whether the derivative
is correct (by comparing with an FD approximation).  If a derivative
passes this test it MUST be tangential.  No need to check that
explicitly.