dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2023-01-11T17:20:21Zhttps://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/3360[test][components] Use constexpr and is_detected2023-01-23T14:05:10ZTimo Kochtimokoch@math.uio.no[test][components] Use constexpr and is_detectedFixes #1208
This should make it easier for cppcheck (although this was a false positive) but it also makes the code more readable and shorter.Fixes #1208
This should make it easier for cppcheck (although this was a false positive) but it also makes the code more readable and shorter.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3361[installexternal] Do some safety checks on tar archives using TarSafe2023-01-23T13:45:00ZTimo Kochtimokoch@math.uio.no[installexternal] Do some safety checks on tar archives using TarSafeFixes #1207Fixes #12073.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3362[fmt] Update shipped version to 9.1.02023-01-25T23:38:42ZTimo Kochtimokoch@math.uio.no[fmt] Update shipped version to 9.1.03.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3363[ci] Run cppcheck static code analysis2023-02-10T20:26:25ZTimo Kochtimokoch@math.uio.no[ci] Run cppcheck static code analysis3.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3364[io][gnuplot] Fix variable type2023-01-23T14:26:41ZTimo Kochtimokoch@math.uio.no[io][gnuplot] Fix variable type3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3365[cleanup][io] Small fixes in raster image reader2023-01-23T15:12:20ZTimo Kochtimokoch@math.uio.no[cleanup][io] Small fixes in raster image reader3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3366Fix python binding docs2023-02-06T19:38:43ZMartin UtzFix python binding docsBefore 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 r...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.7Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3367[ci] add job for doxygen docu build2023-03-02T12:36:10ZDennis Gläser[ci] add job for doxygen docu build<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Adds a build of the `doxygen` ...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Adds a build of the `doxygen` documentation to the `build` stage in one of our pipelines.
<!--
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.
-->
Fixes #1187
<!--
Keep the following TODO list in the merge request description for documentation.
Bullet points marked with _(if not applicable remove)_ may be removed.
-->
- [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.7Dennis GläserDennis Gläserhttps://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/3369Use standard-conforming detector idiom2023-02-06T22:01:44ZChristoph GrüningerUse standard-conforming detector idiomSee also:
https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1218
https://gitlab.dune-project.org/core/dune-common/-/issues/326
Change required with changes in Dune with didn't fully conform to the C++ standard interf...See also:
https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1218
https://gitlab.dune-project.org/core/dune-common/-/issues/326
Change required with changes in Dune with didn't fully conform to the C++ standard interface.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3370[ci] Use new specification of exceptions in pylint config2023-02-06T17:17:06ZMathis Kelm[ci] Use new specification of exceptions in pylint config<!--
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**:
Specifying exceptions as overl...<!--
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**:
Specifying exceptions as overly general without module name is deprecated and will be removed with Pylint 3.0.Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3371separate development python dependencies into requirements.txt2023-02-06T16:17:05ZMathis Kelmseparate development python dependencies into requirements.txt<!--
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**:
Development dependencies shoul...<!--
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**:
Development dependencies should be installed separately and with fixed versions.
<!--
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.7Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3372[spgrid] Add gridmanager.init(...) with lowerLeft/upperRight/cells2023-02-07T03:10:00ZTimo Kochtimokoch@math.uio.no[spgrid] Add gridmanager.init(...) with lowerLeft/upperRight/cellsAnalogously to YaspGrid add an interface for SPGrid to create the grid by passing parameters explicitly instead of reading them from the parameter tree.Analogously to YaspGrid add an interface for SPGrid to create the grid by passing parameters explicitly instead of reading them from the parameter tree.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3373Merge branch 'fix/separate-development-dependencies' into 'master'2023-02-06T18:09:14ZMathis KelmMerge branch 'fix/separate-development-dependencies' 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**:
Backport !3371 to latest relea...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Backport !3371 to latest release 3.6 to fix CI errors caused by updated dependency.Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3374[ci] Also pass project URL to downstream trigger2023-02-07T17:53:14ZTimo Kochtimokoch@math.uio.no[ci] Also pass project URL to downstream triggerTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3375[ci] Pass source project path to downstream pipeline2023-02-07T23:39:37ZTimo Kochtimokoch@math.uio.no[ci] Pass source project path to downstream pipelinehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3376[shallowwater] Add viscous bottom shear stress Poiseuille flow test2023-02-14T09:32:58ZTimo Kochtimokoch@math.uio.no[shallowwater] Add viscous bottom shear stress Poiseuille flow test<!--
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 introduces a new friction...<!--
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 introduces a new friction law for the case of very thin shallow water flows (thin film) where viscous forces are dominating.
Also adds a test case for poiseuille flow at low velocities and tiny water depth, where the walls are full-slip (tangential), no-flow (normal), and the bottom friction is that due to "parallel plate flow" (without the top plate) / plane Poiseuille flow.
**Notes for the reviewer**
TODOs
* [x] Put viscous no slip in its own header -> Viscosity needs to come from volume variables
* [x] Why is the viscosity in the viscous flux called turbulent viscosity? I guess it's the effective viscosity (including "eddy viscosity") Usually we split this into a regular viscosity part which comes from the fluid system and an effective part which would correspond to the turbulence model. This would also be helpful here.
* [x] We could add viscosity like density in the volvars (without memory overhead and requiring that it's a constant for now -> no runtime overhead).
**Checklist**
- [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.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3377[swe] Implement viscosity interface in volume variables2023-02-10T21:42:51ZTimo Kochtimokoch@math.uio.no[swe] Implement viscosity interface in volume variableshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3378[fix] Fix file permission. Some files were erroneously executable2023-02-13T14:07:12ZTimo Kochtimokoch@math.uio.no[fix] Fix file permission. Some files were erroneously executable3.7