depending on a preprocessor define we switch the base classes to be
pure virtual, or implement a dummy category(). If the classes are pure
virtual the old interface with an enum is not possible anymore.

To enable/disable the backwards compatibility check we provide a cmake
flag DUNE_ISTL_SUPPORT_OLD_CATEGORY_INTERFACE, which defaults to 1
(e.g. backwards compatibility enabled).

- we add helper code to extract the solver category from the enum
  or the virtual function
- we update the base classes to actually use this code to perform
  consistency checks

We introduce a new method category to check for the same SolverCategory of different
components at run time.

This is a drawback compared to compile time checks, but it adds a lot of flexibility as we will
be able to  write factory classes for solvers and compose/exchange solvers at runtime.

Besides this we added the following changes:
- an additional intermediate class IterativeSolver encapsulates the data of almost all solvers
- the solvers now inherit from IterativeSolver and can usually reuse its constructor
- the solvers now only have to implement _one_ apply method, the other is implemented
  generically

State:
- currently the example compiles
- none of the AMG headers has been updated yet

[test] We removed the deprecated constructors of RestartedGMResSolver. Don't test the old constructor.

Feature/improve simd handling

See merge request !86

[cleanup] replace deprecated type trait

See merge request !82

Felix Gruber authored 8 years ago and Felix Gruber committed 8 years ago

The enable_if implementation defined in dune-common is deprecated.

Change module version number to 2.6-git

See merge request !81

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?