dune-istl issueshttps://gitlab.dune-project.org/core/dune-istl/-/issues2019-12-19T22:34:16Zhttps://gitlab.dune-project.org/core/dune-istl/-/issues/56CreateVector of VariableBlockVector is broken2019-12-19T22:34:16ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.deCreateVector of VariableBlockVector is broken`VariableBlockVector` can be initialized by iterating over the blocks with a `CreateIterator` and setting the block sizes. This can be done by either calling the method `setblocksize(int)` on the iterator or by assigning the block size t...`VariableBlockVector` can be initialized by iterating over the blocks with a `CreateIterator` and setting the block sizes. This can be done by either calling the method `setblocksize(int)` on the iterator or by assigning the block size to the dereferenced iterator. The allocation is handled in the prefix `operator++()`. The iterator claims to be an output iterator, but it is in fact not even that, because assignment to the result of the postfix `operator++(int)` will fail to correctly initialize blocks. This became apparent when I replaced a call to `std::fill()` in the test suite with `std::fill_n()`, which calls the postfix operator. By assigning to the result of the postfix operator, the block size is stored in the temporary iterator returned by the postfix operator, and as that temporary is thrown away without ever having its prefix `operator++()` called, the corresponding block is never allocated.
AFAICT, the only real way of fixing this would be to cache the assigned block sizes in the `VariableBlockVector` instead of storing them in the iterator and to delay the block allocation until the iterator reaches the end state. This would, however, change the behavior of the vector.
I don't really use this thing, could someone with more experience perhaps chime in?DUNE 2.7.0https://gitlab.dune-project.org/core/dune-istl/-/issues/52BCRSMatrix: iterating over rows and accesing entries results in invalid memor...2018-07-11T11:53:50ZAnsgar Burchardtansgar.burchardt@tu-dresden.deBCRSMatrix: iterating over rows and accesing entries results in invalid memory accessUsing a loop over the rows of a `BCRSMatrix` of the form
```c++
for (auto row = m.begin(); row != m.end(); ++row) {
row[ row.index() ] = 1.0;
// m[row.index()][row.index()] = 1.0; // This is okay.
}
```
results in an invalid ...Using a loop over the rows of a `BCRSMatrix` of the form
```c++
for (auto row = m.begin(); row != m.end(); ++row) {
row[ row.index() ] = 1.0;
// m[row.index()][row.index()] = 1.0; // This is okay.
}
```
results in an invalid memory access reported by valgrind:
```
==12712== Invalid read of size 8
==12712== at 0x40408B: operator= (bvector.hh:798)
==12712== by 0x40408B: operator= (bvector.hh:1097)
==12712== by 0x40408B: main (test-bcrsmatrix-rowwise.cc:18)
==12712== Address 0xffe7d00 is 16 bytes after a block of size 80 in arena "client"
```
and crashes in my use of it.
The example program resulting in the valgrind output above is attached.
[test-bcrsmatrix-rowwise.cc](/uploads/4a6bbfc443e66e296cdae697f4e18f74/test-bcrsmatrix-rowwise.cc)DUNE 2.7.0https://gitlab.dune-project.org/core/dune-istl/-/issues/50SIMD-related build failure in CI when using clang 62018-12-12T14:25:48ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.deSIMD-related build failure in CI when using clang 6The new CI setup contains two tests with clang 6, which both fail to build due to some errors related to SIMD and Vc, e.g. https://gitlab.dune-project.org/core/dune-istl/-/jobs/42892.
See !220The new CI setup contains two tests with clang 6, which both fail to build due to some errors related to SIMD and Vc, e.g. https://gitlab.dune-project.org/core/dune-istl/-/jobs/42892.
See !220DUNE 2.7.0Jö Fahlkejorrit@jorrit.deJö Fahlkejorrit@jorrit.dehttps://gitlab.dune-project.org/core/dune-istl/-/issues/26Add a generic factory for solver setup using configuration from a ParameterTree2020-01-19T16:59:41ZChristian EngwerAdd a generic factory for solver setup using configuration from a ParameterTree**This is a followup on !5 and !1.**
The idea is to allow creating solvers / preconditioners from ParameterTrees.
A solver (including preconditioner) should be configurable via an ini file, similar to (we might want to change the seman...**This is a followup on !5 and !1.**
The idea is to allow creating solvers / preconditioners from ParameterTrees.
A solver (including preconditioner) should be configurable via an ini file, similar to (we might want to change the semantics slightly in some places...):
```
[solver]
precond = SeqSSOR
solver = CGSolver
[SeqSSOR]
iterations = 1
relaxation = 1.8
[CGSolver]
reduction=1e-9
maxit = 5000
verbose = 3
```
**Necessary steps:**
* [x] make interface classes really dynamic (see !84)
* [x] add constructors taking a `ParameterTree` (see !315)
* [x] use these new constructors in a solver factory (see !312)
* [x] rewrite the factories to use the `ParameterizedFactory` in `dune-common` (see !312)
* [x] review and cleanup the `ParameterTree` *"interface"*
* [x] remove static AMG configurations (coarse solver, smoother, etc) (explicit dispatch in !312)
* [x] switch `Hierarchy<T>` to use `std::shared_ptr` or `std::unique_ptr` for internal memory management instead of manual `new`/`delete`)(see !274 and !333)
1. introduce a value semantics wrapper class for the polymorphic interface classes
1. add concepts for simple precompilation for a range of field types, e.g. vectorized data.
1. review the concepts of how to instantiate and pre-compile the factoriesDUNE 2.7.0Christian EngwerChristian Engwer