dune-solvers merge requestshttps://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/merge_requests2023-03-31T12:27:46Zhttps://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/merge_requests/73WIP: Extend `ProximalNewtonSolver` to more general `ProximalSolver`2023-03-31T12:27:46ZPatrick Jaappatrick.jaap@tu-dresden.deWIP: Extend `ProximalNewtonSolver` to more general `ProximalSolver`With this change we can use the structure of the Proximal Newton solver for problem with less differential order of the smooth part.
Things that need some further input:
- I want to provide shortcuts to `ProximalNewtonSolver` and `Proxi...With this change we can use the structure of the Proximal Newton solver for problem with less differential order of the smooth part.
Things that need some further input:
- I want to provide shortcuts to `ProximalNewtonSolver` and `ProximalGradientSolver` with aliases using `using`.
- However, this is a `C++20` feature if I want to omit the explicit template arguments
- The Methods `setHessian` etc. are only meaningful for `diffOrder > 1`. Is there a smooth SFINAE method to provide these methods only in this case?https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/merge_requests/58WIP: CholmodSolver: Allow to delete and add rows2022-06-25T11:56:49Zoliver.sander_at_tu-dresden.deoliver.sander@tu-dresden.deWIP: CholmodSolver: Allow to delete and add rowsAllow to update a factorization to the fact that a row/column has been deleted from the matrix. This is useful for TNNMG and active-set methods.
The functionality itself is provided by CHOLMOD, and this patch merely makes it accessible ...Allow to update a factorization to the fact that a row/column has been deleted from the matrix. This is useful for TNNMG and active-set methods.
The functionality itself is provided by CHOLMOD, and this patch merely makes it accessible in the interface.https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/merge_requests/47WIP: Implement an overlapping block Gauss-Seidel step2020-09-04T13:57:02Zoliver.sander_at_tu-dresden.deoliver.sander@tu-dresden.deWIP: Implement an overlapping block Gauss-Seidel stepThis patch brings a block Gauss-Seidel step implementation for a general
set of blocks. The blocks are specified at run-time, and they can
overlap.
I am not really sure yet what the final design should look like. Some open questions a...This patch brings a block Gauss-Seidel step implementation for a general
set of blocks. The blocks are specified at run-time, and they can
overlap.
I am not really sure yet what the final design should look like. Some open questions and things left to do are:
+ Do not hard-wire the type of the local matrix
+ Allow to choose different solvers for the local problems
+ Precompute the local matrices
+ For direct local solvers: Precompute the local factorizations
+ Is std::vector<std::vector> the best data structure for the blocks? Or would it make sense to make the data structure configurable?
Comments are welcome.https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/merge_requests/23WIP: Make getiterationstep return shared ptr2020-06-18T14:45:54Zoliver.sander_at_tu-dresden.deoliver.sander@tu-dresden.deWIP: Make getiterationstep return shared ptrThe method IterativeSolver::getIterationStep should return a shared_ptr rather than a reference. Since IterationStep is an abstract base class, code that calls getIterationStep frequently does dynamic casting afterwards. You cannot do ...The method IterativeSolver::getIterationStep should return a shared_ptr rather than a reference. Since IterationStep is an abstract base class, code that calls getIterationStep frequently does dynamic casting afterwards. You cannot do that with a reference though, unless using some trickery.
Unfortunately, simply changing the return type of the method is not backward compatible. This is why this merge request is marked as WIP. Any ideas on how to proceed?https://git.imp.fu-berlin.de/agnumpde/dune-solvers/-/merge_requests/12WIP: Control LoopSolver entirely through criteria2019-01-25T13:29:58ZpippingWIP: Control LoopSolver entirely through criteriaThese days, it's possible to add termination criteria and output to a `LoopSolver`
through a mechanism referred to as `Criteria` (a `Criterion` can track quantities
and/or print a summary of them, so that in particular something that j...These days, it's possible to add termination criteria and output to a `LoopSolver`
through a mechanism referred to as `Criteria` (a `Criterion` can track quantities
and/or print a summary of them, so that in particular something that just prints
information is covered by this general concept).
So far, the LoopSolver has only been extended in this direction, however: It still
does a lot of manual termination logic that should really be replaced through
criteria as well. @maxka has done a lot of work in this direction and in doing so
uncovered that the LoopSolver does quite a few things slightly differently than one
would expect: A straight-forward translation of its current termination criteria
leads to different criteria than the ones we currently provide as extensions.
First of all, I find it very nice that we're now able to analyse these differences
easily. And we might also want to switch to different default termination criteria
(a change that clearly should not be backported to a release branch without proper
thought and communication).
So what I've done here is just to take the branch `flexible-loopsolver-max` that's
already been around for quite a while without any changes, and turned it into a
merge request. I would like
to get this work merged because I consider it an improvement and I'd hate to see it
continue to accumulate dust and go untested. I'm also interest in comments as to why
merging this might be a bad idea. I believe that the work on this branch is in a state
where no additional code needs to be written (if that should turn out not to be true,
I'd volunteer to write that code), one might only want to squash a few commits, but
that is optional clearly optional.
This MR would also put as in a position to get rid of the `SolverResult` class, which
in its current state (a lesson for the future maybe?) I feel does more harm than good.
Its members have terrible names. And because it comes with the disclaimer "anything
could change any moment" you can't use it any code that you want to continue to work
in the future.
**Update**: There is at least one remaining TODO (with the output precision). I also
need to sort out all the merge conflicts.