dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2023-03-09T08:53:38Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3418Cleanup/resolve istlsolver depracations2023-03-09T08:53:38ZHamza OukiliCleanup/resolve istlsolver depracations<!--
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**:
Removes deprecation warnings r...<!--
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**:
Removes deprecation warnings related to the AMGBackend in the tests.
<!--
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.
-->
Related to #1223
**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.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3415[ci] temporary fix for conflicts with opm cmake setup2023-03-01T16:46:04ZDennis Gläser[ci] temporary fix for conflicts with opm cmake setupAdds a (temporary) fix for the python tests in the CI when opm is installed (OPM is not used in the python tests anywhere). A proper solution probably needs upstream changes, but until then, this seems to make the CI pass...
TODO:
- [x...Adds a (temporary) fix for the python tests in the CI when opm is installed (OPM is not used in the python tests anywhere). A proper solution probably needs upstream changes, but until then, this seems to make the CI pass...
TODO:
- [x] commits should be squashed upon merge3.7Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3405Resolve "[frictionlaws] Roughnessheight calculation in friction laws"2023-03-09T14:27:10ZLeopold StadlerResolve "[frictionlaws] Roughnessheight calculation in friction laws"<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**Make adding artificial water depth in friction laws optional**:
TODO:
- [x]...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**Make adding artificial water depth in friction laws optional**:
TODO:
- [x] adapt limitRoughH in frictionlaw.hh for zero roughnessHeight
- [x] make roughnessHeight optional parameter (default = 0.0) for Manning
- [x] make roughnessHeight optional parameter (default = 0.0) for Nikuradse
- [x] Improve documentation in friction laws
Add some tests
- [x] Add test Nikuradse
<!--
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**
I added a new rough channel example with limited Nikuradse friction law to ensure that the changes will work. All previous tests and examples produce the same results since the water depth was always large enough or no friction law was applied.
Should these changes are mentioned somewhere?
<!--
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 #1216Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3398[fix][md] Add Residual vector to Multidomain traits and fix multidomain conve...2023-03-14T20:16:13ZAnna Mareike Kostelecky[fix][md] Add Residual vector to Multidomain traits and fix multidomain convergence writer* ResidualVector is added to the multidomain traits
* The `MultiDomainNewtonConvergenceWriter` is adapted such that `SolutionVector` type and the `ResidualVector` type are distinguished, as introduced in !3385.
Fixes #1227
- [x] does...* ResidualVector is added to the multidomain traits
* The `MultiDomainNewtonConvergenceWriter` is adapted such that `SolutionVector` type and the `ResidualVector` type are distinguished, as introduced in !3385.
Fixes #1227
- [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.7Anna Mareike KosteleckyAnna Mareike Kosteleckyhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3389[example] cahn hilliard including full model2023-07-18T11:11:18ZTimo Kochtimokoch@math.uio.no[example] cahn hilliard including full modelSimilar intent as example of !3380 implementing a nonlinear model with two equations.
Parallel should work with e.g. `DUMUX_NUM_THREADS=1 mpirun -np 4 ./example_cahn_hilliard` (multi-threaded assembly will not help much because the main ...Similar intent as example of !3380 implementing a nonlinear model with two equations.
Parallel should work with e.g. `DUMUX_NUM_THREADS=1 mpirun -np 4 ./example_cahn_hilliard` (multi-threaded assembly will not help much because the main time is the solver, could try different solver with !3386 or the solver factory).
* [x] Add example description and doc generator3.7Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3385[assembler][pdesolver] Distinguish Resiudal and Solution types and set residu...2023-02-23T13:05:39ZTimo Kochtimokoch@math.uio.no[assembler][pdesolver] Distinguish Resiudal and Solution types and set residual to dune native type**What this MR does / why does DuMux need it**:
Various models in Dumux enable primary variable switching. This is realized by using special block types in the solution coefficient vector that specifies which variables are stored (state...**What this MR does / why does DuMux need it**:
Various models in Dumux enable primary variable switching. This is realized by using special block types in the solution coefficient vector that specifies which variables are stored (state). These custom block types are not well supported by Dune and are also not needed in linear solver and assembler. With this MR we distinguish the `SolutionVector` type and the `ResidualVector` type. Solution vectors may contain Dumux-specific custom block types whereas the `ResidualVector` type is native to the linear algebra backend (at the moment only dune-istl).
This also fixes the strange behavior that if Jacobian/Residual are scalars the solver is still fed a vector of size 1. Now the solver receives a scalar as expected (see test_newton/test_timestepmethods).
This MR will simplify the implementation of the improved solver interfaces in !2113.
**Notes for the reviewer**
The changes are not backwards-compatible.
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] 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.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3368[extract module] add option to include GPLv3 license to new module2023-02-08T01:36:15ZTorben Schiz[extract module] add option to include GPLv3 license to new module<!--
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 #1202 .
This MR adds the...<!--
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 #1202 .
This MR adds the option to automatically add a GPLv3 license file to a new module when executing the `extract_as_new_module.py` script as discussed in issue #1202 . When choosing to add a license, licensing information is also added to the `README.md` file. To my understanding, this is necessary, because in the past, without this option, it would happen regularly that new modules would be extracted and published without proper licensing, which is critical. This especially concerns code accompanying scientific papers that are published in the `dumux-pub` repository.
<!--
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**
I put the license file in a directory in the `bin` directory, because I think that adding such a long text directly into the code will make the unclear and hard to read and understand. If there are better alternatives to store the license, this could be changed easily, in my opinion.
<!--
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 Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3359remove ".git" with endswidth check rather than rstrip2023-01-11T17:20:21ZNed Coltmanremove ".git" with endswidth check rather than rstrip<!--
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**:
The `make_installscript.py` 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**:
The `make_installscript.py` script cleans the URL provided to find the name of the module that it wants to clone. During the cleaning, the ".git" ending is removed using the string rstrip method.
Unfortunately, if the module ends with the characters `g`, `i`, `t`, or `.`, these are also removed. Here is an example:
```
url = "https://gitlab.dune-project.org/core/dune-something.git"
targetModule = url.rstrip(".git").split("/")[-1]
print(targetModule)
```
returns `dune-somethin`, where the actual target should be `dune-something`
<!--
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**
```
url = "https://gitlab.dune-project.org/core/dune-something.git"
targetModule = url.split("/")[-1].replace(".git", "")
print(targetModule)
```
returns `dune-something`. I tested this briefly and it works for all cases I can think of.
I guess we don't have many dumux-appl modules that end in those characters, and the dumux-pub modules typically end in numbers or characters earlier in the alphabet.
<!--
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)
<!--
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.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3355[bin][postprocessing] add pvpython version check for 5.112023-01-20T06:47:35ZAnna Mareike Kostelecky[bin][postprocessing] add pvpython version check for 5.11<!--
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**:
extractlinedata script checks ...<!--
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**:
extractlinedata script checks now also for the new Paraview/pvpython version 5.11.
<!--
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**
Note that the use of the PlotOverLine function is slightly different from earlier pvpython versions.
<!--
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 KosteleckyAnna Mareike Kosteleckyhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3351[rans] Allow for more general solution types in addDynamciwWallProps2022-12-23T13:53:19ZTimo Kochtimokoch@math.uio.no[rans] Allow for more general solution types in addDynamciwWallPropsShould be backported to release 3.6 for the course to work.Should be backported to release 3.6 for the course to work.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3342[md][freeflow] Update pressure and viscosity functions in couplingmanager2022-11-22T16:46:35ZMartin Schneider[md][freeflow] Update pressure and viscosity functions in couplingmanagerWhen using `isRotationalExtrusion` for a coupled momentum-mass problem, the coupling manager needs the functions `effectiveViscosity(element, fvGeometry, scv)` and `pressure(element, fvGeometry, scv)` (called by the base problem).
These ...When using `isRotationalExtrusion` for a coupled momentum-mass problem, the coupling manager needs the functions `effectiveViscosity(element, fvGeometry, scv)` and `pressure(element, fvGeometry, scv)` (called by the base problem).
These functions were missing.
Furthermore, the argument `considerPreviousTimeStep` has been added to these functions such that they are now consistent with the already implemented density functions.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3320Revert "Merge branch 'fix/multithreading-temp' into 'master'"2022-10-07T15:09:48ZTimo Kochtimokoch@math.uio.noRevert "Merge branch 'fix/multithreading-temp' into 'master'"3.6Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3316Change default multithreading backend from TBB to OpenMP2022-10-07T12:58:36ZMathis KelmChange default multithreading backend from TBB to OpenMPThe TBB backend appears to be causing some issues that are resolved by using OpenMP instead. This makes OpenMP the first choice instead.The TBB backend appears to be causing some issues that are resolved by using OpenMP instead. This makes OpenMP the first choice instead.3.6Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3292[pq1bubble] Implement specific bubble functions2022-09-27T21:51:41ZMartin Schneider[pq1bubble] Implement specific bubble functionsExplicit implementation of bubble functions.Explicit implementation of bubble functions.3.6Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3282Cleanup/resolve deprecations2022-09-16T17:15:26ZMathis KelmCleanup/resolve deprecations<!--
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**:
Resolves deprecation warnings ...<!--
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**:
Resolves deprecation warnings introduced by !3202.
- [x] Address remaining calls of `Extrusion::area(scvf)` and `BoxGeometryHelper.scvfArea/Volume(corners_)`
<!--
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.
- [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)
-->3.6Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3277[doc][doxygen] Add missing class documentation.2022-09-06T08:33:00ZMelanie Lipp[doc][doxygen] Add missing class documentation.<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
This MR adds some missing class...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
This MR adds some missing class documentation.
Is there a corresponding issue?
Related to #1178
<!--
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.6Melanie LippMelanie Lipphttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3276Reduce number of warnings and some cleanup2022-09-05T09:01:21ZChristoph GrüningerReduce number of warnings and some cleanup* Fix warnings by Clang 15
* Remove outdated version.hh and DUNE version checks* Fix warnings by Clang 15
* Remove outdated version.hh and DUNE version checks3.6Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3259Distinguish mass and momentum problem2022-08-19T06:31:00ZMartin SchneiderDistinguish mass and momentum problemFixes #1183Fixes #1183Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3238[handbook] Escape underscore in normal text2022-07-31T13:07:07ZDavid Werner[handbook] Escape underscore in normal text<!--
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 unescaped underscore cha...<!--
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 unescaped underscore character in latex of the handbook. The dumux website deployment is else broken.
<!--
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**
Fixes #1181
<!--
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)
-->3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3234[discretization] Add basic gridgeometry2022-09-25T09:35:01ZTimo Kochtimokoch@math.uio.no[discretization] Add basic gridgeometryThis implementation allows to implement gridgeometry which share
the same underlying BasicGridGeometry instance. This means only one
bounding box tree, element map, index mapper. This is useful
when different discretizations are construc...This implementation allows to implement gridgeometry which share
the same underlying BasicGridGeometry instance. This means only one
bounding box tree, element map, index mapper. This is useful
when different discretizations are constructed on the same grid view.
The "old" class `BaseGridGeometry` is now just a thin wrapper around the new `BasicGridGeometry`. The `BasicGridGeometry` is identical to the old `BaseGridGeometry` but is now intended for stand-alone usage in the main file. Discretization-scheme specific grid geometries still inherit from `BaseGridGeometry`.
This allows for two new features
* the basic grid geometry can now be shared between two or more discretization-scheme specific grid geometries on the same grid view
* the base grid geometry allows exchanging the actual implementation of the basic gridgeometry if this is desired to add some basic common shared features3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.no