dumux merge requests
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests
2024-03-19T12:59:08Z
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3766
[material][fluidmatrixinteraction] Fix doc to include Brooks Corey law.
2024-03-19T12:59:08Z
Ivan Buntic
[material][fluidmatrixinteraction] Fix doc to include Brooks Corey law.
<!--
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**:
Within the Brooks Corey law, we refered to the vanGenuchten law. The documentation was probably simply copied without changing the model name.
Before you request a review from someone, make sure to revise the following points:
- [ ] do the test pipelines pass? (see guide on [how to run pipelines for a merge request](https://git.iws.uni-stuttgart.de/dumux-repositories
<!--
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/3765
Merge branch 'fix/cmake-shared-libs' into 'master'
2024-03-26T14:16:06Z
Mathis Kelm
Merge branch 'fix/cmake-shared-libs' into 'master'
<!--
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**:
Backport !3710 into `releases/3.7`
<!--
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)
-->
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3764
[example][1d3d][cleanup] Remove debug in bloodflow helper
2024-03-06T11:22:33Z
Timo Koch
timokoch@math.uio.no
[example][1d3d][cleanup] Remove debug in bloodflow helper
The bloodflow helper doesn't appear explicitly in the documentation and therefore the docs need not be updated.
The bloodflow helper doesn't appear explicitly in the documentation and therefore the docs need not be updated.
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/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/3762
Generalize Slip Condition
2024-03-03T11:27:39Z
Martin Schneider
Generalize Slip Condition
<!--
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**:
- All slip condition related functions should not be in base problem but instead implemented on level of test problem
- One should be able to switch slip conditions. Currently BJ was always assumed.
<!--
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**
This is a first draft. There are still some things we should discuss.
TODOs:
- [ ] Can we unify the slip velocity interface? The issue with fcstaggered currently is the fact that the user can pass `tangentialVelocityGradient` which allows to overwrite derivatives
- [x] Is the current BJ implementation even correct in 3D? I would have expected that it is not enough to only consider one single tangential direction
- [x] Also introduce BJS
3.9
Martin Schneider
Martin Schneider
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/3760
[md][boundary][ffpnm] rename params cellsPerThroat and fixedCellsBetweenThroa...
2024-03-27T13:50:17Z
Anna Mareike Kostelecky
[md][boundary][ffpnm] rename params cellsPerThroat and fixedCellsBetweenThroats to ...Pore(s)
<!--
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 fixes #1351
<!--
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)
-->
Anna Mareike Kostelecky
Anna Mareike Kostelecky
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3757
Explain command line option in getting-started.md
2024-03-18T22:54:32Z
Stefan Meggendorfer
Explain command line option in getting-started.md
--module is used to (re)configure all module depencies
--module is used to (re)configure all module depencies
3.9
Stefan Meggendorfer
Stefan Meggendorfer
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3756
Fix dune grid communication
2024-02-07T21:11:29Z
Timo Koch
timokoch@math.uio.no
Fix dune grid communication
CollectiveCommunication was deprecated in dune 2.9 and is now removed.
CollectiveCommunication was deprecated in dune 2.9 and is now removed.
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
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/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/3753
[facet][cm] add missing const specifier
2024-03-02T17:14:10Z
Dennis Gläser
[facet][cm] add missing const specifier
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
This function can be `const`, but it wasn't marked as such so far. We never noticed because we seem ...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
This function can be `const`, but it wasn't marked as such so far. We never noticed because we seem to always pass `shared_ptr` to non-const coupling managers to the subproblems.
3.9
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3751
Make setRelativeHumidity a proper FluidState method
2024-02-27T16:48:54Z
Lars Kaiser
Make setRelativeHumidity a proper FluidState method
<!--
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 issue #1339
<!--
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**
Can be split into two merge requests, one fixing the setter method and one making the H2OAir FluidSystem compatible with the method.
<!--
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)
-->
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3749
[examples] correct typo in documentation
2024-01-11T17:33:53Z
Kai Wendel
[examples] correct typo in documentation
just correcting a very small typo in the examples.
just correcting a very small typo in the examples.
3.9
Kai Wendel
Kai Wendel
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3748
Cleanup/box facet dof enrichment
2023-12-28T13:13:08Z
Dennis Gläser
Cleanup/box facet dof enrichment
**What this MR does / why does DuMux need it**:
The box-facet-coupling model requires duplication of dofs in the bulk domain at faces coinciding with fractures in order to capture potential jumps in the solution across the fractures. At...
**What this MR does / why does DuMux need it**:
The box-facet-coupling model requires duplication of dofs in the bulk domain at faces coinciding with fractures in order to capture potential jumps in the solution across the fractures. At fracture tips ending inside the bulk domain, or on fractures that coincide with the bulk domain boundary, no duplication occurs. However, at fractures tips located at the bulk domain boundary, duplication does occur.
One case that wasn't handled properly yet is what's shown in the pictures in the comments below. This MR fixes that.
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.
3.9
Dennis Gläser
Dennis Gläser
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/3745
Add new dumux messages.
2023-12-15T15:57:44Z
Ivan Buntic
Add new dumux messages.
<!--
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 add more dumux messages which can be displayed in the beginning and the end of a simulation.
See #1331
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)
3.9
Ivan Buntic
Ivan Buntic
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/3743
Feature/regroup input params
2023-12-14T13:52:40Z
Yue Wang
yue.wang@iws.uni-stuttgart.de
Feature/regroup input params
<!--
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**:
See #1315
<!--
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:
- [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)
-->
Yue Wang
yue.wang@iws.uni-stuttgart.de
Yue Wang
yue.wang@iws.uni-stuttgart.de
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3742
[porousmediumflow][2pncmin][nonisothermal] Use current permeability for Neuma...
2024-01-10T08:34:04Z
Anna Mareike Kostelecky
[porousmediumflow][2pncmin][nonisothermal] Use current permeability for Neumann gas flux
<!--
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 fixes #1325
<!--
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.
-->
<!--
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] reference files for test need to be updated once !3740 is merged
- [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 #1325
Anna Mareike Kostelecky
Anna Mareike Kostelecky