dumux merge requests
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests
2023-07-24T17:27:45Z
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3575
Feature/hld time loop
2023-07-24T17:27:45Z
Leon Keim
Feature/hld time loop
<!--
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:
- [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?
- [x] (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)
-->
Kai Wendel
Kai Wendel
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3574
Delete old groups definition in core.md
2023-06-28T13:35:13Z
Ivan Buntic
Delete old groups definition in core.md
Merge minor fix
Merge minor fix
Ivan Buntic
Ivan Buntic
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3569
Draft: Feature/ff pm coupling allow different discretizations
2023-07-26T14:25:19Z
Martin Schneider
Draft: Feature/ff pm coupling allow different discretizations
<!--
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**:
To be able to choose different discretization schemes for ff-pm coupling, we need to allow discretization-dependent specializations.
<!--
Is there a corresponding issue? Add "Fixes hashtag issuenumber" which will automatically close the issue when this MR is merged. Add "Related to hashtag issuenumber" if it's related but doesn't fix the issue completely.
-->
**Notes for the reviewer**
TODO: insert text here
<!--
Keep the following TODO list in the merge request description for documentation.
Bullet points marked with _(if not applicable remove)_ may be removed.
-->
Before you request a review from someone, make sure to revise the following points:
- [ ] does the new code follow the [style guide](doc/styleguide.md)?
- [ ] do the test pipelines pass? (see guide on [how to run pipelines for a merge request](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Running-test-pipelines-for-merge-requests))
- [ ] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)
- [ ] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [ ] is the list of the header includes complete? ("include what you use")
- [ ] all files have to end with a `\n` character. Make sure there is no `\ No newline at end of file` comment in "Changes" of this MR.
- [ ] (if not applicable remove) are newly introduced or modified physical values/functions backed up with a scientific reference (including doi) in the docs?
- [ ] (if not applicable remove) if the examples are modified, is the documentation regenerated (using [`generate_example_docs.py`](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/examples/generate_example_docs.py))
<!--
The following aspects might also come up during review:
* Does the change reduce the performance of the code (more CPU time or more memory) and is this justified by the benefits
* Does the change improve the performance? (if yes, add this aspect to the MR description)
* Is the code is a gross violation of programming best practices such as DRY (don't repeat yourself / code duplication, see https://de.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself, the SOLID principles (https://en.wikipedia.org/wiki/SOLID), or the C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)?
* Is the code well-documented, concise, easily readable? (e.g. variables are well-named, the logic is split into small & well-named functions)
-->
3.8
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3551
Merge branch 'fix/changesolver-to-sequential' into 'master'
2023-04-20T11:43:38Z
Hamza Oukili
Merge branch 'fix/changesolver-to-sequential' into 'master'
3.7
Hamza Oukili
Hamza Oukili
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3483
Draft: Fix headers in the tests with the new co2table
2023-03-24T05:06:29Z
Hamza Oukili
Draft: Fix headers in the tests with the new co2table
<!--
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**:
Fix the headers in the tests f...
<!--
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**:
Fix the headers in the tests for the new co2tables related to the MR !3455
<!--
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**
The pipeline broke, this fix should fix it.
<!--
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)
- [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/3446
Draft: [doxygen] modules now in markdown.
2023-03-22T15:24:06Z
Leon Keim
Draft: [doxygen] modules now in markdown.
<!--
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**:
Rewrites the old modules in a ...
<!--
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**:
Rewrites the old modules in a markdown files.
<!--
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)
-->
Leon Keim
Leon Keim
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3437
Draft: [doxygen][main] adjust link name
2023-03-13T10:20:10Z
Dennis Gläser
Draft: [doxygen][main] adjust link name
Since !3432, one can click on the link behind `modules` on the main page, and the lands at `Models and main components`. This is maybe a bit counterintuitive.
Since !3432, one can click on the link behind `modules` on the main page, and the lands at `Models and main components`. This is maybe a bit counterintuitive.
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3408
[doxygen][staggered] fix missing group titles
2023-02-28T18:27:04Z
Dennis Gläser
[doxygen][staggered] fix missing group titles
Addresses a few `doxygen` warnings from missing group titles for staggered schemes.
Addresses a few `doxygen` warnings from missing group titles for staggered schemes.
3.7
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3402
Draft: [TEMP][ci] try deactivating python bindings for opm
2023-02-24T16:41:22Z
Dennis Gläser
Draft: [TEMP][ci] try deactivating python bindings for opm
<!--
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
<!--
I...
<!--
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)
-->
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3396
[diffusion test] test a nonrandom initial condition
2023-03-15T08:47:06Z
Kai Wendel
[diffusion test] test a nonrandom initial condition
!closes #1219
It seems, that we should think about, if it is a problem of the initial condition, so because of the use of multiple processes, the random numbers applied vary on the domain.
Then it would not be a bug of the solver or a ...
!closes #1219
It seems, that we should think about, if it is a problem of the initial condition, so because of the use of multiple processes, the random numbers applied vary on the domain.
Then it would not be a bug of the solver or a problem with overlap at all.
If one changes the term in the main file in line 174 to:
```cpp
sol[n] = double(n%2)/10.0;
```
then the initial conditions are the same. This is totally different for a value of 7 instead of 2.
We should find a way, that ensures that initial conditions are the same no matter if mpi is used or not, maybe via a loadsolution.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3395
[diffusion test] test a nonrandom initial condition
2023-02-23T09:19:26Z
Kai Wendel
[diffusion test] test a nonrandom initial condition
<!--
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
<!--
I...
<!--
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)
-->
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3358
Draft: Feature/fieldcompare reuse abs tol estimator
2023-01-19T15:25:41Z
Dennis Gläser
Draft: Feature/fieldcompare reuse abs tol estimator
<!--
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
<!--
I...
<!--
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)
-->
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3357
Draft: [bin][runtest] reuse abs_tol estimator from fieldcompare
2023-01-18T13:57:10Z
Dennis Gläser
Draft: [bin][runtest] reuse abs_tol estimator from fieldcompare
<!--
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
<!--
I...
<!--
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)
-->
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3354
[test] Simplify test driver with new fieldcompare version
2023-01-06T11:08:05Z
Timo Koch
timokoch@math.uio.no
[test] Simplify test driver with new fieldcompare version
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3329
Draft: feature/new-tpfa-grid-geometry
2023-12-13T10:52:22Z
Dennis Gläser
Draft: feature/new-tpfa-grid-geometry
**What this MR does / why does DuMux need it**:
TODO: insert text here
TODOS:
- [x] we should probably add support for injecting custom stencils (currently we have that extended source stencil somewhere...) - EDIT: should be fine becau...
**What this MR does / why does DuMux need it**:
TODO: insert text here
TODOS:
- [x] we should probably add support for injecting custom stencils (currently we have that extended source stencil somewhere...) - EDIT: should be fine because it seems that we currently do this in the classes related to coupling, which is probably better
- [x] extraction/reusage of the `BasicGeometry`, which is currently possible on master - EDIT: should be fine, because this inherits from `BaseGridGeometry`, which takes care of this
- [x] we may think of making grid geometries "observable" to design our depending classes such that they can automatically update in adaptive simulations (probably best to postpone once it actually becomes relevant during development) - EDIT: this would be a change to `BaseGridGeometry`, so I would postpone that (I opened an issue for that: #1192)
- [x] Add a unique local index per scvf (needed for stationary flux fields e.g. in tracer model?)
- [x] Add a test on a corner point grid
- [ ] remove performance test
Relates #1173
**Notes for the reviewer**
TODO: insert text here
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)
-->
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3322
Draft: Feature/new assembly cctpfa grid geom
2022-11-30T11:37:23Z
Dennis Gläser
Draft: Feature/new assembly cctpfa grid geom
<!--
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**:
Introduces a new `GridGeometry...
<!--
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**:
Introduces a new `GridGeometry` for cell-centered finite volume schemes with a modified interface of local views. The new implementation uses significantly less memory while (at least for one considered performance test) being equally fast with caching, but over 3 times faster without caching (while still requiring less memory). The new implementation does not contain a `ConnectivityMap`, as the new local view interface should be enough to construct connectivity information. The new local view interface could be useful in the new assembly...
TODO:
- [ ] I added a header in `geometry/normal`, that, given a geometry and the index of a codim-1 entity computes the outer unit normal vector. In case we keep this, this should be done properly...
- [ ] we should probably add support for injecting custom stencils (currently we have that extended source stencil somewhere...)
- [ ] extraction/reusage of the `BaseGeometry`, which is currently possible on master
- [ ] we may think of making grid geometries "observable" to design our depending classes such that they can automatically update in adaptive simulations (probably best to postpone once it actually becomes relevant during development)
<!--
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.
-->
Relates #1173
**Notes for the reviewer**
The new implementation has the following key differences:
1. It introduces the concept of a `Face`, which is basically the geometric part of our current scvfs (center, area). The scvfs internally reuse a face and additionally expose the outer normal vector. This way, one only has to compute/store the geometric information on scvfs once for all branches meeting at the face. This reduces the memory overhead, but comes with the downside that now scvfs are no longer self-contained objects. Internally, they currently store a pointer to a `Face`, so the lifetime is bound to the lifetime of `Face`. The intended usage is solely with a previously bound local view (which we currently do and promote anyway).
2. The only things (currently) configurable in new implementation are related to optimizing memory - the number of maximum neighbors per face, etc. We had this before, I just renamed the variables to (hopefully) make it a bit more clear what exactly can be customized, and I chose those variation points such that internally we can optimize memory usage. In the old implementation, one could inject the type of `LocalView` to be used as well as the type of `SubControlVolume` and `SubControlVolumeFace`. I didn't really see the use case for the latter two, because the grid geometry constructs these objects (at least in case of caching), so the constructor is fixed, but since these only store/expose the information given in the ctor (basically), I didn't see why I would want to use different types. I figured that if I want different behaviour, I may simply wrap the existing GG and local views and expose some new interface. It also seemed to me that this would be the easiest way in case I want a different local view... Besides this, to really use a custom `LocalView` is probably pretty difficult, as you need to know quite something on the internal wires of the grid geometry... But I am happy to hear examples on where I would need this.
3. Related to 2: While one can inject less things into the GG, I think it is now also easier to just implement a custom grid geometry. I extracted the connectivity determination step into a reusable class, such that in the case of caching, the only thing the grid geometry does is to use that info and construct the grid geometries. In this case the local view basically just forwards calls to the grid geometry. In the case of no caching, the grid geometry class is pretty much empty, and the local view contains the logic of constructing the locally (in the stencil) required geometries. So I don't really see what should be injected where and why (over just wrapping), besides that the GG and local view are highly cohesive...
4. In the case of no caching, the local view does not store the dof indices anymore, finding the local index of scvs by searching in that local container. I went for a different approach, wrapping the Scvs and Scvfs in something that additionally carries an `id`, which is private and can only be accessed by the local view itself. Thus, the local view actually returns not `SubControlVolume`, but a wrapped sub-control volume with the same public interface. I don't mind this, though.
5. Related to 2: Internally, we currently use `Dune::ReservedVector` to store things, and the maximum expected container size can be configured via the traits. I added a class `DefaultStorage`, which uses `Dune::ReservedVector` when an integer value is given for the desired size, but I also introduced a class `Size::Dynamic`, and if that one is set, it uses `std::vector` internally. `Dynamic` can be used in arithmetic operations to compute sizes, with the result always being `Dynamic`. This allows for users to configure the grid geometry such that it uses purely dynamic containers for everything. This could be useful especially on network grids where you may have a few vertices with many branches while the majority of the network only has one branch. In this case `Dynamic` should avoid unnecessary memory overhead.
<!--
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)
-->
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3319
Draft: Merge branch 'fix/multithreading-temp' into 'master'
2022-10-07T19:17:51Z
Mathis Kelm
Draft: Merge branch 'fix/multithreading-temp' into 'master'
Backports fix for multithreading of for loops.
Backports fix for multithreading of for loops.
3.6
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3307
[doc] replace outdated copyright notice
2022-10-04T16:03:19Z
Mathis Kelm
[doc] replace outdated copyright notice
Updates copyright notice to the new version.
Updates copyright notice to the new version.
3.6
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3298
Draft: Merge branch 'fix/deprecated-attribute' into 'master'
2022-09-28T15:58:09Z
Stefanie Kiemle
Draft: Merge branch 'fix/deprecated-attribute' into 'master'
<!--
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 description for dispersion ...
<!--
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 description for dispersion
<!--
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/3283
[geometry] Add volume function with transformed integrationElement
2022-09-14T17:00:56Z
Timo Koch
timokoch@math.uio.no
[geometry] Add volume function with transformed integrationElement
3.6
Mathis Kelm
Mathis Kelm