dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2022-09-01T07:45:28Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3176Metadata unit test2022-09-01T07:45:28ZMartin SchneiderMetadata unit testMartin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3177Feature/flux documentation of Darcy flux2022-07-01T08:59:41ZTheresa SchollenbergerFeature/flux documentation of Darcy flux<!--
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 merge request improves th...<!--
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 merge request improves the documentation (discretization-agnostic) for the fluxes (e.g. Darcy's law / Fick's law / ...). With that no description of the flux laws in every model is needed. We can reference to this description in every model the individual flux law is used.
<!--
Is there a corresponding issue? Add "Fixes hashtag issuenumber" which will automatically close the issue when this MR is merged. Add "Related to hashtag issuenumber" if it's related but doesn't fix the issue completely.
-->
Related to #1149
<!--
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.6Theresa SchollenbergerTheresa Schollenbergerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3178[newton][bugfix] Correct faulty exception handler2022-07-04T21:39:21ZTimo Kochtimokoch@math.uio.no[newton][bugfix] Correct faulty exception handler<!--
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**:
Avoids a deadlock on the Dumux...<!--
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**:
Avoids a deadlock on the Dumux side in case of parallel runs. If one process throws, we make sure to catch the error and only set converged to false. Then, we check if all processes converged and throw on all processes.
Unfortunately, there can still be deadlocks if there is global communication (in Dune) after a process throws (in Dune) within some Dune function (e.g. in the solver). In that case, we cannot easily handle this in Dumux, because the communicating processes are stuck in the Dune function, and only the throwing process makes it back to Dumux. Therefore, we cannot recover (we could terminate after a timeout). See https://arxiv.org/abs/1804.04481 for a discussion of the general problem.
* [x] Add parallel unit test for newton where the assembler or linear solvers throw on one process (test failed before this bugfix)
<!--
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] 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)
-->
Fixes #11713.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3179[cc] Update volume variables in parallel when using caching2022-06-30T16:45:27ZTimo Kochtimokoch@math.uio.no[cc] Update volume variables in parallel when using caching<!--
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**:
Updates volvars in parallel fo...<!--
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**:
Updates volvars in parallel for cell-centered FV (see !3180 for box)
<!--
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/3180[box] Update grid volvars in parallel when using caching2022-07-01T07:31:17ZTimo Kochtimokoch@math.uio.no[box] Update grid volvars in parallel when using caching<!--
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**:
Update grid volvars in paralle...<!--
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**:
Update grid volvars in parallel
<!--
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.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3181[walldistance] Use generic parallelFor2022-07-01T08:58:35ZTimo Kochtimokoch@math.uio.no[walldistance] Use generic parallelForBefore this only worked for TBB, now other backends also work (e.g. OpenMP)Before this only worked for TBB, now other backends also work (e.g. OpenMP)3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3182Draft: Feature/new experimental assembly2023-12-13T10:52:22ZDennis GläserDraft: Feature/new experimental assembly<!--
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)
-->
potential steps/milestones:
- [ ] use some external lib for solution of the linear system (e.g. Eigen) -> makes sure the layout is flexible enough to make use of non-dune-solvers
- [ ] set up a toy example with time dependency to properly integrate `TimeStepper` into the new assembly layout.
- [ ] set up a toy multidomain example to ensure that support for multitypeblockvectors/matrices can be realized
- [ ] implement actual assembler and realize poisson problem
- [ ] make stationary 1p test work
- [ ] make instationary test work
- [ ] make a 2p2c test work (privarswitch should be tried to be put into `GridVariables::update()` such that newton is agnostic of that
- [ ] check that multidomain test with privar switch works with the new assembly layoutDennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3183Improve box geometry helper implementation2022-07-14T09:15:22ZTimo Kochtimokoch@math.uio.noImprove box geometry helper implementation**What this MR does / why does DuMux need it**:
Makes BoxGeometryHelper a thin wrapper around an element geometry. All points are constructed directly from the reference element via transformation given the element geometry. This means ...**What this MR does / why does DuMux need it**:
Makes BoxGeometryHelper a thin wrapper around an element geometry. All points are constructed directly from the reference element via transformation given the element geometry. This means the helper can be cheaply constructed and used to create scv and scvf geometries on-the-fly.
This should serve as a blueprint for other control volume schemes.
Exploiting this change, the memory footprint of scv and scvfs can be much improved (#1173) subsequently.
* [x] Better interface for boundary scvfs (not depending on intersection object)
**Notes for the reviewer**
I couldn't measure any performance penalty, although some points are transformed more often than before.
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] 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.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3184[geometry][cleanup] Use free reference element function2022-07-04T08:13:43ZTimo Kochtimokoch@math.uio.no[geometry][cleanup] Use free reference element function3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3185[simpleh2o] Small cleanup2022-07-06T12:02:33ZTimo Kochtimokoch@math.uio.no[simpleh2o] Small cleanupFix comment, remove unused R, write .0 for floating point numbers
Fixes #1170 (I didn't see any usage of R and it's a private variable, so I removed it)Fix comment, remove unused R, write .0 for floating point numbers
Fixes #1170 (I didn't see any usage of R and it's a private variable, so I removed it)3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3186Draft: Feature/fluxvariables flux2023-10-23T13:54:12ZTimo Kochtimokoch@math.uio.noDraft: Feature/fluxvariables flux<!--
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**
Fixes #1156
* [ ] Make interface in energylr changes backwards-comptatibleTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3187Draft: Stokes permeability upscaling in parallel2023-09-27T16:16:21ZTimo Kochtimokoch@math.uio.noDraft: Stokes permeability upscaling in parallelTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3188[cleanup][2pnc] Remove duplicate calculation of density/mole-denstiy in VolVars2022-07-12T19:25:44ZHanchuan Wu[cleanup][2pnc] Remove duplicate calculation of density/mole-denstiy in VolVars<!--
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 duplicate calculation 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**:
Remove duplicate calculation of density/mole-denstiy in 2pncVolVars
<!--
Is there a corresponding issue? Add "Fixes hashtag issuenumber" which will automatically close the issue when this MR is merged. Add "Related to hashtag issuenumber" if it's related but doesn't fix the issue completely.
-->
**Notes for the reviewer**
Fixes #1172
<!--
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.6Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3189[parallel] Add multithreaded assembly support for Mpfa and FCStaggered2022-07-10T19:50:56ZTimo Kochtimokoch@math.uio.no[parallel] Add multithreaded assembly support for Mpfa and FCStaggeredAdds multithreaded assembly support for CCMpfa and FCStaggeredAdds multithreaded assembly support for CCMpfa and FCStaggered3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3190[fix] Staggered velocity output2022-07-12T06:33:25ZMartin Schneider[fix] Staggered velocity outputIt seems that in the lambda function the wrong fvGeometry has been used. It seems that this actually doesn't make any difference in the solution because the lambda is always called with the fvGeometry passed to the `calculateVelocityForS...It seems that in the lambda function the wrong fvGeometry has been used. It seems that this actually doesn't make any difference in the solution because the lambda is always called with the fvGeometry passed to the `calculateVelocityForStaggeredGrid_`.
Maybe we could also think about deleting the fvGeometry argument when calling `getFaceVelocity`. I current don't really see why one would need a different fvGeometry.Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3191Feature/multithreaded multidomain with freeflow2022-07-12T12:52:47ZTimo Kochtimokoch@math.uio.noFeature/multithreaded multidomain with freeflow<!--
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 multithreaded assembly sup...<!--
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 multithreaded assembly support for multidomain (via traits of the coupling manager),
and uses this new support to enable multithreaded for the free flow coupling manager which assembles on one grid.
Therefore the coloring is especially easy since we just use the coloring of fcstaggered, which includes the tpfa stencil as well.
For the cell-centered block we might be able to use less colors but this is not implemented here.
This requires one change in the coupling managers: This switches from mutable class member coupling contexts to thread local singletons.
This turns the context into global variables that are unique for every thread. Both mutable and thread local are bad implementations,
and we really want to pass around the context instead. However, like this, we at least enable multithreaded assembly.
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] 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.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3192[fcstaggered] Fix remaining local assemblers (not implicit+numeric-diff)2022-07-11T18:26:11ZTimo Kochtimokoch@math.uio.no[fcstaggered] Fix remaining local assemblers (not implicit+numeric-diff)3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3193[fcstaggered] Enable parallel gridvolvar update2022-07-12T13:42:29ZTimo Kochtimokoch@math.uio.no[fcstaggered] Enable parallel gridvolvar update3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3194[bin][util] main branch can be named as main or master2022-07-13T10:01:00ZHanchuan Wu[bin][util] main branch can be named as main or masterHanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3195[ns][momentum] Only compute relevant part of gradient2022-07-27T09:21:38ZTimo Kochtimokoch@math.uio.no[ns][momentum] Only compute relevant part of gradient<!--
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**:
Only compute the needed part 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**:
Only compute the needed part of the gradient. This saves a lot of computation.3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.no