dune-tnnmg merge requestshttps://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/merge_requests2023-10-06T10:30:32Zhttps://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/merge_requests/34Draft: Introduce the IntegralFunctional class and its linearization2023-10-06T10:30:32Zoliver.sander_at_tu-dresden.deoliver.sander@tu-dresden.deDraft: Introduce the IntegralFunctional class and its linearizationThis class currently resides in the `dune-fracture-phasefields` module, but there is nothing fracture-specific about it.
However, there are a few details that I would like to get opinions on:
* Is `functionals` the best subdirectory?
*...This class currently resides in the `dune-fracture-phasefields` module, but there is nothing fracture-specific about it.
However, there are a few details that I would like to get opinions on:
* Is `functionals` the best subdirectory?
* Is the new code in `functionalstest.hh` appropriate, or should it go into a separate file?
Most importantly:
* The MR contains the `ElementQuantityAssembler` class, which uses the `dune-fufem` assemblers. But `dune-fufem` is not a dependency of `dune-tnnmg`. Where should this code go?
* I am still not happy with the name `ElementQuantityAssembler`. Can we come up with anything better?
Finally, the MR needs a changelog entry.https://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/merge_requests/25WIP: Semilinear functional2021-05-07T10:53:35Zlh1887WIP: Semilinear functionalThis MR implements a semilinear functional of the form
```math
J(u) = \sum_i \omega_i \varphi(u_i)
```
where the index i corresponds to the *scalar* entries (but the vectors should be able to be arbitrarily blocked).
The function phi nee...This MR implements a semilinear functional of the form
```math
J(u) = \sum_i \omega_i \varphi(u_i)
```
where the index i corresponds to the *scalar* entries (but the vectors should be able to be arbitrarily blocked).
The function phi needs to be supplied by the user and has to comply to a (not yet fixed) reasonable interface.
This functional explicitly does not carry any quadratic part of the functionals many of us would consider. The idea is to integrate this part via using `SumFunctional` and (e.g.) `QuadraticFunctional` as needed.
This is still work in progress, there are several things remaining, among them:
- tests
- examples (say e.g. Allen-Cahn with different potentials)
- documentation
- clean up (names, files, ...)
- many things can be done more efficiently
- bug fixinghttps://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/merge_requests/22Feature/avoid nonlinearity2020-10-19T16:09:35ZgraeserFeature/avoid nonlinearityAvoid using old `Nonlinearity` and `ConvexProblem` and corresponding headers.Avoid using old `Nonlinearity` and `ConvexProblem` and corresponding headers.https://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/merge_requests/17Convert truncateVector/-Matrix into free functions2020-07-07T15:25:31Zlh1887Convert truncateVector/-Matrix into free functionsThis way, they can more easily be used in other contexts.This way, they can more easily be used in other contexts.https://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/merge_requests/16Use autoCopy when copying vector blocks2020-09-08T14:21:21Zlh1887Use autoCopy when copying vector blocksThis way, types that implement `AutonomousValue` can specify into what
type they are copied. This can be applied e.g. for proxy types such as
the `BlockVectorWindow` used in ISTL's `VariableBlockVector`.
For types that do not implement ...This way, types that implement `AutonomousValue` can specify into what
type they are copied. This can be applied e.g. for proxy types such as
the `BlockVectorWindow` used in ISTL's `VariableBlockVector`.
For types that do not implement `AutonomousValue`, the behavior should
not change.graesergraeserhttps://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/merge_requests/4WIP: Smooth potential2017-07-21T13:41:51Zlh1887WIP: Smooth potentialThis is for minimizing problems with the typical TNNMG structure, i.e.
> J(v) = 0.5 \<Av,v> - \<b,v> + \sum_i phi(v_i)
but with phi being a smooth function at this point. Basically, you should end up with a preconditioned and damped New...This is for minimizing problems with the typical TNNMG structure, i.e.
> J(v) = 0.5 \<Av,v> - \<b,v> + \sum_i phi(v_i)
but with phi being a smooth function at this point. Basically, you should end up with a preconditioned and damped Newton step.
This implementation has still some issues, which are (at least):
* [ ] Having so many template parameters (`PHI`, `PHIPRIME`, `PHI2PRIME`) is ugly. Maybe one wants something like `std::function`s instead,
* [ ] much of the code is based on non-smooth implementations, hence there are still some artefacts that are not really needed for the smooth case,
* [ ] the bisection local solver doesn't let you control all parameters the bisection offers,
* [ ] near the solution, the solver shows some oscillating behaviour, this is most likely a bug (to see this, set the tolerance in the LoopSolver to a smaller number),
* [ ] some *TODO* s which are marked as such in the code,
* [ ] and, finally, the whole code needs more documentation.
I'd be glad to get any kind of remarks, bugfixes, clean-ups etc.