dune-solvers issueshttps://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues2022-01-06T13:02:50Zhttps://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues/22Random failures of both `umfpacksolvertest` and `cholmodsolvertest` on `git-d...2022-01-06T13:02:50ZPatrick Jaappatrick.jaap@tu-dresden.deRandom failures of both `umfpacksolvertest` and `cholmodsolvertest` on `git-debian-11-gcc-9-20`For some time both test fail for no obvious reason. I am not able to reproduce it locally.
I struggled to narrow down the root cause with a lot of different CI configs in this MR (https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/mer...For some time both test fail for no obvious reason. I am not able to reproduce it locally.
I struggled to narrow down the root cause with a lot of different CI configs in this MR (https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/merge_requests/62) and also in my fork (https://git.imp.fu-berlin.de/patrick.jaap_at_tu-dresden.de/dune-solvers/-/pipelines)
The worst observation was that on the same commit the test passed once and failed once
https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/jobs/171102 vs https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/jobs/171173
The basic analysis tools for undefined behavior (`valgrid`,`gcc` flags) reported no problems.https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues/21Some combination of Ipopt segfaults with clang 6 c++172018-10-18T10:01:37ZakbibSome combination of Ipopt segfaults with clang 6 c++17The CI segfaults when running the quadraticipopttest with clang 6 c++17.
Hence I temporarily deactivated the test for this combination in ca17537d1The CI segfaults when running the quadraticipopttest with clang 6 c++17.
Hence I temporarily deactivated the test for this combination in ca17537d1https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues/19Criteria for loopsolver bare dangers with copy construction2018-06-18T12:33:36ZmaxkaCriteria for loopsolver bare dangers with copy constructionCriteria that refer to a specific solver or iteration step at construction time are dangerous.
The constructed solver should not be copy/move-constructible since the criteria it contains may be(come) invalid.
IMHO the respective solvers...Criteria that refer to a specific solver or iteration step at construction time are dangerous.
The constructed solver should not be copy/move-constructible since the criteria it contains may be(come) invalid.
IMHO the respective solvers should either be non-copy/move-constructible (in the best case this is induced by the respective criteria revoking the operation) or the respective solver must be retrieved not on-construction but on-call (which would require an interface change for `Criterion::operator()()` (which might imply more changes that I am not aware of).
P.S. The same applies to other (experimental) solvers that use the `Criterion` framework, e.g. flexible-loopsolver and `CriterionIterationSolver`.https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues/18MultigridStep does not actually check if TransferOperators are set2017-11-14T12:09:39ZmaxkaMultigridStep does not actually check if TransferOperators are setAlthough the `preprocess` method seems to test for the transfer operators, there is no mechanism to check if the transfer operators have been set at all. Since not calling the `setTransferOperators` method results in the derived number o...Although the `preprocess` method seems to test for the transfer operators, there is no mechanism to check if the transfer operators have been set at all. Since not calling the `setTransferOperators` method results in the derived number of levels to be deduced as 0, no error occurs. I understand that a trivial setup (i.e. no transfer hierarchy) should not cause failure.
I believe there was such a check back in 2012 when the number of levels was not deduced from the transfer operators given. While I do not support reintroducing a parameter for the expected number of levels, I would expect some kind of safety to protect users of this class from believing to use a multigrid scheme while actually only solving with the base solver.
Maybe an approach could be to require the `setTransferOperators` method to be called (and check a corresponding flag when preprocessing).https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues/17Get rid of common/tuplevector.hh2017-11-10T12:59:24ZmaxkaGet rid of common/tuplevector.hh... because it is in dune-common.... because it is in dune-common.https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues/16MonotoneMGStep inherits from MultigridStep2017-10-09T14:40:31ZmaxkaMonotoneMGStep inherits from MultigridStep... though it is not a `LinearIterationStep`.
This also caused trouble with a7e17300 (reverted in a2547fe8) because the `MonotoneMGStep` modifies the transfer operators.
If there is a huge overlap of code for `MonotoneMGStep` and `Mul...... though it is not a `LinearIterationStep`.
This also caused trouble with a7e17300 (reverted in a2547fe8) because the `MonotoneMGStep` modifies the transfer operators.
If there is a huge overlap of code for `MonotoneMGStep` and `MultigridStep`, in particular to provide all the mg members and their setters and getters, maybe a separate base class is a convenient solution.https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues/15Move generic vector and matrix tools to dune-matrix-vector2017-10-01T09:55:33ZmaxkaMove generic vector and matrix tools to dune-matrix-vectorThis module still exhibits some tools that should be accessible via the `dune-matrix-vector` module.
By b9f5301b some functionality has been moved and generalized, but a lot of things still remain.
A todo list follows:
- [ ] genericvec...This module still exhibits some tools that should be accessible via the `dune-matrix-vector` module.
By b9f5301b some functionality has been moved and generalized, but a lot of things still remain.
A todo list follows:
- [ ] genericvectortools.hh
- avoid the `GenericVector` struct to allow for (ADL reliant) specialializations
- [ ] resize.hh (provides `resizeInitialize*`, consider integrating into dune-matrix' resize.hh)
- [ ] staticmatrixtools.hhhttps://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues/12RFC: Use of min/max, fmin/fmax, etc.2017-05-09T09:28:38ZpippingRFC: Use of min/max, fmin/fmax, etc.If you have two doubles `x` and `y` and you'd like to take their maximum, you have quite a few options.
```c++
fmax(x, y); // calls the C function
std::max(x, y); // resolves to std::max<double>(x, y)
std::fmax(x, y); // resolves to ...If you have two doubles `x` and `y` and you'd like to take their maximum, you have quite a few options.
```c++
fmax(x, y); // calls the C function
std::max(x, y); // resolves to std::max<double>(x, y)
std::fmax(x, y); // resolves to std::fmax<double>(x, y)
```
I think we should not be using `std::max` at all (except for integer types), because it does not handle `NaN`s gracefully (unfortunately, it's what we use almost everywhere). E.g. the following programme
```c++
#include <cmath>
#include <iostream>
int
main() {
double const mynan = std::nan("");
std::cout << std::max(1.0, mynan) << std::endl;
std::cout << std::max(mynan, 1.0) << std::endl;
}
```
prints
```
1
nan
```
for me, which is useless and also not reliable. `std::fmax` exists for this purpose.
But I think we also should not be writing `std::fmax` directly instead. Rather, I'd like to advocate
```c++
using std::fmax;
fmax(x, y);
```
thereby enabling ADL for types like `adouble`. The fact that we're currently not doing that
has forced someone to put
```c++
namespace std
{
adouble max(adouble a, adouble b) {
...
}
}
```
in `dune/fufem/utilities/adolcnamespaceinjections.hh` which from my reading of the standard (quoted [here](http://stackoverflow.com/a/41062439/179927)) is not allowed.
To be precise, I think
```c++
namespace std
{
template<>
adouble const &max(adouble const &a, adouble const &b) {
...
}
}
```
would be allowed in this case but I'd rather not see `std` extended unless
absolutely necessary.
So to summarise, I would like us to use
```c++
using std::fmax;
fmax(x, y);
```
in place of `fmax`, `std::max`, and `std::fmax` for floating point types everywhere
because it handles `NaN` properly and works in conjunction with ADL. If we can get
a consensus on this matter (for dune-fufem, dune-solvers, etc.) I'll happily go ahead
and do the actual work. I'd first like to collect comments and opinions, though.
NB: `DenseVector::infinity_norm` has a `using` clause just like this to get ADL to
work properly but then uses `std::max` instead of `std::fmax`. That's intentional here,
because a `NaN` should propagate!https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues/9Workaround for constexpr difference in c++11 and c++142018-01-26T12:41:23ZmaxkaWorkaround for constexpr difference in c++11 and c++14As appearing and commented in 3c2d0b9a5b922bdaaaa11e4f1aec265b428ae00b,
maybe a macro would solve this issue providing the respective correct functionality in dependence of the version of the c++ standard used.As appearing and commented in 3c2d0b9a5b922bdaaaa11e4f1aec265b428ae00b,
maybe a macro would solve this issue providing the respective correct functionality in dependence of the version of the c++ standard used.https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues/8Block Gauss--Seidel steps and related tests2018-01-26T12:41:23ZmaxkaBlock Gauss--Seidel steps and related tests- [ ] deprecate current redundant solvers
- [x] test non-scalar block problems where local ignore nodes are not either all true or all false
- [x] test that ignore nodes are respected.
- [x] currently the ProjectedBlockGS is tested, b...- [ ] deprecate current redundant solvers
- [x] test non-scalar block problems where local ignore nodes are not either all true or all false
- [x] test that ignore nodes are respected.
- [x] currently the ProjectedBlockGS is tested, but the obstacles are not relevant to the exact solution
- [ ] provide implementation for cachedldlt local solver (necessary?)
- [ ] extend the framework to support nonlinear steps, e.g. `::ProjectedBlockGS` (overlap with dune-tnnmg/feature/new_tnnmg)
- [ ] allow more deeply nested blocks (and ignore nodes)
- [ ] extend recursively, in analogy to the `::TruncatedBlockGS` class
- [ ] provide Gauss--Seidel loop that accounts for a SumOperator with LowRankFactor (eventually enables fully replacing `::TruncatedBlockGSStep`)
- [ ] test TrustRegionGSStep (in an appropriate setting, i.e. with non-convex block problems)
- [ ] provide some mechanism or at least satisfying documentation to warn about local solvers eventually not generating a symmetric linear iteration step despite the outer Gauss--Seidel loop being symmetric (i.e. forward and backward)
- [ ] provide a test that assures that non-existing (diagonal) blocks yields the same result as zero (diagonal) blocks.
- [ ] provide checks (or at least documentation) that semidefinite diagonal blocks impose assumptions on the sanity of the rhs.
- [ ] make use of row iterators (maybe using a range-based for wrapper to be provided to dune-common or dune-matrix-vector soon)
- [ ] allow for generic ignore nodes implementations (out-source the usage of `any()` and alike because the ignore nodes type might not provide these methods)
- [ ] remove support for an ignore node set that is not set (i.e. add existence checks before the actual solve and do not create temporary local ignore nodes)https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues/7Remove IterativeSolver::writeIterate()2018-01-26T12:41:23ZgraeserRemove IterativeSolver::writeIterate()This method writes a user supplied vector into a file whose name is build by a user supplied number and a prefix. The only reason why this is non-const, is that the prefix is stored as a member. This is orthogonal to what the solver does...This method writes a user supplied vector into a file whose name is build by a user supplied number and a prefix. The only reason why this is non-const, is that the prefix is stored as a member. This is orthogonal to what the solver does and can better be achieved by a separate iteration step that adds the monitoring feature.https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/issues/4IterationStep getSol() superfluous or wrong2018-01-26T12:41:23ZmaxkaIterationStep getSol() superfluous or wrongIterationStep provides a method getSol() that currently returns a VectorType. IMHO this is not in accordance with the associated comment ("return solution object") or superfluous as the solution (`VectorType* x_`) is public anyway. Most(...IterationStep provides a method getSol() that currently returns a VectorType. IMHO this is not in accordance with the associated comment ("return solution object") or superfluous as the solution (`VectorType* x_`) is public anyway. Most(all?) IterationSteps simply implement `return *(this->x_);`.
I am not sure what was the original incentive for this method.
Maybe `x_` should be private (or protected) instead? Then a default implementation for getSol() would improve readability IMHO.
Maybe an actual solution object was intented in addition and it never has been implemented?