-
Elias Pipping authoredElias Pipping authored
Code owners
Assign users and groups as approvers for specific file changes. Learn more.
TODO 2.99 KiB
# ToDo
## Bugs
These issues are not real bugs, but unexpected behaviour that might
lead to serious trouble if you're not aware of.
* ProjectedBlockGSStep does nothing for a whole block if there are
zero diagonal entries in the diagonal block.
One would expect that it solves the system for the reduced
block containing the block rows with nonzero diagonal entry
in this case.
* MultigridStep is not robust wrt setup order.
* MultigridStep deletes the ignoreNodes_ when calling preprocess() a second time
## Performance issues
While a suboptimal implementation might be OK, if it is cleaner
and more readable these issues may decrease the performance
without any again.
* BlockGSStep and the derived classes loop over each row twice.
Once for computing the residual, once for finding the diagonal entry.
This could be done in one loop.
* The ProjectedBlockGSStep 'solves' the local obstacle problems
by a local projected GS with a fixed number of 20 iteration steps
for blocksize!=1. Even in this case using only one step might still
be OK but much cheaper. (Does this have any performance impact on
linear elasticity problems?)
## Design issues
Things that could be improved to make dune-solvers easier to use, understand,
and maintain.
* Make all public member variables protected and introduce public methods for access.
* Use references instead of pointers as member function arguments.
* Make handling solution vector in IterationStep consistent:
Either provide a const reference, store a copy and give (reference)
access to this copy using getSol() or provide a (nonconst) reference,
store the solution there and make getSol() return this reference
and no copy.
(C: I'd prefer the latter to reduce the number of vector copies).
* Make setting up a MultigridStep easier. E.g. by providing a default
version that is preconfigured with GS smoother and coarse grid solver.
* MultigridStep works differently on the finest and the other
levels. On the finest, the smoother is used with the rhs of
the linear system and the current iterate as initial value
to compute the new iterate. On the coarse levels it is used to
solve the defect system approximately, i.e., it computes a
correction with the residual and zero initial value.
This should be unified or at least documented.
Computing corrections also on the finest level might allow
to solve systems really up to machine accuracy sice you
have more digits for the correction.
* devise a coherent meaningful concept of a SolverResult struct for the various
Solver Base-classes (Solver, IterativeSolver, LoopSolver atl) and substitute the
q&d version implemented now
## Naming of classes and members
* ignoreNodes_ should be called ignore_/ignoreIndices_/ignoreComponents_
## Missing features
A wish list for features that would be very welcome.
* Transfer operator assembler for adaptively refined grids (without refinementtype=copy)
This is already implemented in dune-fufem. It could be moved here if the
dependency on P1NodalBasis is removed.