dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2023-03-18T18:38:29Zhttps://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/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/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/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/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/3433Add SimpleCO2 component2023-03-16T08:41:15ZMathis KelmAdd SimpleCO2 component<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Adds a `SimpleCO2` component 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**:
Adds a `SimpleCO2` component and adjusts `BrineCO2` fluidsystem and binarycoefficients to receive a component instead of just a `CO2Table`.
Used in `example/biomineralization` instead of CO2 table.
<!--
Is there a corresponding issue? Add "Fixes hashtag issuenumber" which will automatically close the issue when this MR is merged. Add "Related to hashtag issuenumber" if it's related but doesn't fix the issue completely.
-->
Fixes #1162
- [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) 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))
<!--
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/3422Feature/generalize cvfe2023-03-14T09:34:43ZTimo Kochtimokoch@math.uio.noFeature/generalize cvfe3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3404Feature/seq stokes solver2023-02-27T23:56:34ZTimo Kochtimokoch@math.uio.noFeature/seq stokes solver* Adds a solver specialized for the Stokes problem
* Add a helper to symmetrize Dirichlet, this can be used to make sure a symmetric matrix stays symmetric. Moreover it sometimes seems to help in the solver even for slightly non-symmetri...* Adds a solver specialized for the Stokes problem
* Add a helper to symmetrize Dirichlet, this can be used to make sure a symmetric matrix stays symmetric. Moreover it sometimes seems to help in the solver even for slightly non-symmetric problems
* Test solver in the benchmark test3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3401Feature/helmholtz operator2023-02-24T08:20:38ZTimo Kochtimokoch@math.uio.noFeature/helmholtz operator* Add a Helmholtz operator assemble useful for solver testing or as a component in a preconditioner
* Add a test using the Helmholtz operator and the multi-threaded AMG smoothers (there is a nice speed-up)
The operator is based on the i...* Add a Helmholtz operator assemble useful for solver testing or as a component in a preconditioner
* Add a test using the Helmholtz operator and the multi-threaded AMG smoothers (there is a nice speed-up)
The operator is based on the initial implementation in !3240 where it was used as a Stokes solver component3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3397[preconditioners] Add three preconditioners2023-02-23T18:23:37ZTimo Kochtimokoch@math.uio.no[preconditioners] Add three preconditioners* Thread-parallel Jacobi smoother/preconditioner
* Thread-parallel SOR/SSOR with coloring
* They can be selected via the factory
* They can be used with AMG as smoother (but not unfortunately not via the factory yet)
The reason being tha...* Thread-parallel Jacobi smoother/preconditioner
* Thread-parallel SOR/SSOR with coloring
* They can be selected via the factory
* They can be used with AMG as smoother (but not unfortunately not via the factory yet)
The reason being that Dune currently hard-coded the selection of available smoothers.
We would have to write our own AMGCreator to include them. Probably better to find an
upstream solution.
The tests added for the richards test only add a few seconds in runtime because the solver factory is used anyways.
Because the grid is quite small in the test multi-threading actually makes them slightly slower. But for larger grids
there is a speedup.
Extracted from !32403.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3393[solver] Use thread parallel linear operator2023-02-23T06:57:34ZTimo Kochtimokoch@math.uio.no[solver] Use thread parallel linear operatorAdds multihreading capability to some multitype solver linear operators showing some speedup of the tests.
Header extracted from !3240Adds multihreading capability to some multitype solver linear operators showing some speedup of the tests.
Header extracted from !32403.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3386New istl linear solvers2023-03-08T07:45:40ZTimo Kochtimokoch@math.uio.noNew istl linear solversMR description (based on !2213):
* [x] Revisit template arguments
* [x] Introduce linear algebra backend or similar to make usage simpler
* [x] Adapt all linear solvers to provide `norm`
* [x] In Newton call `linearSolver->norm(r)` if a...MR description (based on !2213):
* [x] Revisit template arguments
* [x] Introduce linear algebra backend or similar to make usage simpler
* [x] Adapt all linear solvers to provide `norm`
* [x] In Newton call `linearSolver->norm(r)` if available otherwise call `assembler->residualNorm();` (depends on !2311 to be merged)
* [x] Deprecate conversion of multitype matrices in Newton (do in solver instead if necessary)
* [x] Fix parallel helper to work with UG
Depends on !3385 to be merged
The matrix and vector type now have to be known to construct the solver.
This was previously delayed until the solve call but made the structure kind of intransparent because it wasn't really clear which vector type has to come in but only specific types work anyway.
Hard coding the solver hopefully reduces compile times wrt the factory. Also the implementation should be
* more compact than the old backends
* have more runtime option due to parameter tree-based params
* work in parallel as well
* [x] ~~We could deprecated the old solver backends? (not the entire header though)~~ different MR
Updated version as replacement for !2113.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3385[assembler][pdesolver] Distinguish Resiudal and Solution types and set residu...2023-02-23T13:05:39ZTimo Kochtimokoch@math.uio.no[assembler][pdesolver] Distinguish Resiudal and Solution types and set residual to dune native type**What this MR does / why does DuMux need it**:
Various models in Dumux enable primary variable switching. This is realized by using special block types in the solution coefficient vector that specifies which variables are stored (state...**What this MR does / why does DuMux need it**:
Various models in Dumux enable primary variable switching. This is realized by using special block types in the solution coefficient vector that specifies which variables are stored (state). These custom block types are not well supported by Dune and are also not needed in linear solver and assembler. With this MR we distinguish the `SolutionVector` type and the `ResidualVector` type. Solution vectors may contain Dumux-specific custom block types whereas the `ResidualVector` type is native to the linear algebra backend (at the moment only dune-istl).
This also fixes the strange behavior that if Jacobian/Residual are scalars the solver is still fed a vector of size 1. Now the solver receives a scalar as expected (see test_newton/test_timestepmethods).
This MR will simplify the implementation of the improved solver interfaces in !2113.
**Notes for the reviewer**
The changes are not backwards-compatible.
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] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)
- [x] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [x] is the list of the header includes complete? ("include what you use")
- [x] all files have to end with a `\n` character. Make sure there is no `\ No newline at end of file` comment in "Changes" of this MR.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3376[shallowwater] Add viscous bottom shear stress Poiseuille flow test2023-02-14T09:32:58ZTimo Kochtimokoch@math.uio.no[shallowwater] Add viscous bottom shear stress Poiseuille flow test<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
This introduces a new friction...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
This introduces a new friction law for the case of very thin shallow water flows (thin film) where viscous forces are dominating.
Also adds a test case for poiseuille flow at low velocities and tiny water depth, where the walls are full-slip (tangential), no-flow (normal), and the bottom friction is that due to "parallel plate flow" (without the top plate) / plane Poiseuille flow.
**Notes for the reviewer**
TODOs
* [x] Put viscous no slip in its own header -> Viscosity needs to come from volume variables
* [x] Why is the viscosity in the viscous flux called turbulent viscosity? I guess it's the effective viscosity (including "eddy viscosity") Usually we split this into a regular viscosity part which comes from the fluid system and an effective part which would correspond to the turbulence model. This would also be helpful here.
* [x] We could add viscosity like density in the volvars (without memory overhead and requiring that it's a constant for now -> no runtime overhead).
**Checklist**
- [x] does the new code follow the [style guide](doc/styleguide.md)?
- [x] do the test pipelines pass? (see guide on [how to run pipelines for a merge request](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Running-test-pipelines-for-merge-requests))
- [x] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)
- [x] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [x] is the list of the header includes complete? ("include what you use")
- [x] all files have to end with a `\n` character. Make sure there is no `\ No newline at end of file` comment in "Changes" of this MR.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3372[spgrid] Add gridmanager.init(...) with lowerLeft/upperRight/cells2023-02-07T03:10:00ZTimo Kochtimokoch@math.uio.no[spgrid] Add gridmanager.init(...) with lowerLeft/upperRight/cellsAnalogously to YaspGrid add an interface for SPGrid to create the grid by passing parameters explicitly instead of reading them from the parameter tree.Analogously to YaspGrid add an interface for SPGrid to create the grid by passing parameters explicitly instead of reading them from the parameter tree.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3362[fmt] Update shipped version to 9.1.02023-01-25T23:38:42ZTimo Kochtimokoch@math.uio.no[fmt] Update shipped version to 9.1.03.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/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/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/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/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 Schneider