dumux-repositories issueshttps://git.iws.uni-stuttgart.de/groups/dumux-repositories/-/issues2021-05-06T08:56:37Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1024Richards test do not converge2021-05-06T08:56:37ZDennis GläserRichards test do not convergeIt seems that after !2574, some richards tests don't converge anymore, causing all pipelines to fail: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/pipelines/3789
I only checked one output log and saw that `test_richards_b...It seems that after !2574, some richards tests don't converge anymore, causing all pipelines to fail: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/pipelines/3789
I only checked one output log and saw that `test_richards_benchmark_infiltration_tpfa` fails due to timeout with poor newton convergence. There may be more tests affected.
In the MR I see that at the latest stage at least, there was no pipeline triggered. Did you test locally before merge @heck, @timok ?3.4https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/955Backport !2139 (RANS density) to 3.22020-10-31T09:57:01ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deBackport !2139 (RANS density) to 3.2!2139 could not be cherry-picked automatically. You need to do it by hand.!2139 could not be cherry-picked automatically. You need to do it by hand.Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/940Clean incoporation of new time integration methods2021-03-25T09:23:04ZDennis GläserClean incoporation of new time integration methods@timok, @bernd, @kweis, @martins and I are currently discussing/developing the incorporation of a generic time integration framework in Dumux. In general, time handling is currently problematic in Dumux and leads to a bug in MultiDomain ...@timok, @bernd, @kweis, @martins and I are currently discussing/developing the incorporation of a generic time integration framework in Dumux. In general, time handling is currently problematic in Dumux and leads to a bug in MultiDomain (#792, #619).
The following work plan is currently envisioned to incorporate the features into an `Experimental` namespace while guaranteeing that the current features and tests on master still work:
1. [x] introduce new grid variables concept, where they represent the complete state of a simulation - thus, not only secondary but also primary variables and possibly a time level. (see !2285)
2. introduce new assembly concept <br>
- [x] make `NewtonSolver`, `PDESolver` accept both assemblers that assemble around given `SolutionVectors` or more generic `Variables` (see !2291) <br>
- [x] add time step methods (see !2296)<br>
- [ ] add generic version of `FVAssembler`, which assembles around `Variables` and uses the time integration methods (see !2519)<br>
- [ ] Introduce solution state (name is to be discussed) class that substitutes elementSolution during the assembly - that is, as argument to volume variables updates and in spatial parameters interfaces. The concept of this state class is to carry time information in addition to the element solution, that can be used within user interfaces. (!2520)
- [ ] Introduce context class, that wraps the local views after bind in order to pass that into the user interfaces. That reduces the number of arguments in a bunch of interfaces, and moreover, we usually have interfaces like `function(element, fvGeometry, elemVolVars,...)`, but `fvGeometry` makes little sense if not bound to `element` anyway and it also carries the bound element. With the same argument `elemVolVars` are basically unusable if you don't have the `scvs` at hand to access the corresponding volume variables. So in all those interfaces it makes sense to group the arguments. This is also introduced together with the solution state in !2520
- [ ] Extend problem/parameter/volvars interfaces to make it possible to inject some container with additionally required data, which in `MultiDomain` could be used to pass the coupling data. This is probably a lot of work and requires some thought regarding compatibility.<br>
- [ ] port the above concepts to `MultiDomain` (first goal: make `test_el2p` work, fixing the main bug)
Edit 25.03: We may postpone the introduction of the additional container to hold the coupling context for now and first realize multidomain in the new experimental framework but still with the context stored centrally in `CouplingManager` (an outdated but working draft is in !2448). This way, we can still reuse most interfaces in non-experimental namespace. Afterwards, we could address the issue of the central context separately, which would probably involve quite some interface changes... With either approach, the bug of non-converging Newton solver for poromechanics is addressed. Getting the context out of `CouplingManager` would additionally address thread safety in thread-parallel runs.
Problems that might need to be solved:
- The `assemble()` functions in the assembler now receive non-const GridVariables (introduced in 3d7068043ddb1cc7249aa0cd7d95ffa077733524). That was necessary because in the case of global caching we actually deflect the variables that come in. We should maybe think of a concept to circumvent this, and adapt !2519 accordingly.
Intermediate solutions/developments or related stuff, which should be deleted in case we favour the propositions above:
!2297, !2448, !2476, !2498, !2134, !2281, `feature/timestepmethods (now deleted)`
Things that should be revisited and adapted once this is ready:
!2130Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/844Wrong dkrn_dswe analytical derivative in Brooks-Corey and Van Genuchten2020-03-31T08:02:07ZTheresa SchollenbergerWrong dkrn_dswe analytical derivative in Brooks-Corey and Van GenuchtenThe implementation of the analytical derivative dkrn_dswe in the Brooks-Corey law is not correct. This is also shown by a comparison with the numerical derivative.
Implemented derivative: $`\frac{d krn}{d swe} = 2 (swe -1) (1+\frac{1}{\...The implementation of the analytical derivative dkrn_dswe in the Brooks-Corey law is not correct. This is also shown by a comparison with the numerical derivative.
Implemented derivative: $`\frac{d krn}{d swe} = 2 (swe -1) (1+\frac{1}{\lambda} \cdot swe^{\frac{2}{\lambda}} + \frac{1}{2} - (\frac{1}{2}+\frac{1}{\lambda}) \cdot swe)`$
Correct derivative: $`\frac{d krn}{d swe} = 2 (swe -1) (1+(\frac{1}{2} + \frac{1}{\lambda}) \cdot swe^{\frac{2}{\lambda}} - (\frac{3}{2}+\frac{1}{\lambda}) \cdot swe^{\frac{2}{\lambda}+1})`$
![dkrndSw](/uploads/6ae2e8e4116184f902d7d0a1a61858eb/dkrndSw.png)
Additionaly there is also an error in the analytical derivative dkrn_dswe in the Van Genuchten law.
Implemented derivative: $`\frac{d krn}{d swe} = -(1-swe)^{\gamma-1}\cdot(1-swe^{\frac{1}{m}})^{2m-1}\cdot (\gamma(1-swe^{\frac{1}{m}}) - 2\frac{1-swe}{swe} swe^{\frac{1}{m}})`$
Correct derivative: $`\frac{d krn}{d swe} = -(1-swe)^{\gamma-1}\cdot(1-swe^{\frac{1}{m}})^{2m-1}\cdot (\gamma(1-swe^{\frac{1}{m}}) \color{red}+ \color{black} 2\frac{1-swe}{swe} swe^{\frac{1}{m}})`$
![dkrndSw_vanGenuchten](/uploads/a5a6da85cf8b39c6d2c0aed9587edd3b/dkrndSw_vanGenuchten.png)3.2Theresa SchollenbergerTheresa Schollenbergerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/662Wrong use of extrusion factors (freeflow)2019-02-27T09:56:07ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deWrong use of extrusion factors (freeflow)At certain points, the use of the extrusion factor is implemented wrong:
* fluxoversurface.hh lacks the factor for the calculation of the volume fluxes
* stokesdarcy/couplingdata.hh includes the factor in the calculation of diffusive fl...At certain points, the use of the extrusion factor is implemented wrong:
* fluxoversurface.hh lacks the factor for the calculation of the volume fluxes
* stokesdarcy/couplingdata.hh includes the factor in the calculation of diffusive fluxes, however, those values
are then applied as Neuman-BCs where the factor is again applied
__TODO__ @heck What about the Maxwell-Stefan fluxes in the coupling data?3.1Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/474[material][brine] Implement brine fluid system and brine pseudo component2018-07-20T15:18:13ZTimo Kochtimokoch@math.uio.no[material][brine] Implement brine fluid system and brine pseudo componentBrine is currently a pseudo component but extends the interface to be able to have variable salinity. A mixture with variable salinity is however a fluid system. We should implement both interface (brine as fluidsystem and brine as pseud...Brine is currently a pseudo component but extends the interface to be able to have variable salinity. A mixture with variable salinity is however a fluid system. We should implement both interface (brine as fluidsystem and brine as pseudocomponent with constant salinity) classes separately.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/469Compiler warnings2018-10-31T15:52:12ZThomas FetzerCompiler warningsWe should fix or at least discuss whether we want to fix the following compiler warnings (I am aware that DUNE prints a lot of this warnings, too).
* [x] -Wshadow (shadowing of local variables, e.g. by lambda functions or if/for loops)
...We should fix or at least discuss whether we want to fix the following compiler warnings (I am aware that DUNE prints a lot of this warnings, too).
* [x] -Wshadow (shadowing of local variables, e.g. by lambda functions or if/for loops)
* [x] -Wno-missing-braces -Wmissing-field-initializers (initiliazation, e.g. object({}) vs object{{}} )
* [x] -Wunused-result (e.g. #472)
* [x] -Wfloat-equal3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/364Correct handling of diffusive fluxes2018-07-26T11:46:43ZDennis GläserCorrect handling of diffusive fluxesIn the seminar we came up with the following strategy:
- [x] When useMoles = false we will have to add the diffusive fluxes to the total mass balance equation (eqIdx = replaceCompIdx)
- [x] Fick's law will always be mole based (as in it...In the seminar we came up with the following strategy:
- [x] When useMoles = false we will have to add the diffusive fluxes to the total mass balance equation (eqIdx = replaceCompIdx)
- [x] Fick's law will always be mole based (as in its derivation). However, the fluxes are transformed into mass fluxes if useMoles = false
- [x] Update documentation
- [x] Return vector of fluxes from fick's law and think about maxwell-stefan diffusion when implementing it
3.0Katharina HeckKatharina Heck