- Apr 10, 2017
-
-
Christian Engwer authored
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
-
Christian Engwer authored
[test] We removed the deprecated constructors of RestartedGMResSolver. Don't test the old constructor.
-
- Apr 07, 2017
-
-
Christian Engwer authored
Feature/improve simd handling See merge request !86
-
- Mar 31, 2017
-
-
Christian Engwer authored
-
- Mar 27, 2017
-
-
Christian Engwer authored
-
- Jan 19, 2017
-
-
Christoph Grüninger authored
[cleanup] replace deprecated type trait See merge request !82
-
- Jan 18, 2017
-
-
The enable_if implementation defined in dune-common is deprecated.
-
- Jan 11, 2017
-
-
Christoph Grüninger authored
-
- Dec 23, 2016
-
-
Christoph Grüninger authored
Change module version number to 2.6-git See merge request !81
-
Christoph Grüninger authored
-
- Dec 15, 2016
-
-
Ansgar Burchardt authored
-
Christian Engwer authored
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
-
- Dec 13, 2016
-
-
Christian Engwer authored
in the cond construction of givensrotation we have to take care the we don't mix complex and real values.
-
Christian Engwer authored
-
Christian Engwer authored
-
Christian Engwer authored
-
Christian Engwer authored
-
Christian Engwer authored
-
Christian Engwer authored
-
Christian Engwer authored
-
Christian Engwer authored
-
Christian Engwer authored
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.
-
- Dec 09, 2016
-
-
Christian Engwer authored
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
-
Christian Engwer authored
-
Christian Engwer authored
- create dedicated "eigenvalue solvers" group - move implementation details into the "Impl" namespace - minor cleanups of doxygen documentation
-
Christian Engwer authored
-
- Dec 06, 2016
-
-
Christoph Grüninger authored
[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
-
Felix Gruber authored
This header is included by the installed headers superlu.hh and supermatrix.hh.
-
- Dec 05, 2016
-
-
Christoph Grüninger authored
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
-
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.
-
- Nov 25, 2016
-
-
Christian Engwer authored
reenable solvertest ... got 'lost' in the cmake transition See merge request !75
-
Christian Engwer authored
-
- Nov 22, 2016
-
-
Ansgar Burchardt authored
-
- Nov 17, 2016
-
-
Dominic Kempf authored
[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
-
Ansgar Burchardt authored
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
-
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?
-
- Nov 15, 2016
-
-
Robert K authored
is selected. Since UMFPack does not support this, it cannot be used in this case.
-
- Nov 11, 2016
-
-
Markus Blatt authored
[cleanup] fix some typos See merge request !72
-
- Nov 10, 2016
-
-
Felix Gruber authored
-
Felix Gruber authored
-