dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2021-11-01T16:54:11Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2913Draft: Feature/geometry tolerance2021-11-01T16:54:11ZDennis GläserDraft: Feature/geometry toleranceIntroduces a central place for geometry tolerance definitions.Introduces a central place for geometry tolerance definitions.3.5Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2888Draft: Feature/base spatialparams v22021-12-06T16:13:48ZDennis GläserDraft: Feature/base spatialparams v2An alternative approach to !2839.
TODO:
- [x] add new versions for geomechanics params
- [x] add new version for nonequilibrium params
- [ ] where to put gstatrandomfield? Or deprecate in favor of something like https://gitlab.dune-pro...An alternative approach to !2839.
TODO:
- [x] add new versions for geomechanics params
- [x] add new version for nonequilibrium params
- [ ] where to put gstatrandomfield? Or deprecate in favor of something like https://gitlab.dune-project.org/oklein/dune-randomfield?
- [ ] port the tests, which requires moving `temperature` and `extrusionFactor` into the spatial params (dumux day task?)
TODOS for follow-up merge requests (!!!Before merging this we should open respective issues!!!):
- [ ] use spatial params in free flow models
- [ ] move porenetwork spatial params in pore-network folder?
- [ ] move fluid property interfaces from geomechanics problem into geomech spatial params and deprecate problem
Test folder ports:
- [ ] 1p (@IvBu) !2906
- [ ] 1pnc (@RoWin)
- [ ] 1pncmin (@mathis) !2942
- [ ] richards (@bernd) !2945
- [ ] 2p (@stefaniekiemle) !2950
- [ ] 2p1c (@mathis) !2943
- [ ] mpnc (@DennisGlaeser) !2949
- [ ] 2p2c (@mathis) !2955
- [ ] 3p (@bernd) !2946
- [ ] 3p3c (@bernd) !2947 which is based on !2946
- [ ] richardsnc (@bernd) !2948 which is based on !2945
- [ ] co2 (@bernd) !2957 which is based on !2955
- [ ] tracer (@bernd) !2952 which is based on !2950
- [ ] solidenergy (@DennisGlaeser) !2951
- [ ] 2pnc (@mathis) !2956
- [ ] multidomain (@DennisGlaeser) !29603.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2734Draft: Resolve "extrusionFactor should be a spatial parameter interface"2021-08-25T14:35:17ZFelix WeinhardtDraft: Resolve "extrusionFactor should be a spatial parameter interface"Closes #1001Closes #10013.5Felix WeinhardtFelix Weinhardthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2687WIP: Feature/metadata extraction2021-10-26T17:45:37ZTimo 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.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2640WIP: [assembler] Add parallel assembly with tbb and coloring2021-10-21T14:25:34ZTimo Kochtimokoch@math.uio.noWIP: [assembler] Add parallel assembly with tbb and coloring* [x] Look at other discretization schemes (or at least disable feature for non-tpfa, non-box)
* [x] Add guards in case TBB is not available.
* [ ] Guard for gridviews which are not thread-safe.
* [x] Check caching (due to coloring this ...* [x] Look at other discretization schemes (or at least disable feature for non-tpfa, non-box)
* [x] Add guards in case TBB is not available.
* [ ] Guard for gridviews which are not thread-safe.
* [x] Check caching (due to coloring this should also work with caching)
* [x] Option to set number of available threads at runtime
Check efficiency of coloring scheme (efficiency doesn't matter much for instationary simulations).
The constraint behind the coloring should be: Two elements that modify the same entries of the matrix or the cache or any other global object shouldn't have the same color. In the graph coloring sense: Two elements (two nodes) that do modify the same entries are connected by an edge.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/2565[examples] Feature/pnm non creeping upscaling2021-10-27T13:04:44ZMaziar Veyskarami[examples] Feature/pnm non creeping upscalingUpscaling non-creeping flow (#997)Upscaling non-creeping flow (#997)3.5Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://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.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2496WIP: [linear] matrix converter with reordering2021-03-24T16:14:17ZTimo 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.3.5Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2294WIP: Add Trilinos solvers2021-06-01T20:18:13ZBernd 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/2276WIP: [test][1p] Add 3d convergence test2020-10-07T09:26:12ZTimo Kochtimokoch@math.uio.noWIP: [test][1p] Add 3d convergence testAdds a 2d test on a sphere tet grid (`sphere.msh`). I also committed a `sphere_quad.msh` grid which has some nasty distorted quad elements.
Unfortunately I currently get for both grids:
```
Dune::InvalidStateException [decompose:/Users...Adds a 2d test on a sphere tet grid (`sphere.msh`). I also committed a `sphere_quad.msh` grid which has some nasty distorted quad elements.
Unfortunately I currently get for both grids:
```
Dune::InvalidStateException [decompose:/Users/pumbaa/dune-master/dumux/dumux/discretization/cellcentered/wmpfa/facedatahandle.hh:101]: CoNormal decomposition not found
```
although the tet version of the grid looks fairly nice.
I wanted to use this test to check if it works in 3D.
For now it's only Dirichlet but it should be relatively easy to try Neumann boundaries.Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2253[WIP] Feature/nonlinear schemes2021-03-25T08:51:11ZTimo Kochtimokoch@math.uio.no[WIP] Feature/nonlinear schemes3.5https://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/2201[WIP] Feature/new staggered impl2021-10-19T13:08:24ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[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 #7563.5Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2142WIP: Feature/freeflow outflow as neumann2021-03-25T08:51:25ZMartin 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.5Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2130WIP Feature/finite element method2020-10-16T08:57:48ZDennis 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 ...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 coupling2021-03-09T12:25:16ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[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@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2113WIP: Feature/new istl linear solvers2021-07-16T13:11:46ZTimo 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.5Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2012[WIP] TEMP: first draft of new staggered fvgridgeometry2020-06-26T06:43:45ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[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 scvfs
This 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
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2001[WIP] Feature/python fluidsystem2021-07-19T06:31:44ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[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.3.5Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de