dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2022-11-30T11:44:57Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3324Add test labels ransnc in CMakeLists.txt2022-11-30T11:44:57ZMathis KelmAdd test labels ransnc in CMakeLists.txtAdd missing ransnc test labelsAdd missing ransnc test labels3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3332Cleanup/remove deprecations in discretization2022-11-03T13:28:38ZYue Wangyue.wang@iws.uni-stuttgart.deCleanup/remove deprecations in discretization<!--
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**:
Remove the deprecated in the 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**:
Remove the deprecated in the folder /dumux/discretization
<!--
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.7Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3333Cleanup/remove deprecations in assembly and multidomain2022-11-03T14:52:22ZTim JupeCleanup/remove deprecations in assembly and multidomain<!--
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**:
Remove the deprecations in fol...<!--
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**:
Remove the deprecations in folder /dumux/assembly and /dumux/multidomain
<!--
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.7Tim JupeTim Jupehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3334[richards] Remove deprecated extension of Richards model2022-11-05T00:43:35ZMathis Kelm[richards] Remove deprecated extension of Richards model<!--
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 the old extensions of ...<!--
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 the old extensions of Richards model, deprecated in release 3.6. The new implementation now properly inherits from the base Richards model.
<!--
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/3335Improve doc of Riemann solver2022-12-02T12:52:56ZMartin UtzImprove doc of Riemann solverSlightly improve the documentation of the Riemann Solver as discussed in #1184 by documenting some cryptic variables.Slightly improve the documentation of the Riemann Solver as discussed in #1184 by documenting some cryptic variables.3.7Martin UtzMartin Utzhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3337Avoid duplicated checkPoints2022-11-21T09:23:24ZMartin UtzAvoid duplicated checkPoints<!--
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**:
Currently it is possible to se...<!--
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**:
Currently it is possible to set several checkpoints at the same time step. This seems to be a bug, since it yields to a time step size of 0.0, which causes a crash of the Newton solver due to Nan values.
<!--
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**
Is there any use case for several checkPoints at the same time, which I don't consider?
<!--
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.7Martin UtzMartin Utzhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3338[examples] Annotate model and discretization2022-11-07T09:35:02ZTimo Kochtimokoch@math.uio.no[examples] Annotate model and discretizationPreview here: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/feature/examples-model-discretization/examples/README.mdPreview here: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/feature/examples-model-discretization/examples/README.md3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3339[example] Add 1d3d tracer example2022-11-08T14:42:07ZTimo Kochtimokoch@math.uio.no[example] Add 1d3d tracer example<!--
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**:
A new documented example for 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**:
A new documented example for a 1D-3D multi-domain problem simulating tracer transport in a porous medium with embedded transport network.
* [x] Add fuzzy compare data regression test for the tissue tracer amount
**Notes for the reviewer**
Preview documentation here: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/feature/example-1d3d/examples/embedded_network_1d3d/README.md
Not all header files have been added to the documentation so far (e.g. `bloodflow.hh` and `solver.hh` are excluded). I wanted to focus on the main parts. This can be extended in the future.
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] 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/3341[readme] Update link to latest release pipeline2022-11-12T21:00:19ZTimo Kochtimokoch@math.uio.no[readme] Update link to latest release pipeline3.7https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3343[intersections] Make IntersectionPolicy customizable2022-11-30T15:46:23ZTimo Kochtimokoch@math.uio.no[intersections] Make IntersectionPolicy customizableI realized we had this customization point but it was not exposed.
In order to use a different intersection policy I had to copy the entire implementation.
Now it should be possible to choose the intersection policy (e.g. PointPolicy).
...I realized we had this customization point but it was not exposed.
In order to use a different intersection policy I had to copy the entire implementation.
Now it should be possible to choose the intersection policy (e.g. PointPolicy).
I implemented it as a function parameter, because there is already template arguments and they are being deduces.
So to introduce the policy, I would have to have introduced it as first template argument.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3344[box] Do not store corners in scv/scvf to save memory2022-11-30T17:59:02ZTimo Kochtimokoch@math.uio.no[box] Do not store corners in scv/scvf to save memoryReduces the memory footprint of the box grid geometry by not storing corners which are not needed anymore.Reduces the memory footprint of the box grid geometry by not storing corners which are not needed anymore.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3346[readme] Explicitly mention bug reports and how to report security vulnerabil...2022-12-12T14:56:21ZTimo Kochtimokoch@math.uio.no[readme] Explicitly mention bug reports and how to report security vulnerabilities3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3347[license][authors] Simplify LICENSE.md file to only contain license2022-12-13T12:38:55ZTimo Kochtimokoch@math.uio.no[license][authors] Simplify LICENSE.md file to only contain licenseE.g. github doesn't automatically recognize our license file because the format is too complex.
To increase machine-readability / meta-data extraction, I simplified the information
* Remove statement duplicated from README.md
* Move con...E.g. github doesn't automatically recognize our license file because the format is too complex.
To increase machine-readability / meta-data extraction, I simplified the information
* Remove statement duplicated from README.md
* Move contributors to a separate file AUTHORS.md
* Mention AUTHORS.md file in the README.md3.7Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3348Delete obsolete COPYING symlink2022-12-13T12:56:10ZTimo Kochtimokoch@math.uio.noDelete obsolete COPYING symlinkThis was meant to be for Debian packages. We do not have Debian packages to date.
Debian seemed to have updated the way copyright information is supplied anyway and there is no mention of a `COPYING` file: https://www.debian.org/doc/pack...This was meant to be for Debian packages. We do not have Debian packages to date.
Debian seemed to have updated the way copyright information is supplied anyway and there is no mention of a `COPYING` file: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
8d693cde3.7Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3349Feature/cvfe improvements2023-03-02T12:51:05ZTimo Kochtimokoch@math.uio.noFeature/cvfe improvementsUnify several files for all cvfe schemes to reduce code duplication
* Reduce code duplication in Navier-Stokes momentum model and coupling manager
* Deprecated separate coupling managers and separate Navier-Stokes momentum models
* Add ...Unify several files for all cvfe schemes to reduce code duplication
* Reduce code duplication in Navier-Stokes momentum model and coupling manager
* Deprecated separate coupling managers and separate Navier-Stokes momentum models
* Add `elementIndex` for box element geometry like for the other CVFE schemes3.7Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3350[test][stokes] Add stabilized Box-Box donea test2022-12-31T17:02:50ZTimo Kochtimokoch@math.uio.no[test][stokes] Add stabilized Box-Box donea test3.7Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3353Feature/fieldcompare2023-01-23T15:28:37ZTimo Kochtimokoch@math.uio.noFeature/fieldcompareUsing `fieldcompare` will allow some more comparisons than previously possible, e.g. binary VTUs or different mesh formats supported by meshio, e.g. comparing Gmsh `msh` files, or `CSV` data with given delimiter.
* [x] Install `fieldcom...Using `fieldcompare` will allow some more comparisons than previously possible, e.g. binary VTUs or different mesh formats supported by meshio, e.g. comparing Gmsh `msh` files, or `CSV` data with given delimiter.
* [x] Install `fieldcompare` in CI images
* [x] Fix reference solutions where there is some field name mismatch
* [x] Add and propagate option to ignore fields
* [x] Run pipeline that runs all tests (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/pipelines/25800, `DUMUX_SKIP_TEST_SELECTION=yes`)3.7Timo 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/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.no