dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2021-03-25T08:51:03Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/141[WIP] Feature/velocity output cc2021-03-25T08:51:03ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[WIP] Feature/velocity output cc3.5Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/870[WIP] Feature/seq coupl2021-03-25T08:51:54ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[WIP] Feature/seq coupl3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1248[WIP] Feature/improve rans2021-11-12T10:41:37ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[WIP] Feature/improve rans3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1703WIP Feature/multidomain analytic jac2021-03-25T08:51:15ZTimo Kochtimokoch@math.uio.noWIP Feature/multidomain analytic jac3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1716WIP: Feature/explicit flashs of implicit models2021-03-25T08:51:07ZBeatrix BeckerWIP: Feature/explicit flashs of implicit models**What this MR does / why does DuMux need it**:
Introduces a 2p2c-specific constraint solver, that explicitly calculates mass fractions for two-phase state, assuming ideal mixtures (as does the generic mpnc constraint solver for two-phas...**What this MR does / why does DuMux need it**:
Introduces a 2p2c-specific constraint solver, that explicitly calculates mass fractions for two-phase state, assuming ideal mixtures (as does the generic mpnc constraint solver for two-phase state).
Changes in volumevariables: The new constraint solver is used for two-phase state. In the one-phase state the `ComputeFromReferencePhase` solver is used, since it does the simplest thing possible for ideal mixtures.
`useConstraintSolver` is deleted because it's not needed anymore.
Resolves #761
**Special notes for your reviewer**:
Is it okay to have a new header for the 2p2c-specific constraint solver or should I integrate it as a special case in the generic one? I guess this is not backward compatible (deleted `useConstraintSolver`)? Do I have to deprecate the entire old volumevariables? @holle : The 2p2c tests parse with the new constraint solver (they did so before with the old, in my opinion slightly less correct/buggy version, too, although that was never tested...). Does it look good to you, too?3.5Holger ClassHolger Classhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1781WIP: Feature/create co2 tables2021-11-29T16:34:03ZMartin UtzWIP: Feature/create co2 tablesclose #690
The CO2 tables are created by the help of a website (https://webbook.nist.gov/chemistry/fluid), which can calculate the needed values. The query for these is automated by a python script, which also does the formatting of th...close #690
The CO2 tables are created by the help of a website (https://webbook.nist.gov/chemistry/fluid), which can calculate the needed values. The query for these is automated by a python script, which also does the formatting of the received values.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1950WIP: Block-diagonal AMG in parallel2021-03-25T08:52:30ZBernd FlemischWIP: Block-diagonal AMG in parallelMake the `BlockDiagAMGBiCGSTABSolver` work in parallel.
On the user side, this requires passing argument and template tuples. For the currently working test in `multidomain/poroelastic/el1p`, this amounts to
```cpp
using GridGeometr...Make the `BlockDiagAMGBiCGSTABSolver` work in parallel.
On the user side, this requires passing argument and template tuples. For the currently working test in `multidomain/poroelastic/el1p`, this amounts to
```cpp
using GridGeometries = std::tuple<OnePFVGridGeometry, PoroMechFVGridGeometry>;
using LinearSolver = BlockDiagAMGBiCGSTABSolver<GridGeometries>;
auto views = std::make_tuple(std::cref(leafGridView), std::cref(leafGridView));
auto mappers = std::make_tuple(onePFvGridGeometry->dofMapper(), poroMechFvGridGeometry->dofMapper());
auto groups = std::make_tuple(std::string("OneP"), std::string("PoroElastic"));
auto linearSolver = std::make_shared<LinearSolver>(views, mappers, groups);
```
So far, only `YaspGrid` works.
1. [x] Make it work for [dumux-sediment](https://git.iws.uni-stuttgart.de/dumux-appl/dumux-sediment).
2. [x] Make it work for `UGGrid` and `ALUGrid`.
3. [x] Decide where to put what.3.5Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1975WIP: [io][gridmanagerbase] Fix dune deprecation warning2021-03-25T08:51:20ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deWIP: [io][gridmanagerbase] Fix dune deprecation warningfixes #859
Should probably be backported to 3.2fixes #859
Should probably be backported to 3.23.5Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://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.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/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/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/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/2433WIP: Feature/new staggered higher order2021-06-15T13:51:56ZNed ColtmanWIP: Feature/new staggered higher ordertodos:
- [x] Sincos higher order test stationary (pass)
- [x] Sincos higher order test instationary (fail)
- [x] 3D Channel higher order test (pass)
- [x] Kovaznay higher order test stationary (fail)
- [ ] Find errors that would cause ba...todos:
- [x] Sincos higher order test stationary (pass)
- [x] Sincos higher order test instationary (fail)
- [x] 3D Channel higher order test (pass)
- [x] Kovaznay higher order test stationary (fail)
- [ ] Find errors that would cause bad convergence and solution differences3.5Ned ColtmanNed Coltmanhttps://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/2561WIP: analytical case for K-Omega2021-04-20T09:31:34ZNed ColtmanWIP: analytical case for K-Omega**What this MR does / why does DuMux need it**:
- Implements an analytical case for two-eq turbulence models from pre dumux 3.0
**Special notes for your reviewer**:
- Currently no convergence, for future comparison with new staggered im...**What this MR does / why does DuMux need it**:
- Implements an analytical case for two-eq turbulence models from pre dumux 3.0
**Special notes for your reviewer**:
- Currently no convergence, for future comparison with new staggered implementations3.5Ned ColtmanNed Coltmanhttps://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/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/2730Draft: Advection Diffusion Model2021-09-16T15:16:28ZNed ColtmanDraft: Advection Diffusion ModelI'm not sure if this is something we would really want, but I set it up for a different module and mentioned this in issue #1001.
This is the same as the tracer1p model with a stationary velocity field, but it does not assume that the ...I'm not sure if this is something we would really want, but I set it up for a different module and mentioned this in issue #1001.
This is the same as the tracer1p model with a stationary velocity field, but it does not assume that the domain is a porous medium. It should solve the transport equation decoupled from any momentum balance.
The test calculates a velocity field, passes this to a spatialParams, then calculates transport on the same domain with a fixed velocity field. To make it interesting, it's a rectangular domain with a circle cut out of the center.
This should produce the same result as the tracer1p model with the same velocity field and a porosity of 1.
If this is something we do want to include, It would likely benefit from a bit of refactoring.3.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 Weinhardt