dumux merge requests
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests
2024-02-11T14:19:39Z
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3752
Feature/gridformat writer
2024-02-11T14:19:39Z
Dennis Gläser
Feature/gridformat writer
<!--
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**:
Adds [gridformat](https://github.com/dglaeser/gridformat) as git submodule and a wrapper around its generic readers/writers in order to provide I/O from/to various grid file formats.
TODO:
- [x] Discuss class and file names. The current choice was made s.t. the include is `#include <dumux/io/gridwriter.hh>`, since it's generic over the formats...
- [x] Support discontinuous output. Could be achieved by adding a separate template argument and perform a similar mechanism as currently done for the lagrange wrapper (i.e. add one more wrapper layer around the stored grid...). EDIT: will be done in a separate MR.
- [x] Add support for vol-var output as in `VTKOutputModule`. I suggest to derive from this writer and expose an additional `setVolVarField` function, because for vol var output we need more things (e.g. `GridVariables`, `X`, etc...). By adding it as additional derived class we can keep simple output "simpler". EDIT: will be done in a separate MR.
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.9
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3631
Draft: [localresidual] Make CRTP explicit, remove BaseLocalResidual, reduce L...
2023-09-27T16:02:55Z
Timo Koch
timokoch@math.uio.no
Draft: [localresidual] Make CRTP explicit, remove BaseLocalResidual, reduce LocalResidual property usage
* Add `Implementation` template arg to `FVLocalResidual` and the more disc-scheme-specific child classes (which forward it to `FVLocalResidual`)
* `FVAssembler` receives `LocalResidual` as template arg as well, default comes from propert...
* Add `Implementation` template arg to `FVLocalResidual` and the more disc-scheme-specific child classes (which forward it to `FVLocalResidual`)
* `FVAssembler` receives `LocalResidual` as template arg as well, default comes from property system.
* `BaseLocalResidual` property is removed and substituted by selector trait `DiscretizationDefaultLocalOperator`
* The property `LocalResidual` persists in order to keep the `FVAssembler` bw-compatible
TODO
* [x] Add changelog entry
* [x] Add an example that passes the local residual in the main file
* [x] Fix NavierStokesLocalResidualImpl
* [x] Fix multidomain
* [ ] This does not work with FacetCoupling, because it uses a custom `BaseLocalResidual` which is injected via the property system.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3626
Volume Averaging Methods
2024-01-31T12:36:04Z
Ned Coltman
Volume Averaging Methods
<!--
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**:
Adds a few methods for averaging solutions across different grids.
<!--
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**
There are a few existing MRs that could possibly use this as well? !3160 !3187
Also, for the convolutional averaging, the filter implemented is currently only a uniform filter. A gaussian filter could also be cool?
<!--
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:
- [x] 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))
- [x] 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`.
- [x] is the list of the header includes complete? ("include what you use")
- [x] 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.
<!--
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)
-->
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3564
WIP: [tpfa] Add possiblity for custom boundary function
2024-02-23T22:09:13Z
Timo Koch
timokoch@math.uio.no
WIP: [tpfa] Add possiblity for custom boundary function
I needed to mark certain intersections as boundaries although they are not boundaries in the grid (i.e. have a neighbor). This can be for example a touching point/edge for networks that should be marked as a boundary. One possibility is ...
I needed to mark certain intersections as boundaries although they are not boundaries in the grid (i.e. have a neighbor). This can be for example a touching point/edge for networks that should be marked as a boundary. One possibility is to modify the grid to double the vertex/edge. Another possibility is implemented in this MR and is providing a function that determined which intersections are boundaries.
Rough implementation, can be improved. For example, I don't think the function actually has to be stored. It's enough to pass it to update I think.
* [ ] Remove debug output
* [ ] pass function to update
3.9
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3256
Draft: [pq1bubble] Add Navier-Stokes model parallel
2023-09-27T16:15:35Z
Timo Koch
timokoch@math.uio.no
Draft: [pq1bubble] Add Navier-Stokes model parallel
3.9
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3173
WIP: encapsulate operations in the volvars update method
2023-09-27T16:15:46Z
Ned Coltman
WIP: encapsulate operations in the volvars update method
<!--
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**:
This merge request should remo...
<!--
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**:
This merge request should remove duplicated code often seen in the volvars' update functions. This issue is outlined in #814.
<!--
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**
@tufan, @nedc, @hanchuan, @yue
**Question: **
does it make sense to add new headers to the dumux/material/constraintsolvers/ directory, or would another location make more sense?
<!--
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))
- [x] 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")
- [x] 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.
<!--
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.9
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3160
Draft: Feature/perm upscaling
2024-01-31T10:44:59Z
Timo Koch
timokoch@math.uio.no
Draft: Feature/perm upscaling
<!--
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**:
* Adds a small permeability up...
<!--
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**:
* Adds a small permeability upscaling test on a domain with a cutout sphere
* Should also be a test for Stokes domains with convex corners (see #1167)
<!--
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))
- [x] 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)
- [x] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [x] is the list of the header includes complete? ("include what you use")
- [x] 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.
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2563
[components] Add component LinearizedH2O
2023-09-27T16:15:58Z
Timo Koch
timokoch@math.uio.no
[components] Add component LinearizedH2O
Fixes #1013
I hope this is consistent. Water vapor is modeled as an ideal gas. inner energy and vapor pressure are linearized around the reference state. The evaporation enthalpy should be automatically included now.
I added a new com...
Fixes #1013
I hope this is consistent. Water vapor is modeled as an ideal gas. inner energy and vapor pressure are linearized around the reference state. The evaporation enthalpy should be automatically included now.
I added a new component as this implementation will probably yield different results than SimpleH2O.
3.9
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2253
[WIP] Feature/nonlinear schemes
2023-07-20T13:17:36Z
Timo Koch
timokoch@math.uio.no
[WIP] Feature/nonlinear schemes
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1821
[WIP][md] Implement box staggered coupling
2023-07-25T08:58:33Z
Kilian Weishaupt
[WIP][md] Implement box staggered coupling
Todos:
- [x] Add test for segment-segment intersection algorithm
- [x] Make segment-segment intersection algorithm more efficient
- [x] Put segment-segment in different MR
- [x] Extract Box-Forchheimer to separate MR
- [x] New BJ test ...
Todos:
- [x] Add test for segment-segment intersection algorithm
- [x] Make segment-segment intersection algorithm more efficient
- [x] Put segment-segment in different MR
- [x] Extract Box-Forchheimer to separate MR
- [x] New BJ test (existing test uses indefinite perm. matrix)
- [x] Change convergence script to specify convergence rate
- [ ] It currently only works for `DiffusionCoefficientAveragingType::ffOnly`
- [ ] Maxwell Stefan Diffusion law not yet implemented when using Box
- [ ] Renaming: Use ff/pm instead of stokes/darcy
- [ ] New IC assume specific parameter group "Darcy", generalise this
- [ ] Add missing tests
Suggestions:
- [x] Currently, we retrieve the entire context via `couplingContextVector()`, but the old interface is still there. I would shrink this to only one interface and probably rename it. Currently, there is one context object per coupling segment, so maybe we can find a better name.
- [x] At the moment the coupling segment geometry is stored in both the darcy and the stokes coupling info objects in the mapper. I don't think this is the most memory consuming part of the code, but there is room for memory efficiency improvements.
Fixes #788.
Dennis Gläser
Dennis Gläser