dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2018-07-11T10:11:44Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/348Link the user survey on the Dumux website2018-07-11T10:11:44ZTimo Kochtimokoch@math.uio.noLink the user survey on the Dumux websiteThere is a new DuMuX user survey on ILIAS
https://ilias3.uni-stuttgart.de/goto_Uni_Stuttgart_svy_1148632.html?lang=en
After being tested and if necessary adjusted it should be linked on the website and publicly announced on the mai...There is a new DuMuX user survey on ILIAS
https://ilias3.uni-stuttgart.de/goto_Uni_Stuttgart_svy_1148632.html?lang=en
After being tested and if necessary adjusted it should be linked on the website and publicly announced on the mailing list.
One the questions are publicly announced and the first participated we can't change single questions anymore. So we should be sure they are answering what we want.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/358Inconsistent usage of IndexType2018-12-09T17:40:09ZTimo Kochtimokoch@math.uio.noInconsistent usage of IndexTypeWe should use an `IndexType` from the grid's index set if the index set in question has a clear relation to the grid's indices. These indices could probably use the alias `GlobalIndexType`. We should _not_ use the index type of the grid'...We should use an `IndexType` from the grid's index set if the index set in question has a clear relation to the grid's indices. These indices could probably use the alias `GlobalIndexType`. We should _not_ use the index type of the grid's index set for
* local indices (could use an alias `LocalIndexType`)
* grid index set unrelated indices3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/363[next] Reference files for mixeddimension tests2018-02-14T16:44:13ZTimo Kochtimokoch@math.uio.no[next] Reference files for mixeddimension testsMost mixeddimension tests need reference filesMost mixeddimension tests need reference files3.0https://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 Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/367Meaning of "UseComplexRelations"2018-07-20T15:06:37ZThomas FetzerMeaning of "UseComplexRelations"In the seminar we came up with the following strategy:
"UseComplexRelations" should have a different meaning. When false we will still calculate rho, mu, ... dependent on composition. But, the flag can specify whether or not to use a si...In the seminar we came up with the following strategy:
"UseComplexRelations" should have a different meaning. When false we will still calculate rho, mu, ... dependent on composition. But, the flag can specify whether or not to use a simpler equation.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/387Assumption of constant molar density2018-07-20T14:58:29ZTimo Kochtimokoch@math.uio.noAssumption of constant molar densityMany things in the current code are based on the assumptions that the phase molar density is constant. However this is not explicitly seen in the code. In fact, we even compute the molar density from the mass density (in which we often u...Many things in the current code are based on the assumptions that the phase molar density is constant. However this is not explicitly seen in the code. In fact, we even compute the molar density from the mass density (in which we often use a constant molar density to compute it). Also the assumption that the diffusive flux of a component k in a phase a in equal to minus the diffusive flux of component a in phase a follows from the assumption of constant molar density. However molar density is not only a function of composition (which might be neglected for dilute solution) but also of temperature and density.
I propose to implement it in a way that we never make the assumption of constant molar density. We then should * compute the mass density from the molar density (explicitly using the method returning the molar density),
* ~~compute self-diffusion of water in water / air in air~~
* always add up the diffusive fluxes to the total mass/mole balance (they generally don't cancel out)
* put the molar density inside the gradient in Fick's law ???
* implement molarDensity ~~and self diffusion coefficient~~ method in all components
~~I think this might be necessary to simulate highly concentrated solutions like brine.~~3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/390Distinguish between a vector of size numEq and the primary variables class2018-04-05T14:38:59ZTimo Kochtimokoch@math.uio.noDistinguish between a vector of size numEq and the primary variables classsee commit 266b7840.
If !530 gets merged we need to distinguish between two concept for sake of generality:
* a vector of size number equations that we can use to store fluxes, storage, source and residuals for each
equation and:
* a pr...see commit 266b7840.
If !530 gets merged we need to distinguish between two concept for sake of generality:
* a vector of size number equations that we can use to store fluxes, storage, source and residuals for each
equation and:
* a primary variables vector that contains the values of all primary variables
at a d.o.f. location.
The latter might also have a state in the case of privar switch models
that indicates the type of primary variables saved in this vector.
The vectors have different usages but will default to the same type `Dune::FieldVector<Scalar, numEq>`
and can be speziali0zed independent from each other if needed.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/400Use moles should be known at compile time2018-01-13T18:28:38ZTimo Kochtimokoch@math.uio.noUse moles should be known at compile timeNoone wants to switch useMoles at run time and we could profit from better compiler optimizations.Noone wants to switch useMoles at run time and we could profit from better compiler optimizations.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/407Different initial saturation guesses in 2p2c and 2pnc2018-04-05T09:45:41ZBernd FlemischDifferent initial saturation guesses in 2p2c and 2pncThis emerged from #371.
The initial saturation values when switching from one phase to two phases are different in the 2p2c and 2pnc model:
| | nPhase -> both Phases | wPhase -> both Phases |
|---|---|---|
| 2p2c | Sw = 0, Sn = 1 | Sw ...This emerged from #371.
The initial saturation values when switching from one phase to two phases are different in the 2p2c and 2pnc model:
| | nPhase -> both Phases | wPhase -> both Phases |
|---|---|---|
| 2p2c | Sw = 0, Sn = 1 | Sw = 0.999, Sn = 0.001 |
| 2pnc | Sw = 0.0001, Sn = 0.9999 | Sw = 0.9999, Sn = 0.0001 |
In principle, the Newton should take care of the different initial values. But since the Newton also has a threshold, small differences might add up and lead to intolerable (?) differences. What should we do to synchronize both models?3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/409How to deal with multiple solid phases2018-05-08T16:07:39ZBernd FlemischHow to deal with multiple solid phasesThe models `1pncmin` and `2pncmin` deal with possibly several solid phases. For example, there may be two solid phases, one referring to the original rock matrix and the other one to the precipitated salt. We should rethink how all of th...The models `1pncmin` and `2pncmin` deal with possibly several solid phases. For example, there may be two solid phases, one referring to the original rock matrix and the other one to the precipitated salt. We should rethink how all of this is implemented and named.
For example, the number of solid phases currently is an enum in the fluid system. Why should a *fluid* system keep information about something *solid*? This is very counter-intuitive. Can we find a better place for this? Should we rename `FluidSystem` to `ComponentSystem` or `PhaseSystem`?
The current generic energy equations don't take into account the possibility of more than one solid phase. Should we add the capability there or should we treat this as corner cases and define specialized energy equations for `1pncmin` and `2pncmin`?3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/410Remove UseComplexRelations2018-07-20T15:12:56ZBeatrix BeckerRemove UseComplexRelationsUseComplexRelations does different things for liquids and gases:
* !UseComplexRelations: for liquids the density of the mixture is assumed to be the density of the main component, for gases ideal gas mixture is assumed
* UseComplexRel...UseComplexRelations does different things for liquids and gases:
* !UseComplexRelations: for liquids the density of the mixture is assumed to be the density of the main component, for gases ideal gas mixture is assumed
* UseComplexRelations: for liquids the molar density of the mixture equals the molar density of the main component, for gases Dalton's law is assumed (for ideal gases this is the same as assuming ideal gas mixture)
We propose to remove UseComplexRelations and do:
for liquids: the molar density of the mixture equals the molar density of the main component (and the mass density is calculated accordingly using the composition)
for gases: if all gases are ideal gases (isIdealGas) assume ideal gas mixture, otherwise use Dalton's law
Reference solutions for test cases that use !UseComplexRelations might need to be updated, all other tests should still work3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/411Make fluidsystems more generic and restructure2018-04-08T20:23:29ZBeatrix BeckerMake fluidsystems more generic and restructureFluidsystems could be restructured in the following way + made more generic:
* Fluidsystems/immiscible
* 1pgas, 1pliquid (former gasphase.hh, liquidphase.hh, probably only need to be renamed. This is related to issue #403)
* ~~...Fluidsystems could be restructured in the following way + made more generic:
* Fluidsystems/immiscible
* 1pgas, 1pliquid (former gasphase.hh, liquidphase.hh, probably only need to be renamed. This is related to issue #403)
* ~~2pliquidgas, 2pliquidliquid (need to be created)~~
* 3pliquidliquidgas (needs to be created)
* Fluidsystems/miscible
* 2p1c (inherits from 2pliquidgas only with the same two components)
* all other fluidsystems
Add isMiscible to all fluidsystems. It might be possible to delete some specific fluidsystems and use the new generic fluidsystems instead.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/413Rename Problem-TypeTags to end in "TypeTag"2018-02-09T08:24:20ZTimo Kochtimokoch@math.uio.noRename Problem-TypeTags to end in "TypeTag"Most of our test TypeTags are called something like `OnePBoxProblem` but I think they should be called `OnePBoxTypeTag` just to avoid confusion with the problem class.Most of our test TypeTags are called something like `OnePBoxProblem` but I think they should be called `OnePBoxTypeTag` just to avoid confusion with the problem class.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/421Add Richards test using privarswitch2018-04-09T05:27:43ZTimo Kochtimokoch@math.uio.noAdd Richards test using privarswitchThere exists a privarswitch implementation for the Richards model interesting for evaporation applications. It is currently not tested. See `dumux/porousmediumflow/richards/`.There exists a privarswitch implementation for the Richards model interesting for evaporation applications. It is currently not tested. See `dumux/porousmediumflow/richards/`.3.0Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/424Staggered: Decoupled stencil from flux variables2017-12-21T15:35:10ZTimo Kochtimokoch@math.uio.noStaggered: Decoupled stencil from flux variables3.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/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/427Improve staggered free flow model2018-11-12T16:01:12ZTimo Kochtimokoch@math.uio.noImprove staggered free flow model- [x] Account for extrusion factor (see !914)
- [x] fluxes
- [x] storage terms
- [x] Add 2D friction term to mimic 3D flow (see !925)
- [ ] Implement better tests (e.g. 3D, transient, backward-facing step, etc.) (see #415)
- [ ] Imp...- [x] Account for extrusion factor (see !914)
- [x] fluxes
- [x] storage terms
- [x] Add 2D friction term to mimic 3D flow (see !925)
- [ ] Implement better tests (e.g. 3D, transient, backward-facing step, etc.) (see #415)
- [ ] Improve the documentation (help message) and appearance of the test provlems
- [x] Improve inheritance structure (especially for RANS models) (see !915)
- [x] Improve boundary conditions (#487)
- [x] Check caching on/off3.0Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/428Compiler errors using clang2018-01-11T09:26:38ZThomas FetzerCompiler errors using clangI experienced compiler errors when using clang 4.0.1, e.g. the test_2p2c_box does not compile:
In file included from /temp/fetzer/dumux-30/dumux/test/porousmediumflow/2p2c/implicit/test_2p2c_fv.cc:42:
/temp/fetzer/dumux-30/dumux/dumux/p...I experienced compiler errors when using clang 4.0.1, e.g. the test_2p2c_box does not compile:
In file included from /temp/fetzer/dumux-30/dumux/test/porousmediumflow/2p2c/implicit/test_2p2c_fv.cc:42:
/temp/fetzer/dumux-30/dumux/dumux/porousmediumflow/compositional/privarswitchnewtoncontroller.hh:148:74: error: no member named 'curSol' in
'Dumux::PriVarSwitchNewtonController<Dumux::Properties::TTag::InjectionBoxTypeTag>'
const ElementSolution elemSol(element, this->curSol(), fvGridGeometry);3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/429Compiler errors using gcc2018-01-03T19:54:36ZThomas FetzerCompiler errors using gcctemp/fetzer/dumux-30/dumux/test/freeflow/navierstokes/test_closedsystem.cc:135:36: required from here
/temp/fetzer/dumux-30/dumux/dumux/common/staggeredfvproblem.hh:176:24: error: expected primary-expression
return IntRange(0,...temp/fetzer/dumux-30/dumux/test/freeflow/navierstokes/test_closedsystem.cc:135:36: required from here
/temp/fetzer/dumux-30/dumux/dumux/common/staggeredfvproblem.hh:176:24: error: expected primary-expression
return IntRange(0, numEqCellCenter);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~
/temp/fetzer/dumux-30/dumux/dumux/common/staggeredfvproblem.hh: In instantiation of ‘void Dumux::StaggeredFVProblem<TypeTag>::applyInititalCellCenterSolution(Dumux::StaggeredFVProblem<TypeTag>::SolutionVector&, const SubControlVolume&, const PrimaryVariables&) const [with TypeTag = Dumux::Properties::TTag::ClosedSystemTestProblem; Dumux::StaggeredFVProblem<TypeTag>::SolutionVector = Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >; Dumux::StaggeredFVProblem<TypeTag>::SubControlVolume = Dumux::CCSubControlVolume<Dumux::Properties::Property<Dumux::Properties::TTag::ClosedSystemTestProblem, Dumux::Properties::TTag::StaggeredModel, Dumux::Properties::PTag::SubControlVolume>::ScvGeometryTraits>; Dumux::StaggeredFVProblem<TypeTag>::PrimaryVariables = Dune::FieldVector<double, 3>]’:
/temp/fetzer/dumux-30/dumux/dumux/common/staggeredfvproblem.hh:127:17: required from ‘void Dumux::StaggeredFVProblem<TypeTag>::applyInitialSolution(Dumux::StaggeredFVProblem<TypeTag>::SolutionVector&) const [with TypeTag = Dumux::Properties::TTag::ClosedSystemTestProblem; Dumux::StaggeredFVProblem<TypeTag>::SolutionVector = Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >]’
/temp/fetzer/dumux-30/dumux/test/freeflow/navierstokes/test_closedsystem.cc:135:36: required from here
/temp/fetzer/dumux-30/dumux/dumux/common/staggeredfvproblem.hh:145:9: error: forming reference to void
for(auto&& i : priVarIndices_(cellCenterIdx))3.0