dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2020-10-29T22:53:51Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2175WIP: Coupling concepts 1d3d2020-10-29T22:53:51ZTimo Kochtimokoch@math.uio.noWIP: Coupling concepts 1d3dThis has to be split up in separate MRs.
* [x] intersecting entities cartesian grid -> !2176
* [x] Block-diagonal ILU0 GMres solver -> !2177
* [x] Optimized circle points -> !2178
* [x] Cylinder integration -> !2180 (contains some in...This has to be split up in separate MRs.
* [x] intersecting entities cartesian grid -> !2176
* [x] Block-diagonal ILU0 GMres solver -> !2177
* [x] Optimized circle points -> !2178
* [x] Cylinder integration -> !2180 (contains some interface changes wrt this branch)
* [x] Several smaller cleanups and improvements in the 1d3d coupling manager !2184 (use GridIndex, optimise point source data performance by not using maps, optimise integration point source by only storing a single element index, add possibility to distribute integration point source with box trial functions, rename fvGridGeometry -> gridGeometry)
* [x] polyline debug output helper !2191
* [x] Geometry distance helpers !2192
* [x] Implement internal Dirichlet constraints !2202
* [x] Add changes in coupling manager in some wayhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2173WIP: Coupling concepts 1d3d (old)2020-10-29T22:54:07ZTimo Kochtimokoch@math.uio.noWIP: Coupling concepts 1d3d (old)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2161[cleanup] Use find PTScotch from Dune2020-06-01T11:04:48ZTimo Kochtimokoch@math.uio.no[cleanup] Use find PTScotch from Dune@gruenich We don't need this here, right? And it might even overwrite the stuff that Dune found!?@gruenich We don't need this here, right? And it might even overwrite the stuff that Dune found!?3.3Christoph GrüningerChristoph Grüningerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2152WIP add default fluxcache properties2020-05-28T07:23:43ZBernd FlemischWIP add default fluxcache propertiesFixes #867.Fixes #867.3.3Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2149WIP: Resolve "Translate shell scripts to Python"2020-05-27T13:55:05ZFarid MohammadiWIP: Resolve "Translate shell scripts to Python"Closes #883Closes #883https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2146WIP: [box] Update all element volume variables when deflecting solution2022-02-23T17:26:19ZTimo Kochtimokoch@math.uio.noWIP: [box] Update all element volume variables when deflecting solutionFixes #892Fixes #892https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2142WIP: Feature/freeflow outflow as neumann2022-09-01T07:09:15ZMartin SchneiderWIP: Feature/freeflow outflow as neumannInstead of outflow conditions we want to use Neumann conditions with convenience outflow functions provided in some fluxhelper class.
ToDos
- [x] Check turbulence models
- [ ] Check coupled models
- [ ] Deprecate outflow conditions
- [ ...Instead of outflow conditions we want to use Neumann conditions with convenience outflow functions provided in some fluxhelper class.
ToDos
- [x] Check turbulence models
- [ ] Check coupled models
- [ ] Deprecate outflow conditions
- [ ] Fix failing tests
- [ ] Documentation of helper classes3.7https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2137WIP: [newton] Generalize Newton implementation for different solution types2021-03-24T16:18:08ZTimo Kochtimokoch@math.uio.noWIP: [newton] Generalize Newton implementation for different solution types* [x] Extract Privarswitch logic/implementation into separate class
* [ ] Extract partial reassembler logic into seperate class
* [ ] Provide external helpers for relative shift* [x] Extract Privarswitch logic/implementation into separate class
* [ ] Extract partial reassembler logic into seperate class
* [ ] Provide external helpers for relative shifthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2135WIP: [freeflow] Improve parallel velocities for stair-like boundaries2020-05-29T17:05:15ZMelanie LippWIP: [freeflow] Improve parallel velocities for stair-like boundaries<!--
Thanks for sending a merge request!
If this is your first time, read our [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Fixes #888.
![parallelVelocities](/uploads/7530b446...<!--
Thanks for sending a merge request!
If this is your first time, read our [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Fixes #888.
![parallelVelocities](/uploads/7530b446fb69bcd1bb49c05d44ef0a2f/parallelVelocities.png)
**Special notes for your reviewer**:
Please only keep the second commit and omit all the temporary ones (MR set to WIP as long as temporary commits are in there). The temporary commits are meant to make review easier. In the following there is also the numbered grid for the kovasnay test which lets one compare the parallel indices.
![kovasnay_net](/uploads/ee2e598c546c68ad533e1b77f8cee383/kovasnay_net.png)
Do you see any nice way to get an implementation for higher order without passing the curSol all the way down to staggeredupwindfluxvariables?3.3Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2134WIP Feature/timestepper test2021-03-25T09:14:10ZDennis GläserWIP Feature/timestepper testMany todos...
One of them:
- [ ] rethink commit providing access to assembler/linear solver in PDESolver
Furthermore, I guess we have to rethink our plan to not provide the current solution to the PDESolver/assembler - as a reminder: t...Many todos...
One of them:
- [ ] rethink commit providing access to assembler/linear solver in PDESolver
Furthermore, I guess we have to rethink our plan to not provide the current solution to the PDESolver/assembler - as a reminder: the motivation was to avoid multiple calls to gridVars.init() or update() in case users have instantiated grid vars before assembly. What we also wanted to achieve is that, when a user creates grid vars and a solution in the main file, after the time integration procedure we said we'd like both the solution and the grid variables to be on the state after time integration withouth the user having to do anything.
The problem is - I changed the (grid)variables concept such that they store a pointer to the solution with which they were updated. However, if we change that pointer in update() which is, for instance, called from the NewtonSolver after an iteration, this changes the pointer in the grid variables of the user as the user grid vars are used in the last stage of time integration such that everything is written into them. Now it works because the time stepper receives a user solution vector (in which to store the solution), which is the one stored in the user grid variables, and which is forwarded to the PDESolver. So the whole chain uses that solution vector. But, I guess we have to think more about this as this is error-prone. If the user provides another solution vector to store the result in then the grid variables won't be up to date after time integration. This issue is a general one in our current assembly concept (as we discussed).
W.r.t. time integration: what we could do is to always use temporary grid variables for all stages (also the last) and copy the last grid variables into the user grid vars. But, as the solution vector that created the object is a temporary, the pointer would lose validity - this could only be fixed using shared_ptr everywhere... But maybe we find a better way.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2120WIP: Feature/add turbulent diffusion to shallow water model2020-09-16T13:01:04ZFrank PlatzekWIP: Feature/add turbulent diffusion to shallow water model<!--
Thanks for sending a merge request!
If this is your first time, read our [contributing guidelines](/CONTRIBUTING.md)
-->
**Adding (turbulent) diffusion to the shallow water model (part of freeflow)**:
For now using constant eddy-...<!--
Thanks for sending a merge request!
If this is your first time, read our [contributing guidelines](/CONTRIBUTING.md)
-->
**Adding (turbulent) diffusion to the shallow water model (part of freeflow)**:
For now using constant eddy-viscosity. Turbulence models will be added in separate issues. The implementation also contains 2 wall shear stress implementations:
1. no-slip implementation
2. law-of-the-wall implementation
One test has been added: Poiseuille flow test: for flow in a channel with rough side walls.
This test has an analytical solution.
**Which issue this MR fixes**:
#706
**Special notes for your reviewer**:
N/Ahttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2113WIP: Feature/new istl linear solvers2023-02-22T11:59:20ZTimo Kochtimokoch@math.uio.noWIP: Feature/new istl linear solvers* [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...* [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)
Depends on !2310 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
If this works out, we would deprecated the old solver backends.3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2095[fix] change maxRelativeNewtonShift to a stricter criterion to make solution ...2020-04-29T16:16:35ZKatharina Heck[fix] change maxRelativeNewtonShift to a stricter criterion to make solution more stableWith this change the test passes me. Before the pressure solution varied by 1.2 percent.With this change the test passes me. Before the pressure solution varied by 1.2 percent.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2058[WIP] Cleanup/matrixconverter2020-04-27T13:40:31ZKilian Weishaupt[WIP] Cleanup/matrixconverterCannot be backported to 3.2Cannot be backported to 3.23.3Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2057Merge branch 'fix/clone-opm-release-branches' into 'master'2020-04-27T09:35:14ZTimo Kochtimokoch@math.uio.noMerge branch 'fix/clone-opm-release-branches' into 'master'First merge !2056
[bin] clone OPM release branches
See merge request dumux-repositories/dumux!2050
(cherry picked from commit 9cd965f51980ea6aa99a03427618820bd41588c9)
4db9a880 [bin] clone OPM release branchesFirst merge !2056
[bin] clone OPM release branches
See merge request dumux-repositories/dumux!2050
(cherry picked from commit 9cd965f51980ea6aa99a03427618820bd41588c9)
4db9a880 [bin] clone OPM release branches3.2Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2056Merge branch 'fix/test-2p-cornerpoint' into 'master'2020-04-27T09:35:07ZTimo Kochtimokoch@math.uio.noMerge branch 'fix/test-2p-cornerpoint' into 'master'[test][cornerpoint] Add -fopenmp to link options.
See merge request dumux-repositories/dumux!2055
(cherry picked from commit 43d33f47e359a00691a7db5e5c710482ce5adc86)
25ca8b00 [test][cornerpoint] Add -fopenmp to link options.[test][cornerpoint] Add -fopenmp to link options.
See merge request dumux-repositories/dumux!2055
(cherry picked from commit 43d33f47e359a00691a7db5e5c710482ce5adc86)
25ca8b00 [test][cornerpoint] Add -fopenmp to link options.3.2Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2046[WIP] [common] Add function rows(multiTypeBlockMatrix)2020-04-29T07:49:06ZKilian Weishaupt[WIP] [common] Add function rows(multiTypeBlockMatrix)fixes #872 fixes #872 3.3Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2043WIP:Backport/update 2pfracturetests2020-04-28T14:08:50ZNed ColtmanWIP:Backport/update 2pfracturetestsadds !2042 to releases/3.2
fixes #863 adds !2042 to releases/3.2
fixes #863 3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2032Merge branch 'feature/biomin_example' into 'master'2020-04-22T16:48:23ZTimo Kochtimokoch@math.uio.noMerge branch 'feature/biomin_example' into 'master'Feature/biomin example
See merge request dumux-repositories/dumux!1784
(cherry picked from commit b27b2a2fc9edcefada532e5738f4500f37cdeef0)
d90afc08 [examples][biomin] added new biomineralization exampleFeature/biomin example
See merge request dumux-repositories/dumux!1784
(cherry picked from commit b27b2a2fc9edcefada532e5738f4500f37cdeef0)
d90afc08 [examples][biomin] added new biomineralization example3.2Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2012[WIP] TEMP: first draft of new staggered fvgridgeometry2023-02-19T23:24:45ZKilian Weishaupt[WIP] TEMP: first draft of new staggered fvgridgeometryThis is a first prototype for a "real" staggered fvGeometry.
Results of discussion so far:
* staggered fvGeometry contains 4 (2D quad cells) scvs and 12 scvfsThis is a first prototype for a "real" staggered fvGeometry.
Results of discussion so far:
* staggered fvGeometry contains 4 (2D quad cells) scvs and 12 scvfs