dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2022-12-12T09:33:48Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3345[opm] support version 2022.102022-12-12T09:33:48ZDennis Gläser[opm] support version 2022.10<!--
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 support for `opm-2022.10`...<!--
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 support for `opm-2022.10` via preprocessor checks.
<!--
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)
-->Dennis GläserDennis Gläserhttps://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/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/3352Merge branch 'fix/freeflow-allow-partial-proxy-solution' into 'master'2022-12-23T14:07:34ZTimo Kochtimokoch@math.uio.noMerge branch 'fix/freeflow-allow-partial-proxy-solution' into 'master'Backport of !3351 needed to make the dumux-course workBackport of !3351 needed to make the dumux-course work3.6https://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/3356[cleanup] [test][md][stokesdarcy][1p2c] remove unused properties_stokes.hh2023-01-05T11:33:24ZAnna Mareike Kostelecky[cleanup] [test][md][stokesdarcy][1p2c] remove unused properties_stokes.hhThis is related to issue #1206
<!--
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 is related to issue #1206
<!--
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**:
Removed unused properties file 'properties_stokes.hh' as all properties of coupled problem are stored in 'properties.hh'.
<!--
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)
-->Anna Mareike KosteleckyAnna Mareike Kosteleckyhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3354[test] Simplify test driver with new fieldcompare version2023-01-06T11:08:05ZTimo Kochtimokoch@math.uio.no[test] Simplify test driver with new fieldcompare versionhttps://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/3097Draft: Feature/test templated typetags2023-01-11T18:41:51ZTimo Kochtimokoch@math.uio.noDraft: Feature/test templated typetagshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3357Draft: [bin][runtest] reuse abs_tol estimator from fieldcompare2023-01-18T13:57:10ZDennis GläserDraft: [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/3358Draft: Feature/fieldcompare reuse abs tol estimator2023-01-19T15:25:41ZDennis GläserDraft: 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/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/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/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/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/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/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.no