amdis-core merge requestshttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests2019-04-26T20:36:29Zhttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/30Example/surface grid2019-04-26T20:36:29ZPraetorius, SimonExample/surface gridhttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/29add operator+= to transposed view2019-03-28T11:33:56ZPraetorius, Simonadd operator+= to transposed viewhttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/28make tuple_size and tuple_element a class2019-03-28T11:33:48ZPraetorius, Simonmake tuple_size and tuple_element a classhttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/27Issue/amdisproject executable2019-03-28T12:09:12ZPraetorius, SimonIssue/amdisproject executablehttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/26Parallel ISTL2019-06-14T08:36:05ZMüller, FelixParallel ISTLThis changes the linear algebra interface such that parallel linear algebra backends can be used and provides the implementation of the interface for parallel ISTL solvers.
Adds:
- Support for parallel ISTL solvers using the current ...This changes the linear algebra interface such that parallel linear algebra backends can be used and provides the implementation of the interface for parallel ISTL solvers.
Adds:
- Support for parallel ISTL solvers using the current solver interface
- Runtime switch for overlap type of the ISTL solver used
- `solver->category: [default, sequential, nonoverlapping, overlapping]` initfile parameter
- `Comm` object for the linear algebra interface that is to be used as a container for all required information for running the backend's solvers in parallel
- Implementation of the `Comm` object for ISTL
Changes:
- Linear algebra classes now use a `Traits` class as template parameter
TODO:
* [x] Check if `Grid` uses overlap and use `[Non]OverlappingSchwarzOperator`
* [x] Provide an efficient method for computing the parallel index set
* [x] ~~Resolve all `TODO(FM)` markers~~
* [x] ~~Make an alternative implementation for nonoverlapping Schwarz~~
* [x] ~~Handle the corner case `overlapSize + ghostSize == 0`~~
* [x] Add an example or test file
* [x] ~~Update assembler element loops to use the proper partition set~~
Relates to #4.Müller, FelixMüller, Felixhttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/25Rewrite adaption interface to allow to attach bases to the grid-transfer2019-04-26T11:23:41ZPraetorius, SimonRewrite adaption interface to allow to attach bases to the grid-transferThe GlobalBasis needs to be updated after each grid change. So, we have added a list of callbacks that are called in the `GridTransfer` class in `preAdapt()`, after `adapt()` and in `postAdapt()`. There are two types of supported data:
...The GlobalBasis needs to be updated after each grid change. So, we have added a list of callbacks that are called in the `GridTransfer` class in `preAdapt()`, after `adapt()` and in `postAdapt()`. There are two types of supported data:
1. Classes with `preAdapt(bool)` and `postAdapt(bool)`
2. Classes with `update(gridView())`
The first one is typically implemented by data containers that need interpolation. The second one is implemented by a basis.
The `DOFVector` and its basis are automatically registered in the GridTransfer in construction of the `DOFVector`. If you have a data-container or a basis independent of a DOFVector you have to attach (and detach before destruction) yourself. Therefore, simply call
```c++
GridTransferManager::attach(grid, data); // or
GridTransferManager::detach(grid, data);
```
where data must implement on of the interface 1. or 2., described also in the `AdaptionInterface.hh`.
Note, the adaption cycle works as follows:
1. preAdapt
2. adapt
3. update
4. postAdapt
So, in the postAdapt step we can assume that all update callbacks are executed. The order of the update methods could be random, though. And also the order of the pre/postAdapt callbacks is arbitrary.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/24change the default DataTransferOperation to INTERPOLATE2019-03-27T16:18:33ZPraetorius, Simonchange the default DataTransferOperation to INTERPOLATEIt is the source of some errors if by default data is not interpolated during grid changes. If the user knows what she does, she can set `NO_OPERATION` manually, but for all other users `INTERPOLATE` is the better choice.It is the source of some errors if by default data is not interpolated during grid changes. If the user knows what she does, she can set `NO_OPERATION` manually, but for all other users `INTERPOLATE` is the better choice.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/23reimplement interpolate function with averaging2019-04-26T13:51:45ZPraetorius, Simonreimplement interpolate function with averagingReplace `Dune::Functions::interpolate` with own implementation based on the dune-functions implementation. Here, I want to allow non-smooth (non-continuouse) functions in the interpolation. Thus simple nodal-interpolation does not work. ...Replace `Dune::Functions::interpolate` with own implementation based on the dune-functions implementation. Here, I want to allow non-smooth (non-continuouse) functions in the interpolation. Thus simple nodal-interpolation does not work. A first strategy is implementated, namely node-averaging. A counter is added that counts how often a values is added to a DOF and after the interpolation the DOF value is divided by this counter value.
Other strategies that could be added:
- Clement type interpolation (using local L2 projection)
- Evaluation in *super-convergent* points, i.e. average over evaluations in the element barycenters
- Least-squares approximation
- [x] Therefore, the interface of `interpolate()` must be extended to support some kind of `strategy` flag.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/21boundary-manager traverse over leafgridview2019-03-26T11:09:04ZPraetorius, Simonboundary-manager traverse over leafgridviewThe reason for this change is, that not all Grids support traversal of intersection of non-leafgridview, e.g. AlbertaGrid.The reason for this change is, that not all Grids support traversal of intersection of non-leafgridview, e.g. AlbertaGrid.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/20virtual inheritance of ProblemTimeinterface in ProblemInstat2019-03-26T13:09:53ZPraetorius, Simonvirtual inheritance of ProblemTimeinterface in ProblemInstatUse virtual inheritance from ProblemTimeinterface for ProblemInstatBase, to allow diamond inheritance in coupling datastructures.Use virtual inheritance from ProblemTimeinterface for ProblemInstatBase, to allow diamond inheritance in coupling datastructures.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/19Implement the copy constructor for DiscreteFunction2019-03-27T16:19:03ZPraetorius, SimonImplement the copy constructor for DiscreteFunctionThis solves a bug in `LocalFunction` and `GradientLocalFunction` of `DiscreteFunction`. If copy constructed, the `subTree` member was a dangling pointer.
Maybe I have to add the copy-assignment operator as well. Or, better, a `swap()`...This solves a bug in `LocalFunction` and `GradientLocalFunction` of `DiscreteFunction`. If copy constructed, the `subTree` member was a dangling pointer.
Maybe I have to add the copy-assignment operator as well. Or, better, a `swap()` method.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/18add doxygen closing comment bracket2019-03-21T15:53:16ZPraetorius, Simonadd doxygen closing comment brackethttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/17Cleanup of examples for stokes equation2019-03-21T10:33:31ZPraetorius, SimonCleanup of examples for stokes equationThis is a cleanup MR, intended to provide the code for the first amdis presentationThis is a cleanup MR, intended to provide the code for the first amdis presentationhttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/16make eigen and mtl a system package2019-05-02T11:56:53ZPraetorius, Simonmake eigen and mtl a system packageRewrite find eigen and mtl in cmake to link against imported targets. This makes these external mackages system packages and thus compiler warning are not shown anymore. It hast to be checked which cmake version is required for this to w...Rewrite find eigen and mtl in cmake to link against imported targets. This makes these external mackages system packages and thus compiler warning are not shown anymore. It hast to be checked which cmake version is required for this to work. And it has to be checked whether we could do the same for other external packages in dune.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/15densematrix view for sparse matrices2019-03-21T09:04:42ZPraetorius, Simondensematrix view for sparse matricesAdd a View class that wraps sparse matrices so that they can be used as sparse matrix, i.e. provide const `operator[][]` access. This solves some bugs in operator terms with partial derivatives in case of `YaspGrid`.Add a View class that wraps sparse matrices so that they can be used as sparse matrix, i.e. provide const `operator[][]` access. This solves some bugs in operator terms with partial derivatives in case of `YaspGrid`.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/14parametrize BasisCreator with Grid instead of GridView2019-03-28T10:27:38ZPraetorius, Simonparametrize BasisCreator with Grid instead of GridViewWhen using a BasisCreator, like `LagrangeBasis` or `TaylorHoodBasis`, it is required that the `GridView` is a `LeafGridView`, since this is passed to the `create()` method in `createGlobalBasis()` of `ProblemStat`. So, instead of giving ...When using a BasisCreator, like `LagrangeBasis` or `TaylorHoodBasis`, it is required that the `GridView` is a `LeafGridView`, since this is passed to the `create()` method in `createGlobalBasis()` of `ProblemStat`. So, instead of giving the user the freedom to pass a different `GridView` than the leaf one, in the MR is Creator is parametrized with the `Grid` and the `GridView` is fixed to `LeafGridView`.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/13check whether BACKEND is either MTL, EIGEN, or ISTL2019-03-21T08:04:05ZPraetorius, Simoncheck whether BACKEND is either MTL, EIGEN, or ISTLhttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/12correct dimension in datatransfer checkInside for surface grids2019-03-19T22:29:33ZPraetorius, Simoncorrect dimension in datatransfer checkInside for surface gridshttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/11import mtl::size for size of std::vector2019-03-19T22:29:00ZPraetorius, Simonimport mtl::size for size of std::vectorhttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/merge_requests/10Instantiate ProblemStat and ProblemInstat for YaspGridBasis explicitly2019-03-26T16:18:46ZPraetorius, SimonInstantiate ProblemStat and ProblemInstat for YaspGridBasis explicitlyexplicit template instantiation can reduce compile time for derived projects significantly. In my test for the ellipt.2d example, I got 18sec with explicit instantiation and 40sec without. In need to be checked whether this procedure can...explicit template instantiation can reduce compile time for derived projects significantly. In my test for the ellipt.2d example, I got 18sec with explicit instantiation and 40sec without. In need to be checked whether this procedure can be extended to more grids and dimension, maybe by automatic source generation by cmake, i.e. generate explicit template instantiations in separate translation units for YaspGrid, AlbertaGrid, UGGrid, and ALUGrid for different dimension and LagrangeBasis of different degrees. These are 4x2x(3^n) instantiations. This, probably, should be made an non-default cmake option.