Feature/simd for multi rhs

Update the solvers to solve for multiple rhs vectors simultaniously. This makes use of SIMD abstractions in dune-common (see dune-common!16) to use vectors of SIMD vectors as `FieldType` of the right-hand-side. By this we can make immediate use of SIMD units in modern processors. Using SSE for example we get a speedup of 2 basically for free. This extension is useful whenever the same operator has to be solved for many rhs vectors, e.g. in the case of MS-FEM.

AMG Ist working as long as the coarse grid solver is an iterative solver. I therefore added an additional preprocessor macro to disable the direct coarse solver explicitly.

What is missing currently is multi-rhs support for the direct solvers. I'm preparing a separate merge request for this feature, which will add multi-rhs direct-coarse-grid support for the AMG.

See also: dune-common!81, dune-geometry!13.


See merge request !17

in the cond construction of givensrotation we have to take care the we
don't mix complex and real values.

Currently RestartedGMRes and MINRes don't work with multiple rhs, as
it is not straight forward to rewrite the Givens-rotation in a
vectorized way.

Feature/cleanup of eigenvalue solver docs

improve structure of the doxygen documentation to make the eigenvalue solvers visible and hide implementation details

See merge request !79

- create dedicated "eigenvalue solvers" group
- move implementation details into the "Impl" namespace
- minor cleanups of doxygen documentation

[CMake] install superlufunctions.hh

superlufunctions.hh which was introduced in !77 has to be installed as it is included by the installed headers superlu.hh and supermatrix.hh.

See merge request !78

This header is included by the installed headers superlu.hh and
supermatrix.hh.

Support various numeric types for SuperLU at once.

Previously, we only supported one numeric type (float, double, complex<float>,
or complex<double>) that the user could select via a cryptic preprocessor
define. This was done this way because when including SuperLU headers we
would otherwise have multiply defined structs in SuperLU. At least in 4.3
GlobalLU_t is defined in slu_sdefs.h, slu_ddefs.h, slu_cdefs.h, and
slu_zdefs.h

With this commit we do not include the problematic SuperLU headers anymore.
Instead why define the functions called by us with extern C within DUNE.
In addition we now provide all the numeric types for which SuperLU drivers are
found at the same time.

Hopefully this will also fix problems with multiply defined BLAS routines experienced
with arpack and SuperLU.

See merge request !77

Markus Blatt authored 8 years ago and Christoph Grüninger committed 8 years ago

Previously, we only supported one numeric type (float, double, complex<float>,
or complex<double>) that the user could select via a cryptic preprocessor
define. This was done this way because when including SuperLU headers we
would otherwise have multiply defined structs in SuperLU. At least in 4.3
GlobalLU_t is defined in slu_sdefs.h, slu_ddefs.h, slu_cdefs.h, and
slu_zdefs.h

With this commit we do not include the problematic SuperLU headers anymore.
Instead why define the functions called by us with extern C within DUNE.
In addition we now provide all the numeric types for which SuperLU drivers are
found at the same time.

Hopefully this will also fix problems with multiply defined BLAS routines experienced
with arpack and SuperLU.

reenable solvertest

... got 'lost' in the cmake transition

See merge request !75

[bugfix] This fixes an issue when UMFPack is found and AMG with field type float is used.

The selection of UMFPack as a direct solver does not only depend on UMFPack being found, but also whether the field type is double or complex<double>. Otherwise UMFPack cannot be used as a coarse solver in AMG. This PR fixes this issue.

@markus.blatt: Please take a look at this. 
@smuething: Please take a look at this. 

See merge request !51

Move various implementation classes into the 'Imp' namespace

There are various classes in dune-istl that are effectively implementation
classes internal to dune-istl. A few of them are base_array_unmanaged,
base_array_window, compressed_base_array_unmanaged,block_vector_unmanaged,
BlockVectorWindow, compressed_block_vector_unmanaged, CompressedBlockVectorWindow

See #22 for a brief
discussion.

This patch moves the classes into the namespace 'Imp'.  That way it is
clear that they are internal.

All code outside of dune-istl using those classes will break, but does
such code really exist?

See merge request !65

Oliver Sander authored 8 years ago and Ansgar Burchardt committed 8 years ago

There are various classes in dune-istl that are effectively implementation
classes internal to dune-istl. A few of them are base_array_unmanaged,
base_array_window, compressed_base_array_unmanaged,block_vector_unmanaged,
BlockVectorWindow, compressed_block_vector_unmanaged, CompressedBlockVectorWindow

See #22 for a brief
discussion.

This patch moves the classes into the namespace 'Imp'.  That way it is
clear that they are internal.

All code outside of dune-istl using those classes will break, but does
such code really exist?

is selected. Since UMFPack does not support this, it cannot be used in this
case.

[cleanup] fix some typos

See merge request !72

Mark various implementation classes as 'internal'

By using the doxygen \internal command.

See merge request !70

By using the doxygen \internal command.

Remove forbidden downcast

This removes several constructors and assignments from base class in the class hierarchy around `base_array`. These removed methods are all implemented using a downcast which may result in undefined behaviour.
Since they are not used anywhere in the core modules we can maybe remove them. According to @markus.blatt  these base classes are all meant to be internal.

This may cause problems if user code explicitly uses the raw base classes and these methods. However, such user code would only be valid if the passed base class reference is actually an upcasted derived class which is very unlikely.

See merge request !66

The implementation for this was hidden in the base classes
before and relied on undefined behaviour by using a downcast.
Now it is explicitly implemented for the derived classes
which also makes it more visible to users.

These constructors and assignments from base class are
all using a downcast which may result in undefined behaviour.
Since this is potentially dangerous and not used anywhere
in the core modules, this patch removes those methods.

These constructors and assignments are all implemented using
a downcast to derived class and may lead to undefined behaviour.
This commit removes the checks for these methods in preparation
for their removal.

Use `std::tuple` instead of `Dune::tuple`



See merge request !68

Fix implicit buildmode documentation and adjust test accordingly

This basically turns the issue #21 into a feature by correctly describing the constraints of the implicit build mode and the meaning of its parameters. This invalidates the test against the old interface description which is hence dropped by this MR. As a consequence the bcrsimplicitbuild-test passes again.

See merge request !63

Update test environments

- No longer test with clang 3.5.
- Add clang 3.8 from Debian 8 + backports
- Add gcc 5.4 + clang 3.8 from Ubuntu 16.04 LTS.
- Use `duneci-standard-test`

See merge request !64