dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2018-09-04T19:42:32Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/518Most fluid systems uses w,n as phase names2018-09-04T19:42:32ZTimo Kochtimokoch@math.uio.noMost fluid systems uses w,n as phase namesThese are not correct phasenames for mixed wettability cases. Also some fluid systems use liquid/gas while others use l/g. I would prefer the latter since it's shorter.These are not correct phasenames for mixed wettability cases. Also some fluid systems use liquid/gas while others use l/g. I would prefer the latter since it's shorter.3.0Sina AckermannSina Ackermannhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/426BrineCO2 Fluidsystems uses wrong/misleading gasDensity_ calculation2018-09-01T14:50:04ZSimon EmmertBrineCO2 Fluidsystems uses wrong/misleading gasDensity_ calculationThe ``brineco2.hh`` fluidystems uses an incorrect gasDensity calculation in the private ``gasDensity_`` function. It returns the unchanged CO2 gas density, while the density function implies a lot more complex density calculation similar...The ``brineco2.hh`` fluidystems uses an incorrect gasDensity calculation in the private ``gasDensity_`` function. It returns the unchanged CO2 gas density, while the density function implies a lot more complex density calculation similar to the ``liquidDensity_``.
This seems to be like this from the very first commit on git, but e.g. in a ``biofluidsystem.hh`` that was derived from the brineco2.hh a long time ago by @hommel on dumux-devel there is a more complex gasDensity calculation using Dalton's law available. (see below)
I suggest we change/fix this once most tests pass, because this might change some results for the ``next`` branch.
I am not sure, what we should do about the master (or 2.12).
Additionally the normalization of some moleFractions etc. seems a little sketchy to me, but that might be necessary.
Additionally the second the brineco2.hh still uses the deprecated xl and xg naming. This should be changed, while fixing this.
` static Scalar gasDensity_(Scalar T,
Scalar pg,
Scalar xgH2O)
{
Scalar pH2O = xgH2O*pg; //Dalton' Law
Scalar pCO2 = pg - pH2O;
Scalar gasDensityCO2 = CO2::gasDensity(T, pCO2);
Scalar gasDensityH2O = H2O::gasDensity(T, pH2O);
Scalar gasDensity = gasDensityCO2 + gasDensityH2O;
return gasDensity;
}`3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/561BrineCO2 phaseIdx assertion in test_fluidsystems2018-08-30T07:15:33ZSimon EmmertBrineCO2 phaseIdx assertion in test_fluidsystemsOur fluidsystems-test fails (line 159), because the assertion of ``assert(restrictPhaseIdx_ < 0 || restrictPhaseIdx_ == phaseIdx);`` fails for the pressure.
I guess this has to do with the brine-adapter, but could not fix it or it did n...Our fluidsystems-test fails (line 159), because the assertion of ``assert(restrictPhaseIdx_ < 0 || restrictPhaseIdx_ == phaseIdx);`` fails for the pressure.
I guess this has to do with the brine-adapter, but could not fix it or it did not make perfect sense to me right away. Does someone have an idea? If not this should be perfect for the dumux day.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/548Streamline phase presence output name2018-08-29T14:00:29ZTimo Kochtimokoch@math.uio.noStreamline phase presence output namelooks like `phase presence` is used by 3p, 3p3c while `phasePresence` is used by 2pnc, 2p1c, richards, who wins?looks like `phase presence` is used by 3p, 3p3c while `phasePresence` is used by 2pnc, 2p1c, richards, who wins?3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/568Calling type tags `...TypeTag`2018-08-29T09:35:55ZBernd FlemischCalling type tags `...TypeTag`At some point back in time, many of the type tags in the test problems have been renamed from `...` to `...TypeTag`. I would like to discuss this (once more?). I don't see any added value here. It is clear that the first argument in the ...At some point back in time, many of the type tags in the test problems have been renamed from `...` to `...TypeTag`. I would like to discuss this (once more?). I don't see any added value here. It is clear that the first argument in the `_PROP_` macros is a `TypeTag`, it can't be anything else. We also don't call a `SolutionVector` `xSolutionVector` or a `Scalar` `porosityScalar`.
In any case, the naming is not done consistently over all test problems.3.0Melanie LippMelanie Lipphttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/567test_vtkreader_2d3d fails due to assert2018-08-29T09:16:41ZTimo Kochtimokoch@math.uio.notest_vtkreader_2d3d fails due to assert```
test_vtkreader_2d3d: /data/src/dune-alugrid/dune/alugrid/impl/serial/gitter_mgb.cc:759: void ALUGrid::MacroGridBuilder::finalize(): Assertion `((hface3_GEO *)(*i).second)->ref == 2' failed.
```
Maybe something is wrong with the grid ...```
test_vtkreader_2d3d: /data/src/dune-alugrid/dune/alugrid/impl/serial/gitter_mgb.cc:759: void ALUGrid::MacroGridBuilder::finalize(): Assertion `((hface3_GEO *)(*i).second)->ref == 2' failed.
```
Maybe something is wrong with the grid file? The test passes however, if assertions are disabled.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/550Freeflow assembly clang compiler error2018-08-28T19:22:54ZTimo Kochtimokoch@math.uio.noFreeflow assembly clang compiler error```
/data/src/dumux/dumux/multidomain/subdomainstaggeredlocalassembler.hh:360:97: error: non-type template argument is not a constant expression
1885 static constexpr auto otherDomainIds = makeIncompleteIntegerSequence<Dune::Hybri...```
/data/src/dumux/dumux/multidomain/subdomainstaggeredlocalassembler.hh:360:97: error: non-type template argument is not a constant expression
1885 static constexpr auto otherDomainIds = makeIncompleteIntegerSequence<Dune::Hybrid::size(jacRow), domainId>{};
1886 ^
```
jacRow is indeed not a constexpr. The result of Dune::Hybrid::size can be actually a constexpr for special types and jacRow is I think a tuple so it works. But you are proabably not allowed to directly use it in a template because it might also be not a constexpr. Maybe we can try static constexpr auto size = Dune::Hybrid::size(jacRow); and then use size as a template argument?3.0Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/442Collection of not working tests / errors on buildbot2018-08-28T12:56:57ZSimon EmmertCollection of not working tests / errors on buildbotThis is a collection of problems we currently have on buildbot. It is collected here to help everyone in fixing the last tests.
The following fail:
**test flow
* [ ] test_2p_fracture_gravity_mpfa --> Data differs -> Dennis
* [ ] tes...This is a collection of problems we currently have on buildbot. It is collected here to help everyone in fixing the last tests.
The following fail:
**test flow
* [ ] test_2p_fracture_gravity_mpfa --> Data differs -> Dennis
* [ ] test_2p_fracture_gravity_tpfa --> Data differs in parameter: Sn, mobW, pc -> Dennis
* [ ] test_box3pwateroil -> was fixed but still fails on buildbot while passing on my notebook+desktop -> Bernd
* [ ] test_3d2pfvadaptive -> Error from solvers.hh "abs(h) < EPSILON" (see !1038)3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/425Test unused headers2018-08-23T11:00:13ZBernd FlemischTest unused headersTest the following headers:
* [x] common/reorderingdofmapper.hh
* [x] common/quad.hh
* [x] io/cpgridcreator.hh
* [x] linear/scotchbackend.hh
* [x] material/chemistry/electrochemistry/electrochemistryni.hh
* [x] nonlinear/newtonconvergen...Test the following headers:
* [x] common/reorderingdofmapper.hh
* [x] common/quad.hh
* [x] io/cpgridcreator.hh
* [x] linear/scotchbackend.hh
* [x] material/chemistry/electrochemistry/electrochemistryni.hh
* [x] nonlinear/newtonconvergencewriter.hh3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/560Mixed-type boundary conditions for box2018-08-16T16:48:42ZBernd FlemischMixed-type boundary conditions for boxThe current implementation in `assembly/boxlocalresidual.hh` forbids boundary conditions of mixed type, i.e. where one subset of equations gets Dirichlet conditions while the complementary subset gets Neumann conditions. This is too rest...The current implementation in `assembly/boxlocalresidual.hh` forbids boundary conditions of mixed type, i.e. where one subset of equations gets Dirichlet conditions while the complementary subset gets Neumann conditions. This is too restrictive. The box method can handle such mixed-type boundary conditions easily. They are frequently encountered in, e.g., solid mechanics problems.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/5222p1c primary variable switch and mixed wettability concept not consistent wit...2018-08-16T08:54:19ZTimo Kochtimokoch@math.uio.no2p1c primary variable switch and mixed wettability concept not consistent with other 2p compositional modelsThe 2p1c model is not adapted (at least in some parts) to the new mixed-wettability concept for two-phase flow.The 2p1c model is not adapted (at least in some parts) to the new mixed-wettability concept for two-phase flow.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/558Porosity under deformation2018-08-16T08:37:33ZBernd FlemischPorosity under deformationIn `material/fluidmatrixinteractions/porositydeformation.hh`, we calculate the effective porosity as
```math
\phi_\text{eff} = \phi_0 ( 1 + \text{div}\,u ).
```
In the last release's `geomechanics/el2p/elementvolumevariables.hh`, we use
...In `material/fluidmatrixinteractions/porositydeformation.hh`, we calculate the effective porosity as
```math
\phi_\text{eff} = \phi_0 ( 1 + \text{div}\,u ).
```
In the last release's `geomechanics/el2p/elementvolumevariables.hh`, we use
```math
\phi_\text{eff} = \frac{\phi_0 + \text{div}\,u}{1 + \text{div}\,u},
```
justified by the following comment:
```cpp
// this equation would be correct if the bulk volume could change (Vol_new = Vol_init *(1+div u)),
// however, we have a constant bulk volume therefore we should apply phi_eff = phi_init + div u
// but this causes convergence problems. Since div u is very small here the chosen relation is
// assumed to be a good approximation
```
The comment suggests that the truth should be
```math
\phi_\text{eff} = \phi_0 + \text{div}\,u.
```
@martinb, @DennisGlaeser, @holle: What's your opinion? What should we implement? It actually makes a rather big difference: In the setting discussed in #546, I get the following effective porosities:![el2p_porosities](/uploads/b260998a323ff75b7e7b0d335a75ba88/el2p_porosities.png)
Red corresponds to the first formula (master), black to the second (release) and green to the third (suggested by the comment).3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/556H2OAir compiler warning2018-08-14T16:07:45ZTimo Kochtimokoch@math.uio.noH2OAir compiler warning```
/home/timok/dumux-root/dumux/dumux/material/fluidsystems/h2oair.hh: In static member function 'static Scalar Dumux::FluidSystems::H2OAir<Scalar, H2Otype, Policy, useKelvinVaporPressure>::binaryDiffusionCoefficient(const FluidState&, ...```
/home/timok/dumux-root/dumux/dumux/material/fluidsystems/h2oair.hh: In static member function 'static Scalar Dumux::FluidSystems::H2OAir<Scalar, H2Otype, Policy, useKelvinVaporPressure>::binaryDiffusionCoefficient(const FluidState&, int, int, int) [with FluidState = Dumux::ImmiscibleFluidState<double, Dumux::FluidSystems::H2OAir<double, Dumux::Components::SimpleH2O<double>, Dumux::FluidSystems::H2OAirDefaultPolicy<true>, false> >; Scalar = double; H2Otype = Dumux::Components::SimpleH2O<double>; Policy = Dumux::FluidSystems::H2OAirDefaultPolicy<true>; bool useKelvinVaporPressure = false]':
/home/timok/dumux-root/dumux/dumux/material/fluidsystems/h2oair.hh:618:17: warning: this statement may fall through [-Wimplicit-fallthrough=]
switch (compJIdx) {
^~~~~~
/home/timok/dumux-root/dumux/dumux/material/fluidsystems/h2oair.hh:623:13: note: here
default:
^~~~~~~
```
there is a break missing after the nested switch AFAIK...3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/458[task] Reimplement restart facility2018-08-10T17:25:01ZTimo Kochtimokoch@math.uio.no[task] Reimplement restart facilityThe restart feature got lost in transition to 3.0. Think about how to reimplement in the new structure. Most main files still have left over restart code that doesn't do anything.The restart feature got lost in transition to 3.0. Think about how to reimplement in the new structure. Most main files still have left over restart code that doesn't do anything.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/527[fluidsystems] Reuse brine fluid system in BrineCO22018-08-10T10:07:16ZTimo Kochtimokoch@math.uio.no[fluidsystems] Reuse brine fluid system in BrineCO2See BrineAir for this can be achieved.
Check if the binary laws Brine_CO2 are actually needed.See BrineAir for this can be achieved.
Check if the binary laws Brine_CO2 are actually needed.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/539Small time step size when using CheckPointTimeLoop2018-08-03T06:01:19ZMartin SchneiderSmall time step size when using CheckPointTimeLoopWhen using the `CheckPointTimeLoop` it may happen that the last time step is extremely small (e.g. in the range of 1.0e-16),
see the `exercise_1p_c` of the dumux-course in the `exercise-mainfile` folder. The reason for this are rounding ...When using the `CheckPointTimeLoop` it may happen that the last time step is extremely small (e.g. in the range of 1.0e-16),
see the `exercise_1p_c` of the dumux-course in the `exercise-mainfile` folder. The reason for this are rounding errors and the implementation of the function
```c++
bool finished() const
{ return finished_ || time_ >= endTime_; }
```
where `time_ >= endTime` is false since `time_ = endTime_ - eps`.
It would be better to use `Dune::FloatCmp::eq` instead. The same also holds for the function `willBeFinished()`.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/544Need for unit test for CheckPointTimeLoop2018-08-03T06:01:19ZTimo Kochtimokoch@math.uio.noNeed for unit test for CheckPointTimeLoopThe check pointing can be tricky with floating point operations. We should have a unit test testing corner cases, very small and very big time step size and so on.The check pointing can be tricky with floating point operations. We should have a unit test testing corner cases, very small and very big time step size and so on.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/535Parallelism broken for Grid != YaspGrid?2018-07-30T10:06:35ZBernd FlemischParallelism broken for Grid != YaspGrid?I cannot run any implicit test in parallel with a grid type different from Yasp. The AMGBackend detects a singular matrix for the coarse solver. Since a difference is that Yasp has overlap elements while the other parallel grids have gho...I cannot run any implicit test in parallel with a grid type different from Yasp. The AMGBackend detects a singular matrix for the coarse solver. Since a difference is that Yasp has overlap elements while the other parallel grids have ghost elements, I suspect a bug in the handling of the ghost elements.3.0Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/534Non-implemented functions lead to infinite loops in fluid system2018-07-29T13:55:49ZTimo Kochtimokoch@math.uio.noNon-implemented functions lead to infinite loops in fluid systemThe base class calls Implementation::function in function which leads to an infinite loop of function is not overloaded in the Implementation. Instead mandatory function should probably contain static_asserts as in Components::Base, non ...The base class calls Implementation::function in function which leads to an infinite loop of function is not overloaded in the Implementation. Instead mandatory function should probably contain static_asserts as in Components::Base, non mandatory functions should throw a probably Dune::NotImplemented error.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/533Rename FluidSystem::BaseFluidSystem to FluidSystem::Base2018-07-26T11:46:43ZTimo Kochtimokoch@math.uio.noRename FluidSystem::BaseFluidSystem to FluidSystem::Base3.0