dumux merge requests
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests
2023-09-27T16:02:55Z
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
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3754
Draft: cleanup/smallCleanups
2024-02-09T07:57:39Z
Kai Wendel
Draft: cleanup/smallCleanups
As mentioned in [1346](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1346) several things should be improved in the documentation.
In this branch, a large part is concerned with fixing spelling mistakes. Besides this...
As mentioned in [1346](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1346) several things should be improved in the documentation.
In this branch, a large part is concerned with fixing spelling mistakes. Besides this, some obviously useless code parts were removed.
Some _TODO_-comments were removed, as it seems like that the task referred to is done, but I was not sure about it.
Also in one test (channel flow) an additional comment was added, which could be useful (see commit [05b5753a](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/commit/05b5753af0f1aa4bfd289278d33af45d1f72ee96)
This merge request is also declared as **draft** as I would expect several commits could cause some discussions, as the proposed changes may bring some unexpected implications.
Note also, that the changes are nearly all limited to the `freeflow` part of DuMux.
Kai Wendel
Kai Wendel
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3097
Draft: Feature/test templated typetags
2023-01-11T18:41:51Z
Timo Koch
timokoch@math.uio.no
Draft: Feature/test templated typetags
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3081
Draft: Fix/parallel adaptive
2023-02-22T09:09:54Z
Timo Koch
timokoch@math.uio.no
Draft: Fix/parallel adaptive
Related to #264
Related to #264
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2767
fix conservation of 2p tracer
2022-03-28T09:30:24Z
Bernd Flemisch
fix conservation of 2p tracer
Add a function `equilibrateTracer` which is called after each
update of the flow solution. It adapts the tracer mole fraction
according to the change in phase distribution such that the amount
of tracer in each element is conserved.
Fix...
Add a function `equilibrateTracer` which is called after each
update of the flow solution. It adapts the tracer mole fraction
according to the change in phase distribution such that the amount
of tracer in each element is conserved.
Fixes #1071.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3763
Draft: Feature/enthalpy refactoring
2024-03-27T15:56:56Z
Yue Wang
yue.wang@iws.uni-stuttgart.de
Draft: Feature/enthalpy refactoring
<!--
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 is a first draft for refactoring the enthalpy computation. We would like to use a common database (NIST) for all of our components if possible (for most there is data in NIST). The only "problem" is that the provided temperature ranges as in [this table](https://webbook.nist.gov/cgi/cbook.cgi?ID=C74828&Mask=1&Type=JANAFG&Table=on#JANAFG) can be constraining as they only start from `T=298K` for certain components. People probably would also like to use lower temperatures. Therefore, we compared the plots for the enthalpy difference compared to the the state of T=298K for three approaches. 1) Shomate equation for enthalpy, as suggested by NIST, 2) integrated shomate equation for heat capacity, which should also result in enthalpy, 3) take [discrete value for heat capacity](https://webbook.nist.gov/cgi/cbook.cgi?ID=C74828&Mask=1#Thermo-Gas) and integrate those, these should probably be the reference values, although the discrete values are quite sparse.
![heatEnt](/uploads/df29962056164face9da5635c26bb55e/heatEnt.png)
As can be seen, method 1) and 2) match very well as expected. But what can also be seen: for temperature lower than 298K, these lines also match quite well with the integrated experimental values for the heat capacity. As for lower temperatures all methods align well, in the current implementation we also allow temperatures lower than 298K but print a warning once, that we are operating on extrapolated values, if that is the case. We would like to extend this approach to all components to have a unified interface for the enthalpy.
In the lower graph we compared the values for the computed enthalpies in Dumux with the values provided by the Shomate equations.
![enthalpyComp](/uploads/c5bfa117cd4b638968a275b15d2a1890/enthalpyComp.png)
The dashed line represents the current values in Dumux (orange, dashed line), however they do not use the reference temperature of 298K, which we would like to unify. If we correct the Dumux values to the desired reference temperature we obtain the red line which matches very well with the values provided by the Shomate equation. For methane, the relative RMSE (compared to the corrected Dumux values) is around 0.08%.
Still need to add reference links to the NIST database for each components as a comment.
Connected to #1255
<!--
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))
- [ ] 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.
- [ ] (if not applicable remove) are newly introduced or modified physical values/functions backed up with a scientific reference (including doi) in the docs?
<!--
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
Ivan Buntic
Ivan Buntic
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3761
Resolve "[test][porousmediumflow][2pncmin][nonisothermal] Neumann flux at top...
2024-03-27T15:04:31Z
Anna Mareike Kostelecky
Resolve "[test][porousmediumflow][2pncmin][nonisothermal] Neumann flux at top has to be adapted"
<!--
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**:
Fixes #1356
<!--
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**
<!--
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)?
- [x] 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.
<!--
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)
-->
Closes #1356
Anna Mareike Kostelecky
Anna Mareike Kostelecky
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3758
[test][navierstokes] add iterative stokes solver to channel test
2024-02-09T15:05:12Z
Mathis Kelm
[test][navierstokes] add iterative stokes solver to channel test
<!--
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**:
Adresses #1345. Adds an implementation of `dirichletDofs` helper for the fcstaggered discretization in the 2D-Channel test.
- [ ] Consider moving helper functions to header, taking information from the Assembler
<!--
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.
<!--
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
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3755
Draft: Feature/hldd
2024-03-27T20:53:08Z
Leon Keim
Draft: Feature/hldd
<!--
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**:
Our software needs a high-level design document because it's like a blueprint that helps everyone on the team get on the same page about how DuMux thing is put together and works.
Corresponds to #1154
<!--
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**
<!--
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.9
Leon Keim
Leon Keim
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3747
Draft: parallelize the Uzawa preconditioned solver
2024-01-05T11:37:02Z
Bernd Flemisch
Draft: parallelize the Uzawa preconditioned solver
3.9
Bernd Flemisch
Bernd Flemisch
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3744
Draft: Remove scv/scvf corners
2024-03-26T15:22:21Z
Mathis Kelm
Draft: Remove scv/scvf corners
<!--
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**:
Related to #1173.
The box specializations for `multidomain/facet` and `porousmediumflow/boxfdm` still had corners stored on the scv(f)s.
The `boxfdm/subcontrolvolume.hh` exposed `corners_[0]` as `dofPosition()` and still stores this corner as `dofPosition_`. While the corners can be obtained from the geometryHelper, for scv containing a fracture the corners are constructed using two indices not (obviously) stored in the scv. Are these indices readily available? Is storing the indices and constructing all corners better than storing dofPosition?
Removes deprecations after release 3.8: Fixes #1327.
<!--
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.
<!--
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
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3741
Draft: Ci/gitlab triage
2023-12-13T11:49:15Z
Leon Keim
Draft: Ci/gitlab triage
<!--
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)
-->
Lars Kaiser
Lars Kaiser