dune-amdis issueshttps://gitlab.math.tu-dresden.de/spraetor/dune-amdis/issues2019-02-22T17:51:44Zhttps://gitlab.math.tu-dresden.de/spraetor/dune-amdis/issues/13Gridfunction compatible to dune::functions::gridFunctions2019-02-22T17:51:44ZPraetorius, SimonGridfunction compatible to dune::functions::gridFunctionsMake the gridfunction compatible to the gridfunction concept defined in dune-functions. Therefore, we need to introduce entitySets for abstract gridfunctions, e.g. AnalyticGridFunction and ConstantGridFunctions. Some questions need to be answered, e.g.
- What is the common EntitySet of a FunctorGridFunction
- Is it necessary to introduce DerivativeTraits or can be stick with the defaultsMake the gridfunction compatible to the gridfunction concept defined in dune-functions. Therefore, we need to introduce entitySets for abstract gridfunctions, e.g. AnalyticGridFunction and ConstantGridFunctions. Some questions need to be answered, e.g.
- What is the common EntitySet of a FunctorGridFunction
- Is it necessary to introduce DerivativeTraits or can be stick with the defaultsRelease 0.2https://gitlab.math.tu-dresden.de/spraetor/dune-amdis/issues/9Bug with the new Output.hpp2018-10-17T12:28:41ZMÃ¼ller, FelixBug with the new Output.hpp```cpp
msg("Hello ", "World: ", 123); // prints "Hello \n"
```
Only the first argument is printed. The problem occured after updating develop to the newest version and seems to be related to commit 493a72466ec63f664cb6545f1604c8659c5da122.```cpp
msg("Hello ", "World: ", 123); // prints "Hello \n"
```
Only the first argument is printed. The problem occured after updating develop to the newest version and seems to be related to commit 493a72466ec63f664cb6545f1604c8659c5da122.https://gitlab.math.tu-dresden.de/spraetor/dune-amdis/issues/6Cleanup of CMake files2018-10-05T21:20:18ZPraetorius, SimonCleanup of CMake filesThe structure of cmake files is not optimal yet. TODO:
- add `CMakeLists.txt` to each subdirectory
- Do not manually set MTL flags
- add required packages (like MTL) to `cmake/modules/AMDiSMacros.cmake`The structure of cmake files is not optimal yet. TODO:
- add `CMakeLists.txt` to each subdirectory
- Do not manually set MTL flags
- add required packages (like MTL) to `cmake/modules/AMDiSMacros.cmake`https://gitlab.math.tu-dresden.de/spraetor/dune-amdis/issues/4VTKWriter with correct solution names2018-01-27T23:18:26ZPraetorius, SimonVTKWriter with correct solution namesSomehow the DOFVector-names of the solution vector is not included in the VTU files.Somehow the DOFVector-names of the solution vector is not included in the VTU files.https://gitlab.math.tu-dresden.de/spraetor/dune-amdis/issues/5Remove dependency on boost2018-01-27T23:18:02ZPraetorius, SimonRemove dependency on boost- remove `boost::program_options`, by using `Dune::ParameterTreeParser` with methods `readOptions`, and `readNamedOptions`
- remove `boost::property_tree`, by using `Dune::ParameterTree` with `IniParser`. Possibly extend the implementation by include files, math expression parser and variables
- remove `boost::math`- remove `boost::program_options`, by using `Dune::ParameterTreeParser` with methods `readOptions`, and `readNamedOptions`
- remove `boost::property_tree`, by using `Dune::ParameterTree` with `IniParser`. Possibly extend the implementation by include files, math expression parser and variables
- remove `boost::math`https://gitlab.math.tu-dresden.de/spraetor/dune-amdis/issues/3DiscreteGlobalBasisFunction as basis for DOFVector2017-12-18T22:27:42ZPraetorius, SimonDiscreteGlobalBasisFunction as basis for DOFVectorIn `dune-functions` several data-structures exist, that may be a good basis for the implementation of `DOFVector`s. Currently, a DOFVector is parametrized with a global function-space basis, e.g. `Dune::PQkNodalBasis` and has internal vector datastructure, for holding DOF coefficients.
On the other hand a `Dune::DiscreteGlobalBasisFunction` is parametrizes with a global function-space basis, a tree-path, a vector container, and a `NodeToRangeEntry`. Currently I don't know what's the meaning of
- TreePath
- NodeToRangeEntry
It can construct a `LocalFunction` that can be evaluated at local coordinates in the element. The basis and the coefficients can be accessed and maybe in the future an evaluation at global coordinates might be implemented.In `dune-functions` several data-structures exist, that may be a good basis for the implementation of `DOFVector`s. Currently, a DOFVector is parametrized with a global function-space basis, e.g. `Dune::PQkNodalBasis` and has internal vector datastructure, for holding DOF coefficients.
On the other hand a `Dune::DiscreteGlobalBasisFunction` is parametrizes with a global function-space basis, a tree-path, a vector container, and a `NodeToRangeEntry`. Currently I don't know what's the meaning of
- TreePath
- NodeToRangeEntry
It can construct a `LocalFunction` that can be evaluated at local coordinates in the element. The basis and the coefficients can be accessed and maybe in the future an evaluation at global coordinates might be implemented.https://gitlab.math.tu-dresden.de/spraetor/dune-amdis/issues/2Smart pointers for operator-terms2017-12-18T22:27:20ZPraetorius, SimonSmart pointers for operator-termsIn `Operator` the list of operator-terms for (zot, for, and sot) is stored as `std::list<OperatorTermType*>`. In `addZOT`, `addFOT`... the argument is copied and a new `GenericOperatorTerm` is allocated on the heap using the copy-constructor. This leads to a duplication of construction and the raw-pointer returned by `new GenericOperatorTerm` is never deleted. Maybe it is better to use smart-pointers there, and to not copy always the operator-term, only in the case that it is a temporary.In `Operator` the list of operator-terms for (zot, for, and sot) is stored as `std::list<OperatorTermType*>`. In `addZOT`, `addFOT`... the argument is copied and a new `GenericOperatorTerm` is allocated on the heap using the copy-constructor. This leads to a duplication of construction and the raw-pointer returned by `new GenericOperatorTerm` is never deleted. Maybe it is better to use smart-pointers there, and to not copy always the operator-term, only in the case that it is a temporary.https://gitlab.math.tu-dresden.de/spraetor/dune-amdis/issues/7exchange grid-traverse and matrix-block-traverse2017-12-18T22:26:48ZPraetorius, Simonexchange grid-traverse and matrix-block-traverseCurrently for each matrix-block and rhs-block the grid is traversed again. This forces the implementation to initialize the localView and localIndexSet again on each element, and also to create a geometry for each element again. Also, it forbids to use a composite basis to assemble into a block or a composite matrix.
Better, exchange these two loops.Currently for each matrix-block and rhs-block the grid is traversed again. This forces the implementation to initialize the localView and localIndexSet again on each element, and also to create a geometry for each element again. Also, it forbids to use a composite basis to assemble into a block or a composite matrix.
Better, exchange these two loops.