dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2023-03-21T22:26:02Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3463[disc] Deprecate scv/scvf.geometry/corner2023-03-21T22:26:02ZTimo Kochtimokoch@math.uio.no[disc] Deprecate scv/scvf.geometry/cornerAddresses #1173 (makes sure we can finish this task after release 3.7 and all interfaces are properly deprecated for release 3.7).Addresses #1173 (makes sure we can finish this task after release 3.7 and all interfaces are properly deprecated for release 3.7).3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3462[assembly][cvfe] Unify CVFE assembly2023-03-21T13:09:01ZTimo Kochtimokoch@math.uio.no[assembly][cvfe] Unify CVFE assembly* [x] Unify the local and subdomain assemblers for CVFE
* [x] Unify treatment for fcdiamond on the boundary, treat like other CVFE schemes (non-compatible change)
* [x] Add changelog entry for fcdiamond
* [x] Remove obsolete local assemb...* [x] Unify the local and subdomain assemblers for CVFE
* [x] Unify treatment for fcdiamond on the boundary, treat like other CVFE schemes (non-compatible change)
* [x] Add changelog entry for fcdiamond
* [x] Remove obsolete local assemblers
depends on !3460 because it adopts that bugfix to all CVFE schemes.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3461Feature/ci test example up to dateness2023-03-19T14:51:20ZDennis GläserFeature/ci test example up to dateness<!--
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 the generation of the exa...<!--
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 the generation of the example documentation to the CI, verifying that it is in sync with the corresponding sources. This detects if either an example's README file was modified instead of the sources, or, if the documentation was not regenerated and committed.
<!--
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.7Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3460[cvfe][pnm] Update solution dependent flux vars caches2023-03-18T18:38:29ZTimo Kochtimokoch@math.uio.no[cvfe][pnm] Update solution dependent flux vars cachesFixes #1196 #661
* [x] Do it for the other local assembler variants as well and all cvfe schemesFixes #1196 #661
* [x] Do it for the other local assembler variants as well and all cvfe schemes3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3459[poroelastic] fix the average density in localresidual2023-03-17T14:47:30ZYue Wangyue.wang@iws.uni-stuttgart.de[poroelastic] fix the average density in localresidual<!--
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**:
@NNagel found the bug of densi...<!--
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**:
@NNagel found the bug of density calculation in poroelastic model.
<!--
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**
<!--
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/3458Feature/flexible geometry helper2023-03-17T01:23:18ZMartin SchneiderFeature/flexible geometry helper<!--
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**:
As already done for other disc...<!--
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**:
As already done for other discretization models, e.g. **MPFA** or **fcstaggered**, the geometry helper can be deduced from the Traits class.
This offers more flexibility. Furthermore, in the `fvelementgeometry.hh` the type of the helper is deduced from the gridgeometry.
<!--
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**
This could help unifying grid geometries for CVFE schemes and
is for example also needed to easly switch between overlapping and non-overlapping scvs by changing only the helper class
<!--
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.3.7Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3457[material][SimpleCO2] fix enthalpy calculation2023-03-16T23:48:21ZMathis Kelm[material][SimpleCO2] fix enthalpy calculation<!--
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 some errors related to t...<!--
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 some errors related to the SimpleCO2 component.
We should add a test that uses the nonisothermal aspects of this component. The `BrineCO2` fluidsystem is not well suited for it, as it uses `liquidX` functions in strange places. As that fluidsystem was created for supercritical conditions it's not really a good fit for the `SimpleCO2` component anyway.
<!--
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] 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))3.7Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3456Cleanup/embedded example2023-03-16T17:32:27ZDennis GläserCleanup/embedded exampleA few minor edits on the embedded example
Fixes #1194A few minor edits on the embedded example
Fixes #11943.7Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3455Feature/standard co2 table2023-07-18T11:11:18ZYue Wangyue.wang@iws.uni-stuttgart.deFeature/standard co2 table<!--
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**:
see discussion in #1164.
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**:
see discussion in #1164.
The file `co2tables.hh` is moved into the `components`.
The template for `make_co2_table.py` includes the namespace and can be flexibly included.
<!--
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/3454Add warning amgbackend.hh will be removed after 3.72023-03-16T19:03:58ZHamza OukiliAdd warning amgbackend.hh will be removed after 3.7<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Add warning amgbackend.hh will...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Add warning amgbackend.hh will be removed after 3.7
<!--
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**
<!--
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/3453Feature/doxygen markdown main readme2023-03-23T13:16:00ZTimo Kochtimokoch@math.uio.noFeature/doxygen markdown main readme* [x] Modify actual readme to look the same in GitLab and doxygen
* [x] Improve sections What is Dumux
* [x] Fix links
* [x] Create anchors with filter
* [x] Resolve `installation` section in readme and put in `Documentation`
* [x] renam...* [x] Modify actual readme to look the same in GitLab and doxygen
* [x] Improve sections What is Dumux
* [x] Fix links
* [x] Create anchors with filter
* [x] Resolve `installation` section in readme and put in `Documentation`
* [x] rename `Documentation` in README to `Overview`
* [x] modify script such that all .md are processed (runtime flag for header-level modification used in readme). Call math-modification script internally. The goal is that all headers in all .md files get anchors
* [x] Fix links to papers (seems to be too complex of a markdown link for doxygen)
* [x] Write compatibility table in ~~html~~markdown
Concept:
* Don't add default "pages" in the doxygen layout file
* Add pages and subpages manually into the sidebar
* TOCs in markdown are created with the `[TOC]` command
This allows to
* Split the module description into several files
* The use of `@addtogroup` to combine module documentation3.7Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3452[doxygen] Add filter to convert GitLab math to doxygen math in markdown2023-03-16T08:39:05ZTimo Kochtimokoch@math.uio.no[doxygen] Add filter to convert GitLab math to doxygen math in markdownMakes it possible to use GitLab markdown math syntax in doxygen markdown filesMakes it possible to use GitLab markdown math syntax in doxygen markdown files3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3451[examples][1d3d] Fix math typo2023-03-15T20:45:07ZTimo Kochtimokoch@math.uio.no[examples][1d3d] Fix math typo3.7https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3449[doxygen][header] Fix page overflow with gitlab corner2023-03-15T17:07:40ZTimo Kochtimokoch@math.uio.no[doxygen][header] Fix page overflow with gitlab corner3.7https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3448Remove deprecated file and satisfy headercheck2023-03-17T16:15:36ZMathis KelmRemove deprecated file and satisfy headercheck<!--
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 some missing headers so h...<!--
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 some missing headers so headercheck passes.
<!--
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.
-->
- [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.7Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3447[assembly] Use unified Jacbian sparsity pattern computation for CVFE methods2023-03-15T15:39:03ZTimo Kochtimokoch@math.uio.no[assembly] Use unified Jacbian sparsity pattern computation for CVFE methods**What this MR does / why does DuMux need it**:
Unifies Jacobian pattern computation for CVFE schemes (similar to !3445 for multidomain)
Fixes fcdiamond Jacobian for explicit time integration**What this MR does / why does DuMux need it**:
Unifies Jacobian pattern computation for CVFE schemes (similar to !3445 for multidomain)
Fixes fcdiamond Jacobian for explicit time integration3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3445[md][assembly] Unify coupling Jacobian pattern for cvfe schmes2023-03-15T14:45:35ZTimo Kochtimokoch@math.uio.no[md][assembly] Unify coupling Jacobian pattern for cvfe schmes**What this MR does / why does DuMux need it**:
Use the same implementation for the coupling jacobian for all cvfe schemes
- [x] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the exis...**What this MR does / why does DuMux need it**:
Use the same implementation for the coupling jacobian for all cvfe schemes
- [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] 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/3444[handbook] Update to 3.7, update discretization images and some text.2023-03-16T14:25:18ZIvan Buntic[handbook] Update to 3.7, update discretization images and some 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**:
This MR updates the versions o...<!--
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 updates the versions of Dumux and Dune in the handbook. Also, the images for tpfa, mpfa and box have been unified and the text for the box method has been updated.
<!--
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**
You need to compile the pdf of the handbook locally.
<!--
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] 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] 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.7Ivan BunticIvan Buntichttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3443[ff][velocityoutput] Enable velocity output for all CVFE schemes2023-03-15T10:14:44ZTimo Kochtimokoch@math.uio.no[ff][velocityoutput] Enable velocity output for all CVFE schemes3.7https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3442Feature/reuse compliant2023-07-18T11:11:23ZMathis KelmFeature/reuse compliant<!--
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 SPDX headers to all files...<!--
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 SPDX headers to all files and necessary license files to `dumux/LICENSES` to make DuMux REUSE compliant.
<!--
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**
<!--
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.7Mathis KelmMathis Kelm