dumux merge requests
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests
2023-07-14T14:42:34Z
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3607
[experimental] Implement cached residual variant in test
2023-07-14T14:42:34Z
Timo Koch
timokoch@math.uio.no
[experimental] Implement cached residual variant in test
Implement the timestepping test in a ways that the residuals of the last stage do not have to be recomputed.
This means we also don't have to store the variables of the last step.
Implement the timestepping test in a ways that the residuals of the last stage do not have to be recomputed.
This means we also don't have to store the variables of the last step.
3.8
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3569
Draft: Feature/ff pm coupling allow different discretizations
2023-07-26T14:25:19Z
Martin Schneider
Draft: Feature/ff pm coupling allow different discretizations
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
To be able to choose different discretization schemes for ff-pm coupling, we need to allow discretization-dependent specializations.
<!--
Is there a corresponding issue? Add "Fixes hashtag issuenumber" which will automatically close the issue when this MR is merged. Add "Related to hashtag issuenumber" if it's related but doesn't fix the issue completely.
-->
**Notes for the reviewer**
TODO: insert text here
<!--
Keep the following TODO list in the merge request description for documentation.
Bullet points marked with _(if not applicable remove)_ may be removed.
-->
Before you request a review from someone, make sure to revise the following points:
- [ ] does the new code follow the [style guide](doc/styleguide.md)?
- [ ] do the test pipelines pass? (see guide on [how to run pipelines for a merge request](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Running-test-pipelines-for-merge-requests))
- [ ] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)
- [ ] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [ ] is the list of the header includes complete? ("include what you use")
- [ ] all files have to end with a `\n` character. Make sure there is no `\ No newline at end of file` comment in "Changes" of this MR.
- [ ] (if not applicable remove) are newly introduced or modified physical values/functions backed up with a scientific reference (including doi) in the docs?
- [ ] (if not applicable remove) if the examples are modified, is the documentation regenerated (using [`generate_example_docs.py`](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/examples/generate_example_docs.py))
<!--
The following aspects might also come up during review:
* Does the change reduce the performance of the code (more CPU time or more memory) and is this justified by the benefits
* Does the change improve the performance? (if yes, add this aspect to the MR description)
* Is the code is a gross violation of programming best practices such as DRY (don't repeat yourself / code duplication, see https://de.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself, the SOLID principles (https://en.wikipedia.org/wiki/SOLID), or the C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)?
* Is the code well-documented, concise, easily readable? (e.g. variables are well-named, the logic is split into small & well-named functions)
-->
3.8
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3283
[geometry] Add volume function with transformed integrationElement
2022-09-14T17:00:56Z
Timo Koch
timokoch@math.uio.no
[geometry] Add volume function with transformed integrationElement
3.6
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3255
[ff][cvfe] Implement velocity output for cvfe scheme
2022-08-13T18:33:21Z
Timo Koch
timokoch@math.uio.no
[ff][cvfe] Implement velocity output for cvfe scheme
3.6
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3203
Draft: [box] Add cache to hide implementation interface from the grid geometr...
2022-09-05T17:37:26Z
Timo Koch
timokoch@math.uio.no
Draft: [box] Add cache to hide implementation interface from the grid geometry public interface
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3139
Feature/incompressible stokes solver
2023-02-24T22:42:35Z
Timo Koch
timokoch@math.uio.no
Feature/incompressible stokes solver
3.7
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3011
Surfactant test
2022-02-23T22:19:46Z
Dmitry Pavlov
Surfactant test
Test of surfactant injection in porous medium (2p2c). Surfactant model is loosely based on the one described [here](https://www.sintef.no/contentassets/0d97862cef164d1c965d268ce5e4e082/surfactant_model.pdf). (Also see [here](https://ntnu...
Test of surfactant injection in porous medium (2p2c). Surfactant model is loosely based on the one described [here](https://www.sintef.no/contentassets/0d97862cef164d1c965d268ce5e4e082/surfactant_model.pdf). (Also see [here](https://ntnuopen.ntnu.no/ntnu-xmlui/handle/11250/240038) for a longer version). This test will not work without [MR 2914](!2914).
3.5
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2794
Draft: Resolve "Discretization method as tag instead of enum"
2021-08-25T12:49:26Z
Ivan Buntic
Draft: Resolve "Discretization method as tag instead of enum"
Closes #1054
Closes #1054
3.5
Ivan Buntic
Ivan Buntic
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2734
Draft: Resolve "extrusionFactor should be a spatial parameter interface"
2022-02-22T15:00:08Z
Felix Weinhardt
Draft: Resolve "extrusionFactor should be a spatial parameter interface"
Closes #1001
Closes #1001
3.5
Felix Weinhardt
Felix Weinhardt
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2733
Draft: Resolve "extrusionFactor should be a spatial parameter interface"
2021-07-28T10:17:47Z
Felix Weinhardt
Draft: Resolve "extrusionFactor should be a spatial parameter interface"
Closes #1001
Closes #1001
3.5
Felix Weinhardt
Felix Weinhardt
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2685
Port Darcy-Stokes convergence test
2021-09-09T14:21:16Z
Timo Koch
timokoch@math.uio.no
Port Darcy-Stokes convergence test
* Port convergence test to new staggered
* Add stress tensor for analytical solutions
* add tests for dirichlet, neumann and mixed dirichlet-neumann boundaries in both domains
* test all implemented analytical solutions
* Port convergence test to new staggered
* Add stress tensor for analytical solutions
* add tests for dirichlet, neumann and mixed dirichlet-neumann boundaries in both domains
* test all implemented analytical solutions
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2640
WIP: [assembler] Add parallel assembly with tbb and coloring
2022-04-20T19:05:16Z
Timo Koch
timokoch@math.uio.no
WIP: [assembler] Add parallel assembly with tbb and coloring
* [x] Look at other discretization schemes (or at least disable feature for non-tpfa, non-box)
* [x] Add guards in case TBB is not available.
* [ ] Guard for gridviews which are not thread-safe.
* [x] Check caching (due to coloring this ...
* [x] Look at other discretization schemes (or at least disable feature for non-tpfa, non-box)
* [x] Add guards in case TBB is not available.
* [ ] Guard for gridviews which are not thread-safe.
* [x] Check caching (due to coloring this should also work with caching)
* [x] Option to set number of available threads at runtime
Check efficiency of coloring scheme (efficiency doesn't matter much for instationary simulations).
The constraint behind the coloring should be: Two elements that modify the same entries of the matrix or the cache or any other global object shouldn't have the same color. In the graph coloring sense: Two elements (two nodes) that do modify the same entries are connected by an edge.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2398
[flux][tpfa][fickslaw] Add flux overload taking inside/outside volVars explic...
2020-12-14T00:07:50Z
Kilian Weishaupt
[flux][tpfa][fickslaw] Add flux overload taking inside/outside volVars explicitly
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2186
[newton] Extract privarswitch implementation to separate class
2020-06-19T17:57:39Z
Timo Koch
timokoch@math.uio.no
[newton] Extract privarswitch implementation to separate class
3.3
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2142
WIP: Feature/freeflow outflow as neumann
2022-09-01T07:09:15Z
Martin Schneider
WIP: Feature/freeflow outflow as neumann
Instead of outflow conditions we want to use Neumann conditions with convenience outflow functions provided in some fluxhelper class.
ToDos
- [x] Check turbulence models
- [ ] Check coupled models
- [ ] Deprecate outflow conditions
- [ ...
Instead of outflow conditions we want to use Neumann conditions with convenience outflow functions provided in some fluxhelper class.
ToDos
- [x] Check turbulence models
- [ ] Check coupled models
- [ ] Deprecate outflow conditions
- [ ] Fix failing tests
- [ ] Documentation of helper classes
3.7
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2137
WIP: [newton] Generalize Newton implementation for different solution types
2021-03-24T16:18:08Z
Timo Koch
timokoch@math.uio.no
WIP: [newton] Generalize Newton implementation for different solution types
* [x] Extract Privarswitch logic/implementation into separate class
* [ ] Extract partial reassembler logic into seperate class
* [ ] Provide external helpers for relative shift
* [x] Extract Privarswitch logic/implementation into separate class
* [ ] Extract partial reassembler logic into seperate class
* [ ] Provide external helpers for relative shift
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2120
WIP: Feature/add turbulent diffusion to shallow water model
2020-09-16T13:01:04Z
Frank Platzek
WIP: Feature/add turbulent diffusion to shallow water model
<!--
Thanks for sending a merge request!
If this is your first time, read our [contributing guidelines](/CONTRIBUTING.md)
-->
**Adding (turbulent) diffusion to the shallow water model (part of freeflow)**:
For now using constant eddy-...
<!--
Thanks for sending a merge request!
If this is your first time, read our [contributing guidelines](/CONTRIBUTING.md)
-->
**Adding (turbulent) diffusion to the shallow water model (part of freeflow)**:
For now using constant eddy-viscosity. Turbulence models will be added in separate issues. The implementation also contains 2 wall shear stress implementations:
1. no-slip implementation
2. law-of-the-wall implementation
One test has been added: Poiseuille flow test: for flow in a channel with rough side walls.
This test has an analytical solution.
**Which issue this MR fixes**:
#706
**Special notes for your reviewer**:
N/A
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2113
WIP: Feature/new istl linear solvers
2023-02-22T11:59:20Z
Timo Koch
timokoch@math.uio.no
WIP: Feature/new istl linear solvers
* [x] Revisit template arguments
* [x] Introduce linear algebra backend or similar to make usage simpler
* [x] Adapt all linear solvers to provide `norm`
* [x] In Newton call `linearSolver->norm(r)` if available otherwise call `assembler...
* [x] Revisit template arguments
* [x] Introduce linear algebra backend or similar to make usage simpler
* [x] Adapt all linear solvers to provide `norm`
* [x] In Newton call `linearSolver->norm(r)` if available otherwise call `assembler->residualNorm();` (depends on !2311 to be merged)
* [x] Deprecate conversion of multitype matrices in Newton (do in solver instead if necessary)
Depends on !2310 to be merged.
The matrix and vector type now have to be known to construct the solver.
This was previously delayed until the solve call but made the structure kind of intransparent because it wasn't really clear which vector type has to come in but only specific types work anyway.
Hard coding the solver hopefully reduces compile times wrt the factory. Also the implementation should be
* more compact than the old backends
* have more runtime option due to parameter tree-based params
* work in parallel as well
If this works out, we would deprecated the old solver backends.
3.7
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2046
[WIP] [common] Add function rows(multiTypeBlockMatrix)
2020-04-29T07:49:06Z
Kilian Weishaupt
[WIP] [common] Add function rows(multiTypeBlockMatrix)
fixes #872
fixes #872
3.3
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2012
[WIP] TEMP: first draft of new staggered fvgridgeometry
2023-02-19T23:24:45Z
Kilian Weishaupt
[WIP] TEMP: first draft of new staggered fvgridgeometry
This is a first prototype for a "real" staggered fvGeometry.
Results of discussion so far:
* staggered fvGeometry contains 4 (2D quad cells) scvs and 12 scvfs
This is a first prototype for a "real" staggered fvGeometry.
Results of discussion so far:
* staggered fvGeometry contains 4 (2D quad cells) scvs and 12 scvfs