dumux merge requests
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests
2023-12-13T10:52:17Z
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2112
WIP: Cleanup/assembly properties
2023-12-13T10:52:17Z
Timo Koch
timokoch@math.uio.no
WIP: Cleanup/assembly properties
* [ ] test everything
* [ ] update changelog for `ElementBoundaryTypes` in `LocalResidual`
* [ ] think about `NumEqVector`
* [ ] test everything
* [ ] update changelog for `ElementBoundaryTypes` in `LocalResidual`
* [ ] think about `NumEqVector`
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1510
Feature/multidomain auto bind
2023-12-13T10:52:17Z
Dennis Gläser
Feature/multidomain auto bind
I posed this MR into the box-facet-coupling branch so that the diff is easier to read. If we wait for !1492, which itself has to wait for !1431, then we can merge this into master at one point.
@timok, @kweis, maybe you can have a look ...
I posed this MR into the box-facet-coupling branch so that the diff is easier to read. If we wait for !1492, which itself has to wait for !1431, then we can merge this into master at one point.
@timok, @kweis, maybe you can have a look at this. If we want to keep this, we would have to:
- [x] deprecate old interfaces
- [x] change all tests where cm now receives grid variables
- [x] ~~create an issue to remove the deprecated interfaces in all __facet coupling managers__ and the __poroelasticcouplingmanager__ until version 3.2 release~~ (edit Timo: don't need an issue for that)
- [x] update reference to `test_md_facet_tracer_box` (velocity is included now, which tests the MD vel output)
- [x] Put a note in the changelog that scvfs now have to implement `neighbor()`
Fixes #619.
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2126
[WIP] Feature/ff stokes reverse coupling
2023-12-13T10:52:17Z
Kilian Weishaupt
[WIP] Feature/ff stokes reverse coupling
__TODO__
- [x] make backwards compatible
- [ ] fix failing tests
- [ ] implement for compositional, compressible flow
depends on !2128 !2133
__TODO__
- [x] make backwards compatible
- [ ] fix failing tests
- [ ] implement for compositional, compressible flow
depends on !2128 !2133
Kilian Weishaupt
Kilian Weishaupt
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2448
WIP Feature/new assembly multidomain
2023-12-13T10:52:17Z
Dennis Gläser
WIP Feature/new assembly multidomain
Disclaimer: this is very drafty and does not work yet. No need to review. For now this MR is only here in order to have a place to discuss about this.
Depends also on !2469, in order to harmonize cc/box scvfs and fix vtk output for box-...
Disclaimer: this is very drafty and does not work yet. No need to review. For now this MR is only here in order to have a place to discuss about this.
Depends also on !2469, in order to harmonize cc/box scvfs and fix vtk output for box-facet-coupling models.
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2244
Feature/update box couplingdata
2023-12-13T10:52:17Z
Martin Schneider
Feature/update box couplingdata
Update the box coupling such that it works for general non-matching grids.
This is done by introducing general projections onto the stokes faces.
Update the box coupling such that it works for general non-matching grids.
This is done by introducing general projections onto the stokes faces.
Martin Schneider
Martin Schneider
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2130
WIP Feature/finite element method
2023-12-13T10:52:17Z
Dennis Gläser
WIP Feature/finite element method
This is a first draft of an FEM framework. Currently, major limitations/assumptions are:
* assumes Standard-Galerkin approach
* assumes non-composite dune function space bases
I have tried to incorporate suggestions stemming from the d...
This is a first draft of an FEM framework. Currently, major limitations/assumptions are:
* assumes Standard-Galerkin approach
* assumes non-composite dune function space bases
I have tried to incorporate suggestions stemming from the discussion in #884, in particular it is:
1. The state of the grid variables was always dependent on the problem (e.g. due to BCs) and a current solution. Nevertheless, we had grid variables and problem and cursol as arguments in several assembly-related functions. In particular, we did `assembler.assemble(curSol)`. The assembler introduced here fulfills this interface (for compatibility with NewtonSolver), but does not use curSol. Instead, the assembler is instantiated with grid variables, which are updated with a solution and a problem. Thus, the assembler takes the solution and problem from the grid variables. So, you would want to do `Assembler assembler(gridVariables); assembler.assemble()`. This could help implementing other time stepping schemes, where you create grid variables on different time levels (stages), make an assembler from them and let it assemble the stage. The assembler is basically a copy of `FVAssembler`, which was almost general and non fv-specific. There is one piece of commented code related to parallelism with box (with a todo in the comment) which has to be figured out still.
2. Local assemblers are now a `localView` of the assembler, no which you then call `bind` with only an element. The problem & current solution are extracted from the grid variables with which the assembler was instantiated. This guarantees that a wrong combination of _problem state_, _solution state_ and _grid variables state_ is passed to it.
3. None of the classes use the property system anymore. I wrote a little test solving a poisson equation, which completely works without the property system. See test/discretization/fem/poisson. Therein, a problem and local residual have to be implemented. Currently, I implemented it in a "Dumux conforming" way, also implementing a spatial parameters class that stores the tensor and an "IntegrationPointVariables" class (the equivalent of vol vars in fv schemes), which hold the tensor at an integration point. The test implementation could be simplified very much if the custom local residual simply called `problem.getTensor()` or so - that would get rid of the spatial params and the integration point variables implementations. I did it this way for now to illustrate the complete workflow for implementing a new model and test.
All of this is subject to discussion, and all new headers have "TODOs" all over the place which can be discussed.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2276
WIP: [test][1p] Add 3d convergence test
2023-12-13T10:52:17Z
Timo Koch
timokoch@math.uio.no
WIP: [test][1p] Add 3d convergence test
Adds a 2d test on a sphere tet grid (`sphere.msh`). I also committed a `sphere_quad.msh` grid which has some nasty distorted quad elements.
Unfortunately I currently get for both grids:
```
Dune::InvalidStateException [decompose:/Users...
Adds a 2d test on a sphere tet grid (`sphere.msh`). I also committed a `sphere_quad.msh` grid which has some nasty distorted quad elements.
Unfortunately I currently get for both grids:
```
Dune::InvalidStateException [decompose:/Users/pumbaa/dune-master/dumux/dumux/discretization/cellcentered/wmpfa/facedatahandle.hh:101]: CoNormal decomposition not found
```
although the tet version of the grid looks fairly nice.
I wanted to use this test to check if it works in 3D.
For now it's only Dirichlet but it should be relatively easy to try Neumann boundaries.
Martin Schneider
Martin Schneider
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2272
WIP Feature/multidomain analytic jac rebase
2023-12-13T10:52:17Z
Timo Koch
timokoch@math.uio.no
WIP Feature/multidomain analytic jac rebase
do not merge. rebase of !1703. Should be force pushed to !1703 if it's working again.
Something went wrong in the rebase so the test fails.
do not merge. rebase of !1703. Should be force pushed to !1703 if it's working again.
Something went wrong in the rebase so the test fails.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2162
[WIP] Feature/restructure ff fluxvars
2023-12-13T10:52:17Z
Kilian Weishaupt
[WIP] Feature/restructure ff fluxvars
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/484
[WIP] Feature/ilupack
2023-12-13T10:52:17Z
Kilian Weishaupt
[WIP] Feature/ilupack
* [ ] Update to Dumux 3 (Parameters, Properties, get rid of TypeTag)
* [ ] Update to Dumux 3 (Parameters, Properties, get rid of TypeTag)
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1655
[WIP] Add first draft of Boussinesq comparison
2023-12-13T10:52:16Z
Kilian Weishaupt
[WIP] Add first draft of Boussinesq comparison
DO NOT MERGE YET
DO NOT MERGE YET
Kilian Weishaupt
Kilian Weishaupt
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1485
[WIP] Feature/stokesdarcy anisotropy DO NOT MERGE
2023-12-13T10:52:16Z
Kilian Weishaupt
[WIP] Feature/stokesdarcy anisotropy DO NOT MERGE
__DO NOT MERGE__
__DO NOT MERGE__
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/741
WIP: [2p2c] minimize private alias declarations and static variables
2023-12-13T09:19:30Z
Bernd Flemisch
WIP: [2p2c] minimize private alias declarations and static variables
On the example of two files/classes.
On the example of two files/classes.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3709
Fix type in changelog
2023-11-07T12:22:13Z
Martin Utz
Fix type in changelog
Martin Utz
Martin Utz
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3703
[cmake] Require CMake 3.16 or newer
2023-11-01T19:51:40Z
Christoph Grüninger
[cmake] Require CMake 3.16 or newer
This is related to [dune-common!1302](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1302) which is related to a decision from the Dune developer meeting 2022, see https://dune-project.org/community/meetings/2022-02-de...
This is related to [dune-common!1302](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1302) which is related to a decision from the Dune developer meeting 2022, see https://dune-project.org/community/meetings/2022-02-devmeeting/#minimum-versions-of-gcc-clang-cmake-python
Not sure whether this is for DuMuX 3.8 or 3.9.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3619
Draft: An example for two-phase flow properties using pore network
2023-10-30T09:29:04Z
Maziar Veyskarami
Draft: An example for two-phase flow properties using pore network
<!--
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**:
Since many people use pore network for upscaling purposes, there is a need to have a well-designed and documented example of how it can be done using the pore network in DUMUX. Although we already have an example for upscaling of a single-phase flow system, having another example for upscaling of a two-phase system to obtain capillary-saturation and relative permeability-saturation curves is desirable.
Fixes #1258
**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)
-->
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3645
WIP: [doxygen] Add doc for grid geometry.
2023-10-26T08:05:03Z
Ivan Buntic
WIP: [doxygen] Add doc for grid geometry.
<!--
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**:
This MR adds a first try for a documentation on the `gridgeometry`.
<!--
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**
Follow the instructions on https://dumux.org/docs/doxygen/master/building-the-documentation.html to build the documentation locally. The added description can be found under "Module documentation -> Discretization schemes".
<!--
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))
<!--
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
Ivan Buntic
Ivan Buntic
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3657
[ci][doxygen] verify log file exists
2023-10-17T14:36:15Z
Dennis Gläser
[ci][doxygen] verify log file exists
<!--
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**:
TODO: insert text here
<!--
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
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3646
Draft: [freeflow compositional][preconditioner] try to implemeny a preconditi...
2023-09-28T16:27:12Z
Kai Wendel
Draft: [freeflow compositional][preconditioner] try to implemeny a preconditioner for...
This branch should lead to a preconditioner for a `navierstokesnc` staggered model with veclocity and density weakly coupled.
This branch should lead to a preconditioner for a `navierstokesnc` staggered model with veclocity and density weakly coupled.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3623
[doxygen][highleveldoc] Updates the grid manager documentation
2023-08-03T13:44:54Z
Ivan Buntic
[doxygen][highleveldoc] Updates the grid manager documentation
<!--
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)
-->
Updates the high level documentation of the grid manager.
<!--
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.
-->
Belongs to issue #1154.
3.8
Ivan Buntic
Ivan Buntic