dumux merge requests
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests
2022-10-06T09:47:47Z
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3314
Add documentation to Fourier non-equilibrium
2022-10-06T09:47:47Z
Stefanie Kiemle
Add documentation to Fourier non-equilibrium
<!--
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**:
Add documentation to Fourier's...
<!--
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**:
Add documentation to Fourier's nonequilibrium law
<!--
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**
#1149
<!--
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)
-->
Stefanie Kiemle
Stefanie Kiemle
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3426
Add dualnetwork test from dumux-pub repository Koch2021a
2023-05-22T06:19:57Z
Anna Mareike Kostelecky
Add dualnetwork test from dumux-pub repository Koch2021a
<!--
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 adds the possibility to s...
<!--
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 adds the possibility to study the heat transfer between one fluid phase and a solid phase with one porenetwork model for the void space coupled to one network model for the solid phase (dualnetwork)
In addition one test case is provided with reference solutions
<!--
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**
Files and test case, where taken from [https://git.iws.uni-stuttgart.de/dumux-pub/Koch2021a](https://git.iws.uni-stuttgart.de/dumux-pub/Koch2021a) and modified, such that it is runs on the current master
<!--
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.
- [x] (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.8
Anna Mareike Kostelecky
Anna Mareike Kostelecky
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1127
Added PNG/dalton1.png and PNG/dalton2.png to the list of files for building t...
2018-07-23T15:11:41Z
David Werner
Added PNG/dalton1.png and PNG/dalton2.png to the list of files for building the handbook.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2749
add enthalpy, internal energy, heat capacity and vapor pressure for constant ...
2022-02-24T12:13:46Z
Katharina Heck
add enthalpy, internal energy, heat capacity and vapor pressure for constant component
- [x] check if this changes any tests: I could not find a test with constant component and non-isothermal
- [x] check for consistency with other components: i will adapt simpleh2o accordingly. the napl components still calculate the gas ...
- [x] check if this changes any tests: I could not find a test with constant component and non-isothermal
- [x] check for consistency with other components: i will adapt simpleh2o accordingly. the napl components still calculate the gas enthalpy as liquid enthalpy + vaporization enthalpy but I am going to leave this as it is.
- [x] add test
fixes #1015
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/148
Add explicit std namespace specifier to std::isnan
2016-11-28T10:24:04Z
Timo Koch
timokoch@math.uio.no
Add explicit std namespace specifier to std::isnan
Without `std::` these erros out for me (clang-3.8 / ubuntu 16.04)
Without `std::` these erros out for me (clang-3.8 / ubuntu 16.04)
2.10
Christoph Grüninger
Christoph Grüninger
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/534
Add extended Richards model with water diffusion in gas phase and possible va...
2017-09-06T10:07:36Z
Timo Koch
timokoch@math.uio.no
Add extended Richards model with water diffusion in gas phase and possible variable switch
add extended Richards law with water diffusion in gas phase
depends on !528
* [x] Solve how to get diffusion of only one component in one phase
* [x] Fix fluxvars, see #391
add extended Richards law with water diffusion in gas phase
depends on !528
* [x] Solve how to get diffusion of only one component in one phase
* [x] Fix fluxvars, see #391
Katharina Heck
Katharina Heck
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3005
Add graph partitioning via Scotch
2022-04-18T11:53:26Z
Larissa Brencher
Add graph partitioning via Scotch
Task: Implement graph partitioning via PT-Scotch package and use the resulting partitioning for UG's load balancer
Fixes #812, fixes #1110
- [x] ~~parallelization (change graph to dgraph)~~ -> #1141
- [x] extract as header file
- [x] ...
Task: Implement graph partitioning via PT-Scotch package and use the resulting partitioning for UG's load balancer
Fixes #812, fixes #1110
- [x] ~~parallelization (change graph to dgraph)~~ -> #1141
- [x] extract as header file
- [x] write tests
3.5
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/46
Add guardians for wrong boundary types for the mass balance in the free flow ...
2016-01-19T09:10:44Z
Thomas Fetzer
Add guardians for wrong boundary types for the mass balance in the free flow domain.
Avoids undesired behavior in case a "not-defined" boundary type is set.
Avoids undesired behavior in case a "not-defined" boundary type is set.
Gabi Seitz
Gabi Seitz
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3002
Add helper header for geomechanics spatialparams
2022-01-27T14:31:50Z
Ivan Buntic
Add helper header for geomechanics spatialparams
Ivan Buntic
Ivan Buntic
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/705
Add ingroup TwoPOneCTests
2017-12-22T13:12:26Z
Sina Ackermann
Add ingroup TwoPOneCTests
Simon Emmert
Simon Emmert
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1516
Add labels to tests
2019-03-01T14:09:20Z
Theresa Schollenberger
Add labels to tests
The labels porousmediumflow and geomechanics are added to each test in the respective folders. In multidomain there are the labels boundary, darcydarcy, stokesdarcy, facet and embedded. Further each test has a label of the used model (e....
The labels porousmediumflow and geomechanics are added to each test in the respective folders. In multidomain there are the labels boundary, darcydarcy, stokesdarcy, facet and embedded. Further each test has a label of the used model (e.g. 1p, 1pnc, navierstokes, ...).
Closes issue #595
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3113
Add merge request default template
2022-05-31T17:30:56Z
Dennis Gläser
Add merge request default template
@timok, @heck, @bernd, following our thoughts on a seminar on what is important in merge requests, I thought it could be helpful to have a descriptive default merge request template appearing always when someone opens a merge request.
I...
@timok, @heck, @bernd, following our thoughts on a seminar on what is important in merge requests, I thought it could be helpful to have a descriptive default merge request template appearing always when someone opens a merge request.
I basically copied the text from our `merge_request.md` template but added a check list what should be considered before asking for a review. This should be extended in case we want to do this. I pushed this to ask for you opinion on this...
TODO:
- [x] if we want to keep this layout, we should probably delete the other merge request template file?
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3731
add missing #include config.h to source files
2023-11-30T21:20:06Z
Mathis Kelm
add missing #include config.h to source files
<!--
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 source files should include the `config.h` header.
<!--
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)
-->
3.9
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/616
Add missing include <functional>
2017-11-27T14:17:53Z
Bernd Flemisch
Add missing include <functional>
(cherry picked from commit 8713bc08c6cffd07df1a82b59009b0f664926cd8)
(cherry picked from commit 8713bc08c6cffd07df1a82b59009b0f664926cd8)
Bernd Flemisch
Bernd Flemisch
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/615
Add missing include <functional>
2017-11-27T14:09:42Z
Bernd Flemisch
Add missing include <functional>
(cherry picked from commit 8713bc08c6cffd07df1a82b59009b0f664926cd8)
(cherry picked from commit 8713bc08c6cffd07df1a82b59009b0f664926cd8)
Bernd Flemisch
Bernd Flemisch
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/325
Add missing include <functional>
2017-01-05T11:36:33Z
Christoph Grüninger
Add missing include <functional>
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3468
Add missing includes
2023-03-21T13:49:05Z
Hamza Oukili
Add missing includes
<!--
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 missing headers related to...
<!--
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 missing headers related to [MR](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3462)
<!--
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)
-->
3.7
Hamza Oukili
Hamza Oukili
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2333
Add missing includes to fix headercheck
2020-11-01T16:32:11Z
Kilian Weishaupt
Add missing includes to fix headercheck
3.3
Kilian Weishaupt
Kilian Weishaupt
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2364
add missing namespace qualification
2020-11-06T10:10:24Z
Bernd Flemisch
add missing namespace qualification
This apparently is only triggered by the cornerpoint test.
Should be backported to 3.3.
This apparently is only triggered by the cornerpoint test.
Should be backported to 3.3.
3.3
Kilian Weishaupt
Kilian Weishaupt
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3232
Add missing stuff at the top of files.
2022-07-28T00:51:57Z
Melanie Lipp
Add missing stuff at the top of files.
<!--
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**:
Dumux files usually start by
`...
<!--
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**:
Dumux files usually start by
```
// -*- mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-
// vi: set et ts=4 sw=4 sts=4:
/*****************************************************************************
* See the file COPYING for full copying permissions. *
* *
* This program is free software: you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation, either version 3 of the License, or *
* (at your option) any later version. *
* *
* This program is distributed in the hope that it will be useful, *
* but WITHOUT ANY WARRANTY; without even the implied warranty of *
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
* GNU General Public License for more details. *
* *
* You should have received a copy of the GNU General Public License *
* along with this program. If not, see <http://www.gnu.org/licenses/>. *
*****************************************************************************/
```
I spotted some files, which do not do so for no reason obvious to me. I added missing lines to have a standard starting block in those cases.
<!--
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] 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)
-->
3.6
Melanie Lipp
Melanie Lipp