dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2023-12-13T10:52:21Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2201[WIP] Feature/new staggered impl2023-12-13T10:52:21ZKilian Weishaupt[WIP] Feature/new staggered impl__TODO__
_General:_
- [ ] Fix docu (especially copy and paste errors)
- [ ] Rethink assembly strategy (forward / inverse)?
- [x] Introduce coupling stencils per DOF?
- [x] improve design of "dual" problem
- [x] boundary flux helpers
- [ ...__TODO__
_General:_
- [ ] Fix docu (especially copy and paste errors)
- [ ] Rethink assembly strategy (forward / inverse)?
- [x] Introduce coupling stencils per DOF?
- [x] improve design of "dual" problem
- [x] boundary flux helpers
- [ ] prohibit Dirichlet for mass model?
- [x] check difference in Jacobian for compressible fluids (channel)
- [x] periodic grids
- [ ] Look into benefits of caching options
- [ ] Add volume work to energy balance
@nedc:
- [x] Set up higher order geometry
- [x] Port the TVD methods
- [x] Add correct checks for various boundary conditions
- [x] Add useful tests for higher order
- [ ] Update and include the rans models
@kweis:
- [x] coupling (staggered-cellcentered)
- [x] implement Beavers-Joseph BC
- [x] Compositional models (1pnc)
@martins
- [ ] Finalize box-staggered coupling (old staggered)
- [ ] Port box-staggered to new staggered
- [ ] Develop new freeflow discretizations (long term)
@hanchuan
- [x] port and test Navier stokes tests (should have been completed already by @kweis)
- [x] port compositional tests (after 1pnc is updated)
- [ ] port stokes-darcy MD tests (after MD is updated)
- [ ] port rans tests (after rans is updated)
fixes #756Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2186[newton] Extract privarswitch implementation to separate class2020-06-19T17:57:39ZTimo Kochtimokoch@math.uio.no[newton] Extract privarswitch implementation to separate class3.3Dennis GläserDennis Gläserhttps://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/2130WIP Feature/finite element method2023-12-13T10:52:17ZDennis GläserWIP Feature/finite element methodThis is a first draft of an FEM framework. Currently, major limitations/assumptions are:
* assumes Standard-Galerkin approach
* assumes non-composite dune function space bases
I have tried to incorporate suggestions stemming from the d...This is a first draft of an FEM framework. Currently, major limitations/assumptions are:
* assumes Standard-Galerkin approach
* assumes non-composite dune function space bases
I have tried to incorporate suggestions stemming from the discussion in #884, in particular it is:
1. The state of the grid variables was always dependent on the problem (e.g. due to BCs) and a current solution. Nevertheless, we had grid variables and problem and cursol as arguments in several assembly-related functions. In particular, we did `assembler.assemble(curSol)`. The assembler introduced here fulfills this interface (for compatibility with NewtonSolver), but does not use curSol. Instead, the assembler is instantiated with grid variables, which are updated with a solution and a problem. Thus, the assembler takes the solution and problem from the grid variables. So, you would want to do `Assembler assembler(gridVariables); assembler.assemble()`. This could help implementing other time stepping schemes, where you create grid variables on different time levels (stages), make an assembler from them and let it assemble the stage. The assembler is basically a copy of `FVAssembler`, which was almost general and non fv-specific. There is one piece of commented code related to parallelism with box (with a todo in the comment) which has to be figured out still.
2. Local assemblers are now a `localView` of the assembler, no which you then call `bind` with only an element. The problem & current solution are extracted from the grid variables with which the assembler was instantiated. This guarantees that a wrong combination of _problem state_, _solution state_ and _grid variables state_ is passed to it.
3. None of the classes use the property system anymore. I wrote a little test solving a poisson equation, which completely works without the property system. See test/discretization/fem/poisson. Therein, a problem and local residual have to be implemented. Currently, I implemented it in a "Dumux conforming" way, also implementing a spatial parameters class that stores the tensor and an "IntegrationPointVariables" class (the equivalent of vol vars in fv schemes), which hold the tensor at an integration point. The test implementation could be simplified very much if the custom local residual simply called `problem.getTensor()` or so - that would get rid of the spatial params and the integration point variables implementations. I did it this way for now to illustrate the complete workflow for implementing a new model and test.
All of this is subject to discussion, and all new headers have "TODOs" all over the place which can be discussed.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2126[WIP] Feature/ff stokes reverse coupling2023-12-13T10:52:17ZKilian Weishaupt[WIP] Feature/ff stokes reverse coupling__TODO__
- [x] make backwards compatible
- [ ] fix failing tests
- [ ] implement for compositional, compressible flow
depends on !2128 !2133__TODO__
- [x] make backwards compatible
- [ ] fix failing tests
- [ ] implement for compositional, compressible flow
depends on !2128 !2133Kilian WeishauptKilian Weishaupthttps://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/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/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 scvfshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2001[WIP] Feature/python fluidsystem2023-12-13T10:52:21ZKilian Weishaupt[WIP] Feature/python fluidsystemThis is only a proof of concept.
We should decide what types of fluidsystems we want (e.g, 2pnc).
Probably, it also makes sense to create python components.This is only a proof of concept.
We should decide what types of fluidsystems we want (e.g, 2pnc).
Probably, it also makes sense to create python components.Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1841WIP: Feature/test richards istl factory2020-01-29T12:37:41ZTimo Kochtimokoch@math.uio.noWIP: Feature/test richards istl factoryDepends on !1839.
Compiles and test passes for sequential and parallel richards testsDepends on !1839.
Compiles and test passes for sequential and parallel richards tests3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1840WIP: [test][params] Add unit test for translating solver parameters to dune-i...2020-03-11T15:48:59ZTimo Kochtimokoch@math.uio.noWIP: [test][params] Add unit test for translating solver parameters to dune-istl format* [ ] If this works extract the extractAndTranslate function to `parameters.hh`.
* [ ] Get rid of C++17 (if we don't allow it until this is merged)* [ ] If this works extract the extractAndTranslate function to `parameters.hh`.
* [ ] Get rid of C++17 (if we don't allow it until this is merged)3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1839Added first version of generic factory using istl solver factory.2020-01-29T18:50:49ZMarkus BlattAdded first version of generic factory using istl solver factory.*Adds a generic backend that is configurable via parameters:
~~**This is still work in progress and not fully tested, yet. Compiles, did not test running yet.**~~
*Based on [MR 349 in dune-istl](https://gitlab.dune-project.org/core...*Adds a generic backend that is configurable via parameters:
~~**This is still work in progress and not fully tested, yet. Compiles, did not test running yet.**~~
*Based on [MR 349 in dune-istl](https://gitlab.dune-project.org/core/dune-istl/merge_requests/349)
Configuration parameters (Dumux style are)
- `Verbosity`
- `MaxIterations`
- `ResidualReduction`
- `Type`
- `Restart`
- `MaxOrthogonalizationVectors`
- `PreconditionerVerbosity`
- `PreconditionerType`
- `PreconditionerIterations`
- `PreconditionerRelaxation`
- `ILUOrder`
- `ILUResort`
- `AmgSmootherRelaxation`
- `AmgSmootherIterations`
- `AmgMaxLevel`
- `AmgCoarsenTarget`
- `AmgProlongationDampingFactor`
- `AmgAlpha`
- `AmgBetaAmgAdditive`
- `AmgGamma`
- `AmgPreSmoothingSteps`
- `AmgPostSmoothingSteps`
- `AmgCriterionSymmetric`
- `AmgStrengthMeasure`
- `AmgDiagonalRowIndex`
Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1817Feature/test rotationsymmetry2020-04-23T10:48:58ZMartin SchneiderFeature/test rotationsymmetryFixes #787 Fixes #787 3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1719[WIP] Improve stokes darcy coupling2020-05-11T07:53:50ZKilian Weishaupt[WIP] Improve stokes darcy couplingFor testing, might not be merged.
__Problems__:
* how to make backwards-compatible?
* solution-dependent Dirichlet?
* Neumann-Neumann / Dirichlet-Dirichlet coupling does not yield the same resultsFor testing, might not be merged.
__Problems__:
* how to make backwards-compatible?
* solution-dependent Dirichlet?
* Neumann-Neumann / Dirichlet-Dirichlet coupling does not yield the same resultsKilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1699[WIP] Feature/freeflow periodic bc2020-09-29T07:34:41ZKilian Weishaupt[WIP] Feature/freeflow periodic bccloses #756closes #7563.3Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1661Feature/output vtk path from inputfile2019-08-07T09:34:47ZTimo Kochtimokoch@math.uio.noFeature/output vtk path from inputfile<!--
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**:
This adds a path prefix to the name given to the output modu...<!--
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**:
This adds a path prefix to the name given to the output module. This way the vtk output files can be written to a different folder.
<!--
**Which issue this MR fixes** *(optional - uncomment and add issue)*:
fixes #
-->
**Special notes for your reviewer**:
The argument `path` of the `Dune::VTKSequenceWriter` only changes the path of the vtu files, not the pvd, so it doesn't give the desired effect.3.1Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1648WIP: Feature/simplify effectivelaws - Do not merge!2019-08-05T18:27:27ZGabi SeitzWIP: Feature/simplify effectivelaws - Do not merge!Fixes #711
Fixes #710
Fixes #733
* [x] Depends on a fix in MPFA to handle zero coefficients.
This MR is outdated and superseded by !1684
Fixes #711
Fixes #710
Fixes #733
* [x] Depends on a fix in MPFA to handle zero coefficients.
This MR is outdated and superseded by !1684
3.1Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1532WIP: Variable precision for container IO interface2019-04-05T15:10:38ZTimo Kochtimokoch@math.uio.noWIP: Variable precision for container IO interface3.1Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.no