dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2022-05-10T16:41:50Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3100[benchmark][richards] Add benchmark case on annulus with analytic solution2022-05-10T16:41:50ZTimo Kochtimokoch@math.uio.no[benchmark][richards] Add benchmark case on annulus with analytic solutionConvergence rates are fine (except for sand where the analytic solution is basically a sharp corner).
Onset match with the solutions presented in the paper https://doi.org/10.3389/fpls.2020.00316 after fixing the domain size as reported ...Convergence rates are fine (except for sand where the analytic solution is basically a sharp corner).
Onset match with the solutions presented in the paper https://doi.org/10.3389/fpls.2020.00316 after fixing the domain size as reported here: https://github.com/RSA-benchmarks/collaborative-comparison/blob/master/C1%20Coupled%20problem%2C%20static%20RSA/C1.1%20Single%20root/C1.1%20Benchmark%20problem.ipynb.
There is a readme describing the cases a bit.3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2201[WIP] Feature/new staggered impl2022-05-05T10:47:41ZKilian 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/3051Draft: Feature/grid geometry observer2022-04-20T18:43:11ZDennis GläserDraft: Feature/grid geometry observerAllows observing grid geometries such that the observers can be notified in case the grid changesAllows observing grid geometries such that the observers can be notified in case the grid changesTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2687WIP: Feature/metadata extraction2022-04-01T13:18:54ZTimo Kochtimokoch@math.uio.noWIP: Feature/metadata extractionFixes #885
- [ ] Use concepts
- [ ] Think about metadata collection for parallel runsFixes #885
- [ ] Use concepts
- [ ] Think about metadata collection for parallel runs3.6https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2565Draft: [examples] Feature/pnm non creeping upscaling2022-03-30T08:46:00ZMaziar VeyskaramiDraft: [examples] Feature/pnm non creeping upscalingUpscaling non-creeping flow (#997)Upscaling non-creeping flow (#997)3.6Maziar VeyskaramiMaziar Veyskaramihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2001[WIP] Feature/python fluidsystem2022-03-28T09:40:22ZKilian 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/2496WIP: [linear] matrix converter with reordering2022-03-28T09:39:27ZTimo Kochtimokoch@math.uio.noWIP: [linear] matrix converter with reorderingWould be probably easier if the matrix converter would have a state.Would be probably easier if the matrix converter would have a state.Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/141[WIP] Velocity output for prisms2022-03-28T09:38:52ZKilian Weishaupt[WIP] Velocity output for prismsBernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2253[WIP] Feature/nonlinear schemes2022-03-28T09:36:37ZTimo Kochtimokoch@math.uio.no[WIP] Feature/nonlinear schemeshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2142WIP: Feature/freeflow outflow as neumann2022-03-28T09:32:23ZMartin 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.6Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/870[WIP] Feature/seq coupl2022-03-28T09:30:28ZKilian Weishaupt[WIP] Feature/seq couplhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2113WIP: Feature/new istl linear solvers2022-03-28T09:30:14ZTimo 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.6Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2913Draft: Feature/geometry tolerance2022-02-23T08:55:17ZDennis GläserDraft: Feature/geometry toleranceIntroduces a central place for geometry tolerance definitions.Introduces a central place for geometry tolerance definitions.3.6Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1821[WIP][md] Implement box staggered coupling2022-02-01T16:25:01ZKilian Weishaupt[WIP][md] Implement box staggered couplingTodos:
- [x] Add test for segment-segment intersection algorithm
- [x] Make segment-segment intersection algorithm more efficient
- [x] Put segment-segment in different MR
- [x] Extract Box-Forchheimer to separate MR
- [x] New BJ test ...Todos:
- [x] Add test for segment-segment intersection algorithm
- [x] Make segment-segment intersection algorithm more efficient
- [x] Put segment-segment in different MR
- [x] Extract Box-Forchheimer to separate MR
- [x] New BJ test (existing test uses indefinite perm. matrix)
- [x] Change convergence script to specify convergence rate
- [ ] It currently only works for `DiffusionCoefficientAveragingType::ffOnly`
- [ ] Maxwell Stefan Diffusion law not yet implemented when using Box
- [ ] Renaming: Use ff/pm instead of stokes/darcy
- [ ] New IC assume specific parameter group "Darcy", generalise this
- [ ] Add missing tests
Suggestions:
- [x] Currently, we retrieve the entire context via `couplingContextVector()`, but the old interface is still there. I would shrink this to only one interface and probably rename it. Currently, there is one context object per coupling segment, so maybe we can find a better name.
- [x] At the moment the coupling segment geometry is stored in both the darcy and the stokes coupling info objects in the mapper. I don't think this is the most memory consuming part of the code, but there is room for memory efficiency improvements.
Fixes #788.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2294WIP: Add Trilinos solvers2022-01-19T11:22:38ZBernd FlemischWIP: Add Trilinos solversAdd an optional dependency to Trilinos, https://github.com/trilinos/trilinos. Implement a linear solver backend that uses a solver from there.Add an optional dependency to Trilinos, https://github.com/trilinos/trilinos. Implement a linear solver backend that uses a solver from there.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2203WIP: [test] Add Karman vortex street application2021-10-19T07:59:06ZTimo Kochtimokoch@math.uio.noWIP: [test] Add Karman vortex street applicationRuns way too long to be a good test. Maybe also a good test case for solvers though. And looks fairly cool
![vortexstreet-small](/uploads/9bf4bcf66398ba24bbaccb32d17a00b2/vortexstreet-small.gif)
Update: I got a big speedup by using...Runs way too long to be a good test. Maybe also a good test case for solvers though. And looks fairly cool
![vortexstreet-small](/uploads/9bf4bcf66398ba24bbaccb32d17a00b2/vortexstreet-small.gif)
Update: I got a big speedup by using the SIMPLE-preconditioned BiCGSTABSolver of !1989 https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2628WIP [IMPES][test] Use analytical derivatives2021-05-20T17:47:37ZTimo Kochtimokoch@math.uio.noWIP [IMPES][test] Use analytical derivativesThis test results now in the same solution than the
old IMPES implementation, at least when gravity is neglected.
Related to #869This test results now in the same solution than the
old IMPES implementation, at least when gravity is neglected.
Related to #869https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2563[components] Add component SimplerH2O2021-04-20T14:56:33ZTimo Kochtimokoch@math.uio.no[components] Add component SimplerH2OFixes #1013
I hope this is consistent. Water vapor is modeled as an ideal gas. inner energy and vapor pressure are linearized around the reference state. The evaporation enthalpy should be automatically included now.
I added a new com...Fixes #1013
I hope this is consistent. Water vapor is modeled as an ideal gas. inner energy and vapor pressure are linearized around the reference state. The evaporation enthalpy should be automatically included now.
I added a new component as this implementation will probably yield different results than SimpleH2O.Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1510Feature/multidomain auto bind2021-03-25T08:50:33ZDennis GläserFeature/multidomain auto bindI posed this MR into the box-facet-coupling branch so that the diff is easier to read. If we wait for !1492, which itself has to wait for !1431, then we can merge this into master at one point.
@timok, @kweis, maybe you can have a look ...I posed this MR into the box-facet-coupling branch so that the diff is easier to read. If we wait for !1492, which itself has to wait for !1431, then we can merge this into master at one point.
@timok, @kweis, maybe you can have a look at this. If we want to keep this, we would have to:
- [x] deprecate old interfaces
- [x] change all tests where cm now receives grid variables
- [x] ~~create an issue to remove the deprecated interfaces in all __facet coupling managers__ and the __poroelasticcouplingmanager__ until version 3.2 release~~ (edit Timo: don't need an issue for that)
- [x] update reference to `test_md_facet_tracer_box` (velocity is included now, which tests the MD vel output)
- [x] Put a note in the changelog that scvfs now have to implement `neighbor()`
Fixes #619.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2126[WIP] Feature/ff stokes reverse coupling2021-03-09T12:25:16ZKilian 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 Weishaupt