dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2018-04-09T05:27:43Zhttps://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/422Stencil is only used by cell-centered models2017-12-22T13:12:17ZTimo Kochtimokoch@math.uio.noStencil is only used by cell-centered models* [x] Remove computeStencil in BaseFluxvariables
* [x] Use Stencil class directly
* [x] Move stencil class in cell-centered
It's only used by the assembly map so far.* [x] Remove computeStencil in BaseFluxvariables
* [x] Use Stencil class directly
* [x] Move stencil class in cell-centered
It's only used by the assembly map so far.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/423Staggered: Rename test folders to navierstokes2017-12-22T13:12:17ZTimo Kochtimokoch@math.uio.noStaggered: Rename test folders to navierstokesKilian WeishauptKilian Weishaupthttps://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.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/430Fix compiler error with clang2017-12-28T12:58:07ZTimo Kochtimokoch@math.uio.noFix compiler error with clangClang finds some errors that g++ doesn't seem notice on current master (3.0-alpha).Clang finds some errors that g++ doesn't seem notice on current master (3.0-alpha).3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/431Grid shouldn't be a singleton2018-06-28T16:39:23ZTimo Kochtimokoch@math.uio.noGrid shouldn't be a singletonThere is not just always one grid of a type, or one grid per typetag/problem. So the grid shouldn't be implemented as a singleton.
The gridcreator / gridwrapper needs to be available to problems (boundary conditions) and spatial params ...There is not just always one grid of a type, or one grid per typetag/problem. So the grid shouldn't be implemented as a singleton.
The gridcreator / gridwrapper needs to be available to problems (boundary conditions) and spatial params (params from dgf/msh) for parameters.
We could pass a shared_ptr to the problem / spatialparams in the constructor.
All occurances of `GridCreator::grid()` should be replaced by either `gridView.grid()` or using a grid object directly (adaptive).
see also !185 3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/432Implement primary variable switch for volume variable caching enabled2018-06-22T13:48:35ZTimo Kochtimokoch@math.uio.noImplement primary variable switch for volume variable caching enabled3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/433Initial porosity and permeability in respective laws2018-04-25T08:30:50ZJohannes HommelInitial porosity and permeability in respective lawsCurrently, the initial porosity and permeability values in the respective laws for the mineralization model are treated as values of the clean, unreactive porous medium without any initial precipitates. However, there are many cases, jus...Currently, the initial porosity and permeability values in the respective laws for the mineralization model are treated as values of the clean, unreactive porous medium without any initial precipitates. However, there are many cases, just as in the 2pncmin test, where there is some dissolving mineral present initially. In such cases, the initial porosity and permeability as implemented now are misleading, as the initial porosity and permeability in the calculations will not be the input value, but those updated by the effect of the initial mineral volume fraction.
I think a good way to improve this would be to rename initialPorosity(...) and initialPermeability(...). But I do not yet have good suggestion except for maybe cleanP.(...), unreactiveP.(...), or referenceP.(...). Further, the values for referenceP.(...) should be calculated in the initialization of the spatial parameters based on the actual initial porosity and permeability values: referencePorosity_= initialPorosity_-sum(precipitateVolumeFractions); and accordingly for referencePermeability_ with the respective permeability law used.
Whatever we decide to do, we should be more clear about what the reference parameters (currently initialPorosity(...) and initialPermeability(...)) for the porosity and permeability laws really are. Are they the "clean-porous-medium" values or the "initial" values or some arbitrary reference?. In my opinion, the "initial" is too misleading as it is used right now.
* [X] update 1pncmin and 2pncmin to use referenceXY(), as the already define reference and not initial values
3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/434[mpfa] array subscript is above array bounds2018-02-01T15:39:52ZTimo Kochtimokoch@math.uio.no[mpfa] array subscript is above array boundsMost mpfa tests give the following warning with gcc:
```bash
Scanning dependencies of target test_1pniccmpfa_convection
[ 16%] Building CXX object test/porousmediumflow/1p/implicit/CMakeFiles/test_1pniccmpfa_convection.dir/test_1pnifv.c...Most mpfa tests give the following warning with gcc:
```bash
Scanning dependencies of target test_1pniccmpfa_convection
[ 16%] Building CXX object test/porousmediumflow/1p/implicit/CMakeFiles/test_1pniccmpfa_convection.dir/test_1pnifv.cc.o
In file included from /home/timok/dumux-course/dune-grid/dune/grid/yaspgrid.hh:26:0,
from /home/timok/dumux-course/dune-grid/dune/grid/io/file/dgfparser/dgfyasp.hh:7,
from /home/timok/dumux-course/dune-alugrid/dune/alugrid/common/structuredgridfactory.hh:25,
from /home/timok/dumux-course/dune-alugrid/dune/alugrid/grid.hh:19,
from /home/timok/dumux-course/dumux/dumux/common/boundaryflag.hh:29,
from /home/timok/dumux-course/dumux/dumux/discretization/box/properties.hh:33,
from /home/timok/dumux-course/dumux/test/porousmediumflow/1p/implicit/1pniconductionproblem.hh:30,
from /home/timok/dumux-course/dumux/test/porousmediumflow/1p/implicit/test_1pnifv.cc:35:
/home/timok/dumux-course/dune-common/dune/common/reservedvector.hh: In constructor 'Dumux::CCMpfaOInteractionVolumeIndexSet<DualGridNodalIndexSet>::CCMpfaOInteractionVolumeIndexSet(const NodalIndexSet&) [with DualGridNodalIndexSet = Dumux::CCMpfaDualGridNodalIndexSet<unsigned int, unsigned char, 2, 15, 2>]':
/home/timok/dumux-course/dune-common/dune/common/reservedvector.hh:140:18: warning: array subscript is above array bounds [-Warray-bounds]
return data[i];
~~~~^
/home/timok/dumux-course/dune-common/dune/common/reservedvector.hh:140:18: warning: array subscript is above array bounds [-Warray-bounds]
return data[i];
~~~~^
/home/timok/dumux-course/dune-common/dune/common/reservedvector.hh:140:18: warning: array subscript is above array bounds [-Warray-bounds]
return data[i];
~~~~^
/home/timok/dumux-course/dune-common/dune/common/reservedvector.hh:140:18: warning: array subscript is above array bounds [-Warray-bounds]
...
```3.0Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/435StaggeredNewtonController: Specialize solve depending no whether MultiTypeMat...2018-01-25T15:24:11ZTimo Kochtimokoch@math.uio.noStaggeredNewtonController: Specialize solve depending no whether MultiTypeMatrices are accepted by the solver or not3.0Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/436Minimize private alias declarations and static constants?2023-12-13T11:13:06ZBernd FlemischMinimize private alias declarations and static constants?Currently, each Dumux class that takes a TypeTag as template parameter typically contains several/many private alias declarations and static constant definitions extracted from the TypeTag. This may happen hundreds of lines above the fir...Currently, each Dumux class that takes a TypeTag as template parameter typically contains several/many private alias declarations and static constant definitions extracted from the TypeTag. This may happen hundreds of lines above the first usage of the declared names.
An alternative would be to put the declarations as close as possible to the place where they are used. If the declarations are used as function parameter / return types, one could use template parameters / auto instead.
The expected benefit would be an improved readability of the code and the avoidance of unused declarations and definitions.
In order to discuss this, I set up !741. Please have a look and share your opinions here.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/437!734 Introduces bug for adaptive grids2018-02-05T11:56:47ZTimo Kochtimokoch@math.uio.no!734 Introduces bug for adaptive gridsThen stencil sizes are fixed since this merge and all adaptive tests run into segfaults because the maximum sizes are not big enough anymore..Then stencil sizes are fixed since this merge and all adaptive tests run into segfaults because the maximum sizes are not big enough anymore..3.0Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/438Free RichardsNewtonController from TypeTag2018-04-05T07:43:52ZTimo Kochtimokoch@math.uio.noFree RichardsNewtonController from TypeTag3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/439Free PriVarSwitchNewtonController from TypeTag2018-04-05T07:43:31ZTimo Kochtimokoch@math.uio.noFree PriVarSwitchNewtonController from TypeTag3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/440Preconditioning in miscible2pnc constraintsolver leads to different solution...2018-02-22T07:48:13ZKatharina HeckPreconditioning in miscible2pnc constraintsolver leads to different solution compared to 2p2cThis emerged from issue #407 .
In principal the 2p2c and 2pnc model do the same for 2 components. Even the different values in the priVarswitch (see #407) does not change the solution.
Looking into that we found that the precondition...This emerged from issue #407 .
In principal the 2p2c and 2pnc model do the same for 2 components. Even the different values in the priVarswitch (see #407) does not change the solution.
Looking into that we found that the preconditioning of the matrix in the miscible2pncconstraintsolver is what causes the different solutions of the 2p2c and the 2pnc model.
Points up to discussion are now (in my view)
* we need the preconditioning in the 2pnc due to possible very low concentrations. Do we want to include that in the 2p2c misciblemultiphaseconstraintsolver as well? Then we should have the same solutions for 2p2c and 2pnc
* do we want to change the priVarsswitch values in 2p2c to the 2pnc values for consistency or is that unnecessary (does not change solution)?3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/441Make more methods constexpr2018-03-16T15:03:42ZKilian WeishauptMake more methods constexprIn the `O2` component class, all methods returning constant component properties are
declared `static constexpr`. We should apply this to all remaining component classes.
How about the methods in the `math.hh` header?
Should they also ...In the `O2` component class, all methods returning constant component properties are
declared `static constexpr`. We should apply this to all remaining component classes.
How about the methods in the `math.hh` header?
Should they also be `inline` and have a `noexcept` keyword?3.0https://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/443Make the difference between stationary and instationary problems more obvious2018-04-05T09:12:50ZTimo Kochtimokoch@math.uio.noMake the difference between stationary and instationary problems more obviousCurrently the assembler constructor decides whether a stationary or an instationary problem is assembled. This hides this feature a bit as there is only a difference in the arguments and no error if used inside a timeloop. Different clas...Currently the assembler constructor decides whether a stationary or an instationary problem is assembled. This hides this feature a bit as there is only a difference in the arguments and no error if used inside a timeloop. Different classes might make it more obvious, but might be a bit more code to implement.
* __Suggestion 1:__ Make error messages better and provide a terminal message what type of problem the assembler is assembling
* __Suggestion 2:__ Two different classes: The InstationaryAssembler could probably inherit almost everything from the StationaryAssembler, or both inherit from either only the assembler base class or from both assembler and an instationary assembler base class.3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/444Rename DiscretizationMethods to DiscretizationMethod (singular) and change fi...2018-03-02T10:07:17ZTimo Kochtimokoch@math.uio.noRename DiscretizationMethods to DiscretizationMethod (singular) and change fields to lower caseAccording to Dumux naming schemes and @bernd it should be
* `DiscretizationMethod` instead of ~~`DiscretizationMethods`~~
* `cctpfa` instead of ~~`CCTpfa`~~
* `box` instead of ~~`Box`~~
* ...According to Dumux naming schemes and @bernd it should be
* `DiscretizationMethod` instead of ~~`DiscretizationMethods`~~
* `cctpfa` instead of ~~`CCTpfa`~~
* `box` instead of ~~`Box`~~
* ...3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/445Dune::Hybrid does not compile with g++ 52018-02-14T14:44:10ZKilian WeishauptDune::Hybrid does not compile with g++ 5The new `NewtonSolver` class makes use of the `Dune::Hybrid` utilities.
Using g++5, this results in a compiler error while everything compiles fine with newer versions of g++.The new `NewtonSolver` class makes use of the `Dune::Hybrid` utilities.
Using g++5, this results in a compiler error while everything compiles fine with newer versions of g++.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/446[box] two-phase models may need an interface solver to prevent leakage into l...2018-04-17T08:25:13ZTimo Kochtimokoch@math.uio.no[box] two-phase models may need an interface solver to prevent leakage into lensesSee !582 for previous efforts.See !582 for previous efforts.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/447Multidomain module in 3.02018-07-12T21:03:00ZTimo Kochtimokoch@math.uio.noMultidomain module in 3.0* See !980 for module description.
* commit 57e85394c53563606c5356ab2bc2f6022ca79ed5 removed the old mixeddimension code on the next branch in case you need something for reference for the new implementation.
Here we can discuss furth...* See !980 for module description.
* commit 57e85394c53563606c5356ab2bc2f6022ca79ed5 removed the old mixeddimension code on the next branch in case you need something for reference for the new implementation.
Here we can discuss further wishes and ideas.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/448Discussion: Reintroduce model class as a way to specify model properties / Re...2023-12-13T11:13:09ZTimo Kochtimokoch@math.uio.noDiscussion: Reintroduce model class as a way to specify model properties / Remove TypeTag as template argument whereever feasibleI think it might make sense to reintroduce the model class as a place to specify things associated with a specific mathematical model, e.g. 2-phase 2-component porousmedium flow. In contrast to the old model class this class would know n...I think it might make sense to reintroduce the model class as a place to specify things associated with a specific mathematical model, e.g. 2-phase 2-component porousmedium flow. In contrast to the old model class this class would know nothing about the linear algebra (solution, Jacobian), temporal or spatial discretization. Its member functions / data members would probably ~~most~~ all be static and constexpr. An idea would be something like
```c++
namespace Properties {
SET_PROP(TwoPTwoC, Model)
{
private:
// Some easy customization points through the property system
using FluidSystem = GET_PROP_TYPE(TypeTag, FluidSystem);
using ...
public:
// there are quite many template arguments but they can be conveniently set through the property system
using type = TwoPNCModel<FluidSystem, FluidState, ...>;
};
} // end namespace Properties
template<FSystem, BalanceTraits, ...>
class TwoPNCModel
{
// model specific constants
static constexpr std::size_t numEq() { return 2; }
static constexpr std::size_t numComponents() { return FSystem::numComponents; }
....
// model specific options, template parameters offer customization points through Traits/Policies
static constexpr bool useMoles() { return BalanceTraits::useMoles(); }
...
// model specific types
enum class Index // might be also a struct templated by formulation
{
pressureIdx = 0,
saturationIdx = 1
};
...
// model specific functions
template<typename Scalar>
static constexpr void checkPhysicalBounds(Scalar priVar, Index i)
{ ... }
static constexpr void defaultParams(Dune::ParameterTree& params, const std::string& paramGroup = "")
{ ... }
...
};
```
Other classes could get the model as a template parameter and extract a lot of types and other information from it.Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/449Simplify porosity/permeability laws2018-04-05T13:16:02ZDennis GläserSimplify porosity/permeability lawsWe should get rid of the init() function in the permeability and porosity laws and pass the spatial params to the interface of the evaluate() function in order to avoid storing a spatial params pointer. Maybe could even not pass the spat...We should get rid of the init() function in the permeability and porosity laws and pass the spatial params to the interface of the evaluate() function in order to avoid storing a spatial params pointer. Maybe could even not pass the spatialParams at all, but provide all quantities that are necessary for the particular law to be evaluated. We should think about that.3.0Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/450BrineAir Fluidsystem problems2018-07-04T11:41:19ZSimon EmmertBrineAir Fluidsystem problems* [ ] vaporPressure does not depend on osmotic potential anymore:
Vishal introduced it like this:
```
static Scalar vaporPressure_(Scalar T, Scalar x)
{
Scalar p_0 = H2O::vaporPressure(T);//Saturation vapor pressure for ...* [ ] vaporPressure does not depend on osmotic potential anymore:
Vishal introduced it like this:
```
static Scalar vaporPressure_(Scalar T, Scalar x)
{
Scalar p_0 = H2O::vaporPressure(T);//Saturation vapor pressure for pure water
Scalar p_s = p_0; // modified saturation vapor pressure for saline water
// #if SALINIZATION
// Scalar vw = 18.0e-6;//[m3/mol] volume per unit mole of water
// Scalar R = 8.314;//[j/K mol] universal gas constant
// Scalar pi = (R * T * std::log(1- x))/vw;
// if (x > 0.26) // here we have hard coaded the solubility limit for NaCl
// pi = (R * T * std::log(0.74))/vw;
// p_s = p_0 * std::exp((pi*vw)/(R*T));// Kelvin's law for reduction in saturation vapor pressure due to osmotic potential
// #endif
return p_s;
}
```
Todo: Check if salinity has the desired influence where needed. Do always pass salinity, otherwise constantSalinity is used.3.0Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/451[task] Use the new `NewtonSolver`s in all tests2018-04-09T14:08:55ZTimo Kochtimokoch@math.uio.no[task] Use the new `NewtonSolver`s in all tests3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/452Definition of component in Dumux2018-03-02T10:07:22ZTimo Kochtimokoch@math.uio.noDefinition of component in DumuxThe current doc states a component is a 'pure chemical substance', so Air, Brine, Biofilm and any pseudo component wouldn't fulfill the concept -> it probably needs to be extended. I could also think of splitting the component interface ...The current doc states a component is a 'pure chemical substance', so Air, Brine, Biofilm and any pseudo component wouldn't fulfill the concept -> it probably needs to be extended. I could also think of splitting the component interface into solid (which currently doesn't exist), liquid, and gas related interface, e.g. as in !813.3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/453Introduce SolidSystem and SolidComponents2018-05-08T16:07:40ZKilian WeishauptIntroduce SolidSystem and SolidComponentsThe SolidSystem calculates quantities like solidHeatCapacity, solidDensity and solidHeatConductivity based on the compositions
of individual solid components such as `Granite` or `Sand`.
The concept uses the components' volume fractio...The SolidSystem calculates quantities like solidHeatCapacity, solidDensity and solidHeatConductivity based on the compositions
of individual solid components such as `Granite` or `Sand`.
The concept uses the components' volume fractions which are either solution dependent or fixed via the `spatialParameters`.
For simple cases, where there is only __one__ non-reactive solid component, the base spatialParams implement a `volumeFractions()` method that calls the `spatialParams` implementation's `porosity()` method and returns 1-porosity.
For other cases, this method throws an error and therefore forces the user to implement an own `volumeFaction()` in the `spatialParams`.
The solidSystem has an interface function `porosity()` depending on the solid composition, i.e. a `SolidState`.
This may be realized using some template meta programing magic.
Related to #452 #433 #450, fixes #409.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/454[task] Remove all deprecation warning related to Components2018-04-10T16:00:12ZTimo Kochtimokoch@math.uio.no[task] Remove all deprecation warning related to ComponentsComponents are now in the namespace `Components`. Components should now derive from `Base` and `Liquid`, `Gas`, and/or `Solid` depending on for what states they are implemented.Components are now in the namespace `Components`. Components should now derive from `Base` and `Liquid`, `Gas`, and/or `Solid` depending on for what states they are implemented.3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/455isValid cannot be used in constexpr in C++142018-03-02T10:07:22ZTimo Kochtimokoch@math.uio.noisValid cannot be used in constexpr in C++14The usage is restricted to how it's explained in the isValid doc. With C++17 the usage is extended as we can start to use the checking functions generated by isValid in constexpr settings which makes the syntax a bit less verbose.The usage is restricted to how it's explained in the isValid doc. With C++17 the usage is extended as we can start to use the checking functions generated by isValid in constexpr settings which makes the syntax a bit less verbose.3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/456Where to get ElementSolution type?2018-03-10T18:48:41ZTimo Kochtimokoch@math.uio.noWhere to get ElementSolution type?One crucial point in realizing #448, is to think about which types might be able to know about the ElementSolution type. In the current proposal !828, element solutions are dependent on the fvgridgeometry type (fixing discmethod, knows a...One crucial point in realizing #448, is to think about which types might be able to know about the ElementSolution type. In the current proposal !828, element solutions are dependent on the fvgridgeometry type (fixing discmethod, knows about mapper / connectivities), solutionvector type (elementsolution is a subset of a solution vector).3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/457Release 2.12: 3p3c diffusion is always zero2018-03-09T12:08:21ZKatharina HeckRelease 2.12: 3p3c diffusion is always zeroOn the release branch 2.12 the diffusion of 3p3c models is calculated in the local residual. There the molar density from the fluxvariables is used. However, in the 3p3c flux-vars the molar density is only initialized to 0 and never set....On the release branch 2.12 the diffusion of 3p3c models is calculated in the local residual. There the molar density from the fluxvariables is used. However, in the 3p3c flux-vars the molar density is only initialized to 0 and never set. Therefor all diffusive fluxes are 0.https://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/459Optionally pass spatialParams to problem in constructor2018-04-26T09:08:29ZTimo Kochtimokoch@math.uio.noOptionally pass spatialParams to problem in constructorI think it would be nice for flexibility to have another constructor for problems where the spatial params shared_ptr can be passed from outside. This way we could create a spatial params object outside e.g. with additional information l...I think it would be nice for flexibility to have another constructor for problems where the spatial params shared_ptr can be passed from outside. This way we could create a spatial params object outside e.g. with additional information like grid parameters (see #431) and the problem class doesn't need to know how to construct it.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/460Using generic lambda with trailing return type for isValid() fails with g++ <...2018-03-14T11:09:44ZKilian WeishauptUsing generic lambda with trailing return type for isValid() fails with g++ <= 5.3The `NewtonSolver` uses this kind of SFINAE technique which results in a compiler error for g++ <= 5.3
This is a known bug which has been fixed in g++5.4: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66135
``` c++
//! helper function d...The `NewtonSolver` uses this kind of SFINAE technique which results in a compiler error for g++ <= 5.3
This is a known bug which has been fixed in g++5.4: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66135
``` c++
//! helper function detecting if an assembler supports partial reassembly
template<class Assembler>
auto supportsPartialReassembly(const Assembler& assembler) noexcept
{
using SolutionVector = typename Assembler::ResidualType;
using Reassembler = PartialReassembler<Assembler>;
return isValid([](auto&& a) -> decltype(
a.assembleJacobianAndResidual(std::declval<Assembler>(),
std::declval<const SolutionVector&>(),
std::declval<const Reassembler*>())
){})(assembler);
}
```3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/461Dune::FMatrixPrecision<Scalar>::set_singular_limit() no longer exists2018-03-16T13:59:02ZKilian WeishauptDune::FMatrixPrecision<Scalar>::set_singular_limit() no longer existsThe method in the title was removed in Dune recently: https://gitlab.dune-project.org/core/dune-common/commit/f9ab2e53b05a502d613741e2dc3245528adf9441
Test including the headers
```
dumux/material/constraintsolvers/compositionfromfugaci...The method in the title was removed in Dune recently: https://gitlab.dune-project.org/core/dune-common/commit/f9ab2e53b05a502d613741e2dc3245528adf9441
Test including the headers
```
dumux/material/constraintsolvers/compositionfromfugacities.hh
dumux/material/constraintsolvers/immiscibleflash.hh
dumux/material/constraintsolvers/ncpflash.hh
```
now fail to build.
Do we want to use
``` c++
void set_absolute_limit (ctype absthres)
```
instead?3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/462Changelog for 3.02018-12-17T12:13:26ZTimo Kochtimokoch@math.uio.noChangelog for 3.0This is supposed to be a collection of things that changed in version 3.0. We also planned to write a little guide on the newly introduced things concerning implementers of problem/spatialparams/mainfile/materiallaws.This is supposed to be a collection of things that changed in version 3.0. We also planned to write a little guide on the newly introduced things concerning implementers of problem/spatialparams/mainfile/materiallaws.3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/463Rethink isothermal/mineralization type tags2018-03-19T13:15:14ZDennis GläserRethink isothermal/mineralization type tagsIn order to realize non-isothermal models, type tags inherit from the non-isothermal type tag and one has to set the properties IsothermalIndices, IsothermalNumEq etc. The actual types/values are then determined by the non-isothermal typ...In order to realize non-isothermal models, type tags inherit from the non-isothermal type tag and one has to set the properties IsothermalIndices, IsothermalNumEq etc. The actual types/values are then determined by the non-isothermal type tag.
Alternatively, one could also directly set the non-isothermal types (e.g. EnergyIndices<OnePIndices>), because the current way neither saves code nor does it improve readability. Since mineralization models use a similar pattern, in non-isothermal mineralization models it is particularly difficult to see which type is set/used.
Also, we would get rid of all properties like IsothermalIndices, IsothermalVolumeVariables, ..., NonMineralizationVtkOutputFields, NonMineralizationVolumeVariables ...3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/464Include liquidMolarDensity in component LNAPL2018-04-03T12:34:07ZSimon EmmertInclude liquidMolarDensity in component LNAPLWe introduced liquidMolarDensity and gasMolarDensity in all components in !498. For the component LNAPL we did not know what the molarDensity is, since it does not have a molarMass.
* [ ] look up molar mass for some kind of oil that fi...We introduced liquidMolarDensity and gasMolarDensity in all components in !498. For the component LNAPL we did not know what the molarDensity is, since it does not have a molarMass.
* [ ] look up molar mass for some kind of oil that fits here
* [ ] implement liquidMolarDensity according to !4983.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/465simplesteamaircao2h2.hh and steamn2cao2h2 are not tested at the moment2018-04-25T22:00:35ZSimon Emmertsimplesteamaircao2h2.hh and steamn2cao2h2 are not tested at the moment@heck and I realized while implementing molarDensities that ``simplesteamaircao2h2.hh`` and ``steamn2cao2h2.hh`` are not used in any tests we could find on master. Is that correct?
Should we still keep it? If yes, we propose to use it ...@heck and I realized while implementing molarDensities that ``simplesteamaircao2h2.hh`` and ``steamn2cao2h2.hh`` are not used in any tests we could find on master. Is that correct?
Should we still keep it? If yes, we propose to use it in a test and also implement the ``molarDensity()`` in ``simplesteamaircao2h2.hh`` as it is done in !498.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/466Replace `LNAPL` component by Components::Constant2018-04-04T14:29:50ZTimo Kochtimokoch@math.uio.noReplace `LNAPL` component by Components::ConstantThe LNAPL component has currently an arbitrary fixed density a bit lower than water. It can be simply replaced by constant component and then the density is a variable in the input file.The LNAPL component has currently an arbitrary fixed density a bit lower than water. It can be simply replaced by constant component and then the density is a variable in the input file.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/467Rename `DNAPL` to `Trichloroethene`2018-04-04T14:29:52ZTimo Kochtimokoch@math.uio.noRename `DNAPL` to `Trichloroethene`The DNAPL class actually implement the component Trichloroethene and should be accordingly renamed. Also the filename has to be renamed and the name() member function should return Trichloroethene or TCE.The DNAPL class actually implement the component Trichloroethene and should be accordingly renamed. Also the filename has to be renamed and the name() member function should return Trichloroethene or TCE.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/468[components] Cannot throw Dune::NotImplemented in constexpr and need return s...2018-04-04T15:54:27ZTimo Kochtimokoch@math.uio.no[components] Cannot throw Dune::NotImplemented in constexpr and need return statementThe components cannot throw a not implemented error. Gcc seems to accept it but clang doesn't and seems to be correct. The return statement is required. Suggestion
```c++
static_assert(AlwaysFalse<T>::value, "NotImplemented"); // as bef...The components cannot throw a not implemented error. Gcc seems to accept it but clang doesn't and seems to be correct. The return statement is required. Suggestion
```c++
static_assert(AlwaysFalse<T>::value, "NotImplemented"); // as before
return 0; // unreachable // include this line with comment
```3.0Kilian WeishauptKilian Weishaupthttps://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/470Extract GlobalPosition from Grid2018-05-03T14:38:00ZDennis GläserExtract GlobalPosition from GridThere are many places where the global position type is locally defined as:
```cpp
using GlobalPosition = Dune::FieldVector<Scalar, dimWorld>;
```
We maybe should think about extracting it from the Element (i.e. Element::Geometry::Glob...There are many places where the global position type is locally defined as:
```cpp
using GlobalPosition = Dune::FieldVector<Scalar, dimWorld>;
```
We maybe should think about extracting it from the Element (i.e. Element::Geometry::GlobalCoordinate) or from the sub-control
volumes and sub-control volume faces (which itself should have been given the type extracted from the grid).
This is especially important when Scalar and ctype are not the same.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/471Implement non-conforming output for box with interface solver2018-04-25T16:15:41ZDennis GläserImplement non-conforming output for box with interface solverAs soon as we have an interface solver (!907), we should think about how to visualize correctly the results. The original idea was element-averaged saturations, but an alternative could be nodal, but nonconforming vtk output.As soon as we have an interface solver (!907), we should think about how to visualize correctly the results. The original idea was element-averaged saturations, but an alternative could be nodal, but nonconforming vtk output.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/472Warning for pv python code in rans test2018-04-15T21:51:09ZTimo Kochtimokoch@math.uio.noWarning for pv python code in rans testtest_pipe_laufer compiles with the following warning under g++7
```
/home/timok/dumux-course/dumux/test/freeflow/rans/test_pipe_laufer.cc: In function 'int main(int, char**)':
/home/timok/dumux-course/dumux/test/freeflow/rans/test_pipe_l...test_pipe_laufer compiles with the following warning under g++7
```
/home/timok/dumux-course/dumux/test/freeflow/rans/test_pipe_laufer.cc: In function 'int main(int, char**)':
/home/timok/dumux-course/dumux/test/freeflow/rans/test_pipe_laufer.cc:227:15: warning: ignoring return value of 'int system(const char*)', declared with attribute warn_unused_result [-Wunused-result]
system(syscom.c_str());
~~~~~~^~~~~~~~~~~~~~~~
```
looks like the result of the system call shouldn't be ignored.
Why do we need the system call at all? Can't we have CMake to executing the post processing script (if it's for testing)? Otherwise just leave it to the user if he wants to execute the post processing?
If you call it from C++ code there is also a paraview C++ API for that.Thomas FetzerThomas Fetzerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/473Why do fluid systems state wetting/non-wetting phases/components?2018-04-16T15:42:33ZTimo Kochtimokoch@math.uio.noWhy do fluid systems state wetting/non-wetting phases/components?The decision whether a phase is wetting or non-wetting shouldn't be made by the fluid system, as it depends on the porous matrix.The decision whether a phase is wetting or non-wetting shouldn't be made by the fluid system, as it depends on the porous matrix.3.0https://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/475[test] Implement test with hydrophobic region2018-04-27T17:07:16ZTimo Kochtimokoch@math.uio.no[test] Implement test with hydrophobic regionWith !892 we now have the possibility to define hydrophobic regions using the spatialparams member function `wettingPhase()`.
Implement a test such that the feature is tested.With !892 we now have the possibility to define hydrophobic regions using the spatialparams member function `wettingPhase()`.
Implement a test such that the feature is tested.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/476[task] Implement paramGroup for problems2018-04-19T07:09:01ZTimo Kochtimokoch@math.uio.no[task] Implement paramGroup for problemsthe base problem should store and return the parameter group for retrieving runtime parameters. This parameter is optional so the change in the base problem will be fully compatible with the current test problem that don't use a paramete...the base problem should store and return the parameter group for retrieving runtime parameters. This parameter is optional so the change in the base problem will be fully compatible with the current test problem that don't use a parameter group.3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/351Replace gas viscosity calculations2023-12-13T11:13:08ZBernd FlemischReplace gas viscosity calculationsSee #333. What is done for air, can also be done for N2, O2, ...See #333. What is done for air, can also be done for N2, O2, ...Holger ClassHolger Classhttps://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/354New BC and SpatialParams interfaces2019-02-26T20:27:07ZBernd FlemischNew BC and SpatialParams interfacesThis is related to #350, !274 and !276.
Can we finalize the new interfaces for the boundary/initial conditions and spatial parameters?
I currently find the following for the BC/IC:
```
BoundaryTypes boundaryTypes(Element, SubContro...This is related to #350, !274 and !276.
Can we finalize the new interfaces for the boundary/initial conditions and spatial parameters?
I currently find the following for the BC/IC:
```
BoundaryTypes boundaryTypes(Element, SubControlVolume)
BoundaryTypes boundaryTypes(Element, SubControlVolumeFace)
BoundaryTypes boundaryTypesAtPos(GlobalPosition)
PrimaryVariables dirichlet(Element, SubControlVolume)
PrimaryVariables dirichlet(Element, SubControlVolumeFace)
PrimaryVariables dirichletAtPos(GlobalPosition)
PrimaryVariables neumann(Element, FVElementGeometry, ElementVolumeVariables, SubControlVolumeFace)
PrimaryVariables neumannAtPos(GlobalPosition)
PrimaryVariables source(Element, FVElementGeometry, ElementVolumeVariables, SubControlVolume)
PrimaryVariables sourceAtPos(GlobalPosition)
PrimaryVariables initial(SubControlVolume)
PrimaryVariables initialAtPos(GlobalPosition)
int initialPhasePresence(Vertex, int, GlobalPosition)
void initialPhasePresenceAtPos(GlobalPosition)
```
We should make the `initial...` ones consistent with the other ones. Like this?:
```
PrimaryVariables initial(Element, SubControlVolume)
PrimaryVariables initialAtPos(GlobalPosition)
int initialPhasePresence(Element, SubControlVolume)
int initialPhasePresenceAtPos(GlobalPosition)
```
Can we consider this as final?
What about the spatial parameters?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/340Find better result checking for tests with adaptive grids2020-04-30T13:05:02ZTimo Kochtimokoch@math.uio.noFind better result checking for tests with adaptive gridsAdaptive grids resulting from indicator based on thresholds don't necessarily result in the same grid on a different machine.
* Vtu-comparison should be therefore disabled
* Other measures and indicator might be comparable better (need t...Adaptive grids resulting from indicator based on thresholds don't necessarily result in the same grid on a different machine.
* Vtu-comparison should be therefore disabled
* Other measures and indicator might be comparable better (need to be identified)
* Residual-based indicators, or any thresholds computed from primary variables might be better suited for testinghttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/320Implementation of dispersion2021-11-24T10:35:58ZAlexander KissingerImplementation of dispersionA dispersion interface should be implemented that hopefully works for all discretizations.
## Old flyspray description
#### Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by |...A dispersion interface should be implemented that hopefully works for all discretizations.
## Old flyspray description
#### Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Alexander Kissinger (alexander.kissinger@iws.uni-stuttgart.de) |
| Reported at | Mar 30, 2016 15:18 |
| Type | Bug Report |
| Version | 2.9 |
#### Description
I noticed that the implementation of dispersion in the 1p2c model may not be correct for applications using the cell centered discretization.
The dispersion tensor needs to be evaluated at the interface between two dofs. It requires the velocity at that location.
For the Box method this can easily be achieved using the potential gradient evaluated from multiple dofs in the element. For the CC method however the potential gradient calculated currently at the interface only depends on the two opposing dofs (i and j). This will generally not result in the correct velocity.
A correct implementation would require an interpolation of the two cell velocities i and j at the interface.
Example:
Flow parallel to the interface between i and j would result in a zero velocity at the interface as there is no potential gradient between i and j and the velocity component parallel to the interface is not considered. As a result also the transverse dispersion would be zero.Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/319FS#319 [MaterialLaws] Generalize EffToAbsLaw, Regularization2020-10-30T18:10:39ZKilian WeishauptFS#319 [MaterialLaws] Generalize EffToAbsLaw, Regularization# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Material framwork |
| Reported by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Reported at | Mar 10, 2016 16:00 |
| Type ...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Material framwork |
| Reported by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Reported at | Mar 10, 2016 16:00 |
| Type | DuMuX day |
| Version | Git |
| Last edited by | Johannes Hommel (johannes.hommel@iws.uni-stuttgart.de) |
| Last edited at | Sep 15, 2016 11:54 |
# Description
It should be possible for the user to use a definition
like
using MaterialLaw = VanGenuchten<TypeTag>
The Params should have a default constructor setting the way of regularization and the conversion from absolute to relative quantities.
Both procedures could be generalized.
The materiallaw gets the absolute value and calls a method to convert it to a relative one (defined in a general class). Similarly a method for regularization defined in a general class is called by the materiallaw itself.
This reduces the number of classes required and makes everything more clear.3.3Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/317FS#317 More use of copydoc in material2018-07-11T10:08:46ZAlexander KissingerFS#317 More use of copydoc in material# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Documentation |
| Reported by | Alexander Kissinger (alexander.kissinger@iws.uni-stuttgart.de) |
| Reported at | Mar 8, 2016 08:57 |
| Type | ...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Documentation |
| Reported by | Alexander Kissinger (alexander.kissinger@iws.uni-stuttgart.de) |
| Reported at | Mar 8, 2016 08:57 |
| Type | DuMuX day |
| Version | Git |
| Last edited by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Last edited at | Jul 26, 2016 08:26 |
# Description
There is still some duplicate doxygen documentation in the material folder, for example the FluidState set-functions all have the same documentation.
This could be a task for an upcoming Dumux day or a Hiwi.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/314FS#314 test_adaptive2p2c2d has invalid downcast2018-07-20T15:00:16ZChristoph GrüningerFS#314 test_adaptive2p2c2d has invalid downcast# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Feb 23, 2016 16:32 |
| Type | Bug Report |
| V...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Feb 23, 2016 16:32 |
| Type | Bug Report |
| Version | Git |
# Description
```
test_adaptive2p2c2d with undefined behavior sanitizer gives an error about an illegal cast:
dumux/dumux/porousmediumflow/sequential/impetproblem.hh:836:15: runtime error: downcast of address 0x7ffe0d58ba10 which does not point to an object of type 'Adaptive2p2c2d'
0x7ffe0d58ba10: note: object has invalid vptr
00 00 00 00 00 00 00 00 00 00 00 00 78 50 aa 31 d9 7f 00 00 60 e6 7e 03 00 00 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
invalid vptr
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/310FS#310 Implement interdigitated flow fields for electrochemistry module2019-02-26T20:24:43ZKilian WeishauptFS#310 Implement interdigitated flow fields for electrochemistry module# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Reported at | Jan 27, 2016 12:41 |
| Type | Feature Req...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Reported at | Jan 27, 2016 12:41 |
| Type | Feature Request |
| Version | Git |
# Description
So far, the electrochemistry module can only handle conventional flow fields where the transport of oxygen is driven only by diffusion.
In contrast to that the transport occurs also by advection in interdigitated flow fields.
Implementing the possibility to handle such flow fields in dumux-lecture
could be a job for a HiWi.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/296FS#296 Shallow water model2018-05-07T14:12:49ZMartin SchneiderFS#296 Shallow water model# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Martin Schneider (martin.schneider@iws.uni-stuttgart.de) |
| Reported at | Sep 29, 2015 11:53 |
| Type | Feature Req...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Martin Schneider (martin.schneider@iws.uni-stuttgart.de) |
| Reported at | Sep 29, 2015 11:53 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Last edited at | Jan 22, 2016 09:36 |
# Description
I have modified the old version of the shallow water model (implemented by Anne and Markus) such that it runs with the current dumux version.
Nevertheless, before adding it to the dumux-lecture module, we should change some "outdated" parts.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/275FS#275 Easier handling of boundary conditions and sources2019-02-26T20:22:57ZBernd FlemischFS#275 Easier handling of boundary conditions and sources# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Jul 3, 2015 09:14 |
| Type | Feature Request |
| Versi...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Jul 3, 2015 09:14 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Johannes Hommel (johannes.hommel@iws.uni-stuttgart.de) |
| Last edited at | Jul 14, 2016 14:08 |
# Description
Currently, boundary conditions and sources have to be assigned in the problem file. While it is possible to bring in run-time information with the parameter system, we don't have a uniform way of doing this. We should try to find one.
Requiring Dune 2.4 will facilitate this since it enables to hand over vectors to the ParameterTree.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/264FS#264 Adaptivity with Parallelization2023-12-13T11:13:09ZMartin SchneiderFS#264 Adaptivity with Parallelization# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Implicit models |
| Reported by | Martin Schneider (martin.schneider@iws.uni-stuttgart.de) |
| Reported at | May 5, 2015 06:40 |
| Type | Feat...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Implicit models |
| Reported by | Martin Schneider (martin.schneider@iws.uni-stuttgart.de) |
| Reported at | May 5, 2015 06:40 |
| Type | Feature Request |
| Version | 2.7 |
# Description
The adaptive implicit problems are not yet implementented for parallelization.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/249FS#249 Names and units in the fluidsystems/components2018-07-11T09:58:46ZThomas FetzerFS#249 Names and units in the fluidsystems/components# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Thomas Fetzer (thomas.fetzer@iws.uni-stuttgart.de) |
| Reported at | Dec 5, 2014 09:52 |
| Type | DuMuX day |
| Vers...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Thomas Fetzer (thomas.fetzer@iws.uni-stuttgart.de) |
| Reported at | Dec 5, 2014 09:52 |
| Type | DuMuX day |
| Version | Git |
| Last edited by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Last edited at | Mar 22, 2016 11:07 |
# Description
```
I've just noticed, that some units are wrong in the fluidsystems.hh and components.hh. E.g. the specific heat capacity has the unit J/(kg*K) and not J/kg. Maybe the confusion comes from the wrong function name, which is gasHeatCapacity and not specificIsobaricGasHeatCapacity. So I propose to:
1) change the function names to what is actually returned by the function
2) check the units
But I fear, that this could be a relative huge task, as this affects also volume and fluxvariables:
3) Add units/ change names also in the flux/volumevariables
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/242FS#242 move decoupled 1p2c to stable2018-07-11T10:07:44ZBernd FlemischFS#242 move decoupled 1p2c to stable# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Nov 7, 2014 12:56 |
| Type | Bug Report |
| Version | ...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Nov 7, 2014 12:56 |
| Type | Bug Report |
| Version | Git |
| Last edited by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Last edited at | Jan 22, 2016 10:12 |
# Description
ditohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/214FS#214 Implement naming rules for class names2023-12-13T11:13:07ZBernd FlemischFS#214 Implement naming rules for class names# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Nov 4, 2013 09:34 |
| Type | Feature Request |
| Versi...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Nov 4, 2013 09:34 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Last edited at | Jan 22, 2016 10:18 |
# Description
From 2.3 to 2.4, all member functions and enums have been adapted to our naming conventions. We want to evaluate how we want to do this for class names. Currently, we have inconsistencies like TwoPTwoCNI and Stokes2cni. We discuss in particular the issue about digits in class names.
Newer compilers should provide easier deprecation possibilities. An example will follow.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/210FS#210 enthalpy of dissolved component2023-12-13T11:13:08ZFSFS#210 enthalpy of dissolved component# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Fluid systems |
| Reported by | Philipp Nuske (philipp.nuske@iws.uni-stuttgart.de) |
| Reported at | Oct 16, 2013 08:40 |
| Type | Potential T...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Fluid systems |
| Reported by | Philipp Nuske (philipp.nuske@iws.uni-stuttgart.de) |
| Reported at | Oct 16, 2013 08:40 |
| Type | Potential Thesis/Job |
| Version | Git |
| Last edited by | Nicolas Schwenck (nicolas.schwenck@iws.uni-stuttgart.de) |
| Last edited at | Sep 22, 2015 06:52 |
# Description
In the fluidsystems currently used in \\\\\\\\Dumux (those that do not use tables), the enthalpy of the dissolved component is either neglected (e.g. n2 in H2O in h2on2fluidsystem) or the enthalpy of the gas state is used (h2on2fluidsystemkinetic).
In either case the enthalpy of dissolution http://en.wikipedia.org/wiki/Enthalpy_change_of_solution is neglected.
If this is on purpose, it should be somewhere documented.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/134FS#134 reintroduce the physical-functions2020-09-30T08:53:30ZNicolas SchwenckFS#134 reintroduce the physical-functions# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Nicolas Schwenck (nicolas.schwenck@iws.uni-stuttgart.de) |
| Reported at | Feb 24, 2012 14:35 |
| Type | Feature Req...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Nicolas Schwenck (nicolas.schwenck@iws.uni-stuttgart.de) |
| Reported at | Feb 24, 2012 14:35 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Last edited at | Sep 19, 2016 10:55 |
# Description
What happened to the functions which take care that no unphysical values, e.g, negative saturations appear?3.3https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/362Need for Porousmediumflow/Freeflow/Porenetwork type tag2018-04-18T12:43:26ZTimo Kochtimokoch@math.uio.noNeed for Porousmediumflow/Freeflow/Porenetwork type tagMany properties that are grouped under `Implicit` (especially many new ones on `next`) are only useful for porousmediumflow problem. Further they are not restricted to an implicit time discretization. We should introduce a `Porousmediumf...Many properties that are grouped under `Implicit` (especially many new ones on `next`) are only useful for porousmediumflow problem. Further they are not restricted to an implicit time discretization. We should introduce a `Porousmediumflow` Typetag that porousmedium flow models derive from. Many of the properties introduces for each sub model are actually also shared by all/most porousmediumflow models.
The same holds for freeflow / porenetwork / geomechanics.
Related to this: Some implicit properties might actually be independent of the time discretization as well and could be moved to the base properties.
* [x] Porousmediumflow
* [ ] Porenetworkflow
* [x] Freeflow
* [ ] Geomechanicshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/357Implement staggered grid free flow model2018-04-18T12:43:27ZKilian WeishauptImplement staggered grid free flow modelTodo:
- [ ] FluxVars and LocalResidual
- [x] Add support for component transport
- [x] Add support for energy transport
- [ ] Account for extrusion factor
- [ ] fluxes (see !451)
- [x] storage terms
- [ ] Add 2D friction term t...Todo:
- [ ] FluxVars and LocalResidual
- [x] Add support for component transport
- [x] Add support for energy transport
- [ ] Account for extrusion factor
- [ ] fluxes (see !451)
- [x] storage terms
- [ ] Add 2D friction term to mimic 3D flow
- [ ] Implement better tests (e.g. 3D, transient, backward-facing step, etc.)
Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/267FS#267 MPI exit with error: MPI_Op_free after MPI_FINALIZE2018-04-18T12:43:27ZChristoph GrüningerFS#267 MPI exit with error: MPI_Op_free after MPI_FINALIZE# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | May 22, 2015 08:08 |
| Type | Bug Report |
| V...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | May 22, 2015 08:08 |
| Type | Bug Report |
| Version | Git |
| Last edited by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Last edited at | Jul 10, 2015 14:04 |
| Closed by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Closed at | Jul 10, 2015 14:04 |
| Closed in version | unknown (Id=0) |
| Resolution | Fixed |
# Description
```
Some tests exit with an MPI error. The cause of this problem is unknown to me. It happens for example in decoupled/test_3d2p:
8: *** The MPI_Op_free() function was called after MPI_FINALIZE was invoked.
8: *** This is disallowed by the MPI standard.
8: *** Your MPI job will now abort.
8: [linux:31588] Local abort after MPI_FINALIZE completed successfully; not able to aggregate error messages, and not able to guarantee that all other processes were killed!
8: Return code: 1
The code does not run in parallel, maybe it is an ALUGrid issue?!
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/288FS#288 Base fuel-cell example from lecture on 2pnc stable2018-04-18T12:43:27ZBernd FlemischFS#288 Base fuel-cell example from lecture on 2pnc stable# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Aug 24, 2015 10:15 |
| Type | Feature Request |
| Vers...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Aug 24, 2015 10:15 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Last edited at | Aug 28, 2015 09:42 |
| Closed by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Closed at | Aug 28, 2015 09:42 |
| Closed in version | 2.8 |
| Resolution | Implemented |
# Description
The example in dumux-lecture/lecture/mm/fuelcell uses its own 2pnc model. This was necessary as long as 2pnc was part of dumux-devel. Since it is included in stable by now, it should be possible to use it from there.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/353Inconsistent `index()` method of the different `SubControlVolume` classes2018-04-18T12:43:27ZBernd FlemischInconsistent `index()` method of the different `SubControlVolume` classesThe `index()` method in `discretization/cellcentered` returns the global element index, while the one in `discretization/box` returns the local scv index. Storing the local index information would be useful.The `index()` method in `discretization/cellcentered` returns the global element index, while the one in `discretization/box` returns the local scv index. Storing the local index information would be useful.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/266FS#266 Add decoupled 2p 3d test cases to CMake2018-04-18T12:43:27ZBernd FlemischFS#266 Add decoupled 2p 3d test cases to CMake# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Decoupled models |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | May 21, 2015 11:03 |
| Type | Feature Request...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Decoupled models |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | May 21, 2015 11:03 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | May 22, 2015 08:06 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | May 22, 2015 08:06 |
| Closed in version | 2.8 |
| Resolution | Implemented |
# Description
There exist 3d test cases for the decoupled 2p model that have not been added to CMake yet.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/287FS#287 Unify doxygen comments for properties2018-04-18T12:43:27ZKilian WeishauptFS#287 Unify doxygen comments for properties# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Reported at | Aug 21, 2015 14:38 |
| Type | Bug Report ...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Reported at | Aug 21, 2015 14:38 |
| Type | Bug Report |
| Version | Git |
| Last edited by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Last edited at | Jan 22, 2016 09:48 |
| Closed by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Closed at | Jan 22, 2016 09:48 |
| Closed in version | 2.9 |
| Resolution | Won't implement |
# Description
In doxygen's Dumux::Properties Namespace Reference,for several properties (e.g., Fluidsytem) a multitude of different comments have been assigned in the various models.
These comments should be unified so that there will be only one single comment for each property.
We should probably use the opportunity to do this while changing the folder structure after 2.7.
Since various properties will be declared on a higher level for several models, this will automatically reduce redundancy and the number of different comments for the same property.
Only some "special" properties that are only used by certain models might have to be changed manually.
So far, the following properties have multiple comments:
Property tag Dumux::Properties::WettingPhase
Property tag Dumux::Properties::VtkAddVelocity
Property tag Dumux::Properties::VisitFacesOnlyOnce
Property tag Dumux::Properties::VertexMapper
Property tag Dumux::Properties::VelocityFormulation
Property tag Dumux::Properties::VelocityAveragingInModel
Property tag Dumux::Properties::UseMoles
Property tag Dumux::Properties::UseConstraintSolver
Property tag Dumux::Properties::TimeManagerMaxTimeStepSize
Property tag Dumux::Properties::TimeManager
Property tag Dumux::Properties::SpatialParamsForchCoeff
Property tag Dumux::Properties::SpatialParams
Property tag Dumux::Properties::SolutionVector
Property tag Dumux::Properties::SaturationFormulation
Property tag Dumux::Properties::ReplaceCompEqIdx
Property tag Dumux::Properties::ProblemEnableGravity
Property tag Dumux::Properties::PressureGridFunctionSpace
Property tag Dumux::Properties::PressureFormulation
Property tag Dumux::Properties::PressureFEM
Property tag Dumux::Properties::PhaseIdx
Property tag Dumux::Properties::NumPhases
Property tag Dumux::Properties::NumComponents
Property tag Dumux::Properties::NonwettingPhase
Property tag Dumux::Properties::NewtonWriteConvergence
Property tag Dumux::Properties::NewtonUseLineSearch
Property tag Dumux::Properties::NewtonTargetSteps
Type tag Dumux::Properties::NewtonMethod
Property tag Dumux::Properties::NewtonController
Property tag Dumux::Properties::Model
Property tag Dumux::Properties::MaterialLawParams
Property tag Dumux::Properties::MaterialLaw
Property tag Dumux::Properties::LinearSolverVerbosity
Property tag Dumux::Properties::LinearSolverBlockSize
Property tag Dumux::Properties::JacobianMatrix
Property tag Dumux::Properties::JacobianAssembler
Property tag Dumux::Properties::Indices
Property tag Dumux::Properties::ImplicitNumericDifferenceMethod
Property tag Dumux::Properties::ImplicitMobilityUpwindWeight
Property tag Dumux::Properties::ImplicitMassUpwindWeight
Property tag Dumux::Properties::ImplicitEnablePartialReassemble
Property tag Dumux::Properties::ImplicitEnableHints
Property tag Dumux::Properties::ImpetErrorTermUpperBound
Property tag Dumux::Properties::ImpetErrorTermLowerBound
Property tag Dumux::Properties::ImpetErrorTermFactor
Property tag Dumux::Properties::GridOperatorSpace
Property tag Dumux::Properties::GridOperator
Property tag Dumux::Properties::GridAdaptEnableInitializationIndicator
Property tag Dumux::Properties::Grid
Property tag Dumux::Properties::FluidSystem
Property tag Dumux::Properties::FluidState
Property tag Dumux::Properties::Fluid
Property tag Dumux::Properties::DisplacementGridFunctionSpace
Property tag Dumux::Properties::DisplacementFEM
Property tag Dumux::Properties::CellData
Property tag Dumux::Properties::BaseModel
Property tag Dumux::Properties::BaseFluxVariables
Maybe it would be a good idea to form a group (similar to the handbook team) in order to discuss which comments should be used and/or improved.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/352Initial phase presence for cell-centered models gets evaluated always with fi...2018-04-18T12:43:27ZTimo Kochtimokoch@math.uio.noInitial phase presence for cell-centered models gets evaluated always with first grid vertexSuggestion: the signature of `inititalPhasePresence` should be different for box and cc discretizations. Like `dirichlet`.
See e.g. https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/blob/master/dumux/porousmediumflow/3pwateroil/...Suggestion: the signature of `inititalPhasePresence` should be different for box and cc discretizations. Like `dirichlet`.
See e.g. https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/blob/master/dumux/porousmediumflow/3pwateroil/model.hh line 183
for an example.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/265FS#265 Decoupled 2p2c does not run in parallel2018-04-18T12:43:27ZBernd FlemischFS#265 Decoupled 2p2c does not run in parallel# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Decoupled models |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | May 21, 2015 10:49 |
| Type | Bug Report |
| ...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Decoupled models |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | May 21, 2015 10:49 |
| Type | Bug Report |
| Version | Git |
| Last edited by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Last edited at | May 27, 2015 14:50 |
| Closed by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Closed at | May 27, 2015 14:50 |
| Closed in version | 2.8 |
| Resolution | Won't fix |
# Description
Trying to run the decoupled 2p2c test case in parallel results at least in wrong output. While the pvd-file contains pointers to correct parallel pvtu-file names, only sequential vtu-files are written.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/350Change BC/IC (SpatialParams?) interfaces in a backward-compatible manner2018-04-18T12:43:27ZBernd FlemischChange BC/IC (SpatialParams?) interfaces in a backward-compatible mannerThe `next`branch changes the interface of the boundary/initial conditions and spatial parameters. Evaluate if these changes can be done in a backward-compatible way. Ideally, compiling problems and spatialparams using the old interfaces ...The `next`branch changes the interface of the boundary/initial conditions and spatial parameters. Evaluate if these changes can be done in a backward-compatible way. Ideally, compiling problems and spatialparams using the old interfaces should only give deprecation warnings.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/263FS#263 Don't build executables on make test2018-04-18T12:43:27ZTimo Kochtimokoch@math.uio.noFS#263 Don't build executables on make test# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | CMake |
| Reported by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Reported at | Apr 17, 2015 11:10 |
| Type | Feature Request |
| Version...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | CMake |
| Reported by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Reported at | Apr 17, 2015 11:10 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Feb 23, 2016 08:28 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Feb 23, 2016 08:28 |
| Closed in version | 2.9 |
| Resolution | Deferred |
# Description
```
The CMake way to do this is
make all
make test
where make all builds all executables, make test RUNS the tests.
Some Dune magic can be used to compile all tests on make test.
This has the disadvantage that all tests build also if only one test is desired to run (with ctest -R my_test). This only occurs when there are more than one test in the same directory.
The CMake way has advantages that get lost by contracting build and execution:
- In an automated build the compilation and execution can fail/pass separately
- One test can be build and executed if desired (make my_test, ctest -R my_test)
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/346[doc] Linear solver description2018-04-18T12:43:27ZTimo Kochtimokoch@math.uio.no[doc] Linear solver descriptionMany users - including me -- don't know the advantages, disadvantages, requirements to matrix of all the solvers and preconditioners we support.
Can we add some hints to the Solver Backend classes?Many users - including me -- don't know the advantages, disadvantages, requirements to matrix of all the solvers and preconditioners we support.
Can we add some hints to the Solver Backend classes?Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/262FS#262 Add possibility to install DuMuX using CMake2018-04-18T12:43:27ZChristoph GrüningerFS#262 Add possibility to install DuMuX using CMake# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | CMake |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Apr 16, 2015 09:43 |
| Type | Feature Request |
...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | CMake |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Apr 16, 2015 09:43 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Sep 16, 2015 05:30 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Sep 16, 2015 05:30 |
| Closed in version | 2.8 |
| Resolution | Implemented |
# Description
```
All Dune core modules can be installed. DuMuX' CMakeLists.txt are missing the install directives.
As most LH2 users don't install, we still have use cases:
- there are users wishing to install Dune modules. At least for the core modules there are frequent bug reports when someone breaks this feature.
- it is necessary for creating RPMs with the Open Build Service.
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/344[next] Transitioning to new dumux assembly, geometry, global-local concept2018-04-18T12:43:27ZTimo Kochtimokoch@math.uio.no[next] Transitioning to new dumux assembly, geometry, global-local conceptA new implementation for assembly,finite volume geometry, global-local concept is available on branch `next`.
I think to efficiently transition we need to
1. port existing model to make the code more robust and working with as many m...A new implementation for assembly,finite volume geometry, global-local concept is available on branch `next`.
I think to efficiently transition we need to
1. port existing model to make the code more robust and working with as many modelling situations as possible, this means specifically
-> models should either be based on the `last dumux release 2.10/2.11` or be ported to the new infrastructure to keep adjustments to master branch minimal
2. Postpone cleanup and beautification tasks on master and do them only on the `next` branch (avoid double the work)
3. Port bugfixes and essential improvements made on master to the `next` branch (we have to do double the work)
4. Mark feature requests / issues that will be only fixed on `next`
We should discuss whether there should be a last release of the old version working with `Dune 2.5` soon. Then the next branch should become the new master and old code will be based on the `releases/2.11` branch which we should support with bugfixes for a while.
There should be a documentation on how to port a model and how to port a problem. This can be done after it is decided how to design the spatial params and the vkt output.2017-10-27https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/261FS#261 Misnomer evalPhaseStorage in couplinglocalresiduals2018-04-18T12:43:27ZBernd FlemischFS#261 Misnomer evalPhaseStorage in couplinglocalresiduals# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Apr 15, 2015 08:54 |
| Type | Bug Report |
| Version |...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Apr 15, 2015 08:54 |
| Type | Bug Report |
| Version | Git |
| Last edited by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Last edited at | May 28, 2015 10:41 |
| Closed by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Closed at | May 28, 2015 10:41 |
| Closed in version | 2.8 |
| Resolution | Implemented |
# Description
The 2p2c(ni) couplinglocalresiduals have a member function named "evalPhaseStorage". However, not the storage "S" is calculated there, but its time derivative "(S_new - S_old) / dt". This is not only a misnomer, but also inconsistent with the uncoupled 2p2c localresidual that offers a function with the same name that really calculates "S".
I would propose to rename the function to "evalPhaseStorageDerivative".https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/306FS#306 Unify and generalize diffusive fluxes2018-04-18T12:43:27ZBernd FlemischFS#306 Unify and generalize diffusive fluxes# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Dec 9, 2015 16:01 |
| Type | Feature Request |
| Versi...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Dec 9, 2015 16:01 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Johannes Hommel (johannes.hommel@iws.uni-stuttgart.de) |
| Last edited at | Jul 14, 2016 14:00 |
# Description
Each compositional model has its own FluxVariables: 1p2c, 2p2c, 2pnc, 3p3c, mpnc. Mostly, diffusive fluxes assuming Fickian diffusion are calculated there.
On the one hand, we should unify this and provide a calculation of Fick-based diffusive fluxes for an arbitrary number of phases.
On the other hand, we should generalize and also provide other diffusion models like Maxwell-Stefan or Knudsen. Maxwell-Stefan is already available in the mpnc model. It should be easy to extract this into a separate class that can be used from the other models as well.
The unification part is a continuation of FS#159.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/260FS#260 Improve/update content of the website2018-04-18T12:43:27ZBernd FlemischFS#260 Improve/update content of the website# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Apr 10, 2015 09:51 |
| Type | Feature Request |
| Vers...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Apr 10, 2015 09:51 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Mar 7, 2016 13:57 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Mar 7, 2016 13:57 |
| Closed in version | 2.9 |
| Resolution | Implemented |
# Description
```
Many interesting stuff around Dumux is not mentioned on the website or not up-to-date:
- dumux-lecture and dumux-pub are not mentioned.
- Gallery, projects and publications are outdated.
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/286FS#286 Cleanup after introduction of new gridcreator2018-04-18T12:43:27ZNicolas SchwenckFS#286 Cleanup after introduction of new gridcreator# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Nicolas Schwenck (nicolas.schwenck@iws.uni-stuttgart.de) |
| Reported at | Aug 20, 2015 08:55 |
| Type | Hiwi Job |
...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Nicolas Schwenck (nicolas.schwenck@iws.uni-stuttgart.de) |
| Reported at | Aug 20, 2015 08:55 |
| Type | Hiwi Job |
| Version | Git |
| Last edited by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Last edited at | Mar 24, 2016 07:28 |
| Closed by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Closed at | Mar 24, 2016 07:28 |
| Closed in version | 2.9 |
| Resolution | Implemented |
# Description
Timos last comment on FS#284 was:
A general grid creator is implemented in revision r15307 as the new standard grid creator.
It remains a cleanup task: Through the grid creator the necessary header files (both grid header and dgf header + e.g. gmsh reader) are now included by standard. It is not necessary anymore for most tests to include any header for the grid.
Those includes can be removed.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/303FS#303 beautify README2018-04-18T12:43:27ZBernd FlemischFS#303 beautify README# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Nov 4, 2015 12:33 |
| Type | Feature Request |
| Versi...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Nov 4, 2015 12:33 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Last edited at | Feb 2, 2016 14:58 |
| Closed by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Closed at | Feb 2, 2016 14:58 |
| Closed in version | 2.9 |
| Resolution | Implemented |
# Description
README is the file that is displayed in GitLab upon click on the dumux project. We should use the possibilities of GitLab to improve the appearance.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/259FS#259 Update DuMuX Handbook2018-04-18T12:43:27ZThomas FetzerFS#259 Update DuMuX Handbook# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Thomas Fetzer (thomas.fetzer@iws.uni-stuttgart.de) |
| Reported at | Mar 31, 2015 14:12 |
| Type | Feature Request |...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Thomas Fetzer (thomas.fetzer@iws.uni-stuttgart.de) |
| Reported at | Mar 31, 2015 14:12 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Sep 18, 2015 12:56 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Sep 18, 2015 12:56 |
| Closed in version | 2.8 |
| Resolution | Implemented |
# Description
In the last meeting we discussed that it is necessary the DuMuX handbook in more detail until the next release takes place.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/285FS#285 Grids folder gets linked even if it doesn't exist2018-04-18T12:43:27ZTimo Kochtimokoch@math.uio.noFS#285 Grids folder gets linked even if it doesn't exist# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Reported at | Jul 31, 2015 08:36 |
| Type | Bug Report |
| Version | ...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Reported at | Jul 31, 2015 08:36 |
| Type | Bug Report |
| Version | Git |
| Last edited by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Last edited at | Aug 28, 2015 09:53 |
| Closed by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Closed at | Aug 28, 2015 09:53 |
| Closed in version | unknown (Id=0) |
| Resolution | Fixed |
# Description
Results in broken symlink.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/258FS#258 [cleanup 1p2c] Remove useTwoPointGradients2018-04-18T12:43:27ZTimo Kochtimokoch@math.uio.noFS#258 [cleanup 1p2c] Remove useTwoPointGradients# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | 1p2c |
| Reported by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Reported at | Mar 21, 2015 18:31 |
| Type | Bug Report |
| Version | Git...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | 1p2c |
| Reported by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Reported at | Mar 21, 2015 18:31 |
| Type | Bug Report |
| Version | Git |
| Last edited by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Last edited at | Mar 25, 2015 11:00 |
| Closed by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Closed at | Mar 25, 2015 11:00 |
| Closed in version | 2.7 |
| Resolution | Fixed |
# Description
The function useTwoPointGradients in the spatial params is no longer in use. It just curiously appears in the 1p2c implicit model (with a nongeneral comment about a tumor model already deleted in commit r14382 ). The function is not needed anymore as we have the property ImplicitUseTwoPointFlux that does exactly that and is used in the fvelementgeometries.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/284FS#284 Make GridCreator detect grid format from ini file2018-04-18T12:43:27ZTimo Kochtimokoch@math.uio.noFS#284 Make GridCreator detect grid format from ini file# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Reported at | Jul 28, 2015 18:37 |
| Type | Feature Request |
| Versi...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Reported at | Jul 28, 2015 18:37 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Nicolas Schwenck (nicolas.schwenck@iws.uni-stuttgart.de) |
| Last edited at | Aug 20, 2015 08:56 |
| Closed by | Nicolas Schwenck (nicolas.schwenck@iws.uni-stuttgart.de) |
| Closed at | Aug 20, 2015 08:56 |
| Closed in version | 2.8 |
| Resolution | Implemented |
# Description
```
We recently decided to include more GridCreators in dumux (e.g. *.msh, *.art). I recently found it quite inconvenient that when you want to specify a gmsh file instead of a DGF you have to change something in the source too and recompile.
I suggest two alternatives:
1. A GridCreator/Factory like the one in dune-testtools:
http://conan2.iwr.uni-heidelberg.de/git/quality/dune-testtools/blob/master/dune/testtools/gridconstruction.hh
Explanation: The Gridfactory class has specializations for all supported grid managers. The Gridtype gets deduced by our Dumux Property "Grid". For each grid type we offer an interface in the input file. For e.g. UG it is optional if we want to specify a file (dgf, msh, art) via e.g. "Grid.File = mygrid.dgf" or a cube/simplex convenience constructor via e.g. "cellsX = 20...".
Pros: there is only one GridCreator, no need for a property. Flexible.
Cons: more change, nice interface in the ini file has to be found + good error handling for the user.
2. We keep two kinds of GridCreators:
- the "simple" ones, cube (cubes / simplices), maybe sphere in the future
- a single FromFileGridCreator that detects the type of Grid from the extension of the file given in the input file.
Cons: still multiple grid creators
Pros: easier implementation, Filetype doesn't matter
I would opt for the second one for now, as it is closer to what we already have and just makes life easier if you want to change the grid file to another format. A more comprehensive change like the one in 1. could be realized in 2.9 if positive feedback.
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/302FS#302 Implement EfftoAbsLaw and Regularization classes for 3p (Parker - van ...2018-04-18T12:43:27ZKilian WeishauptFS#302 Implement EfftoAbsLaw and Regularization classes for 3p (Parker - van Genuchten)# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | 3p3c |
| Reported by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Reported at | Nov 4, 2015 08:31 |
| Type | Feature Request...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | 3p3c |
| Reported by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Reported at | Nov 4, 2015 08:31 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Last edited at | Dec 16, 2015 05:57 |
| Closed by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Closed at | Dec 16, 2015 05:57 |
| Closed in version | 2.9 |
| Resolution | Implemented |
# Description
So far, the conversion from absolute to effective saturations takes place in the raw material law itself. The same applies for regularization.
We should implement these features in separate classes in order to be consistent with the 2p material laws. In addition, changing parameters for, e.g., the regularization becomes easier and less error prone.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/257FS#257 Resize localjacobian if non standard size2018-04-18T12:43:27ZTimo Kochtimokoch@math.uio.noFS#257 Resize localjacobian if non standard size# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Implicit models |
| Reported by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Reported at | Mar 21, 2015 18:23 |
| Type | Bug Report |
| Ve...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Implicit models |
| Reported by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Reported at | Mar 21, 2015 18:23 |
| Type | Bug Report |
| Version | Git |
| Last edited by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Last edited at | Mar 25, 2015 11:01 |
| Closed by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Closed at | Mar 25, 2015 11:01 |
| Closed in version | 2.7 |
| Resolution | Fixed |
# Description
The local jocabian should be sized to 1*2^dim x 1*2^dim for the box scheme and 1 x 2*dim for the cc scheme as default. Some advances approximation schemes, grids with hanging nodes, mixed dimensional grids may require different sizes. The actual size is already calculated in implicitlocaljacobian. We should check if the actual size is bigger than the default size and if so, resize the matrix accordingly.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/283FS#283 Compatibility of interfacemeshcreator2018-04-18T12:43:28ZThomas FetzerFS#283 Compatibility of interfacemeshcreator# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | multidomain |
| Reported by | Thomas Fetzer (thomas.fetzer@iws.uni-stuttgart.de) |
| Reported at | Jul 22, 2015 06:46 |
| Type | Feature Reque...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | multidomain |
| Reported by | Thomas Fetzer (thomas.fetzer@iws.uni-stuttgart.de) |
| Reported at | Jul 22, 2015 06:46 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Thomas Fetzer (thomas.fetzer@iws.uni-stuttgart.de) |
| Last edited at | Jul 29, 2015 07:35 |
| Closed by | Thomas Fetzer (thomas.fetzer@iws.uni-stuttgart.de) |
| Closed at | Jul 29, 2015 07:35 |
| Closed in version | 2.8 |
| Resolution | Implemented |
# Description
Using the interfacemeshcreator with the common start.hh is currently not possible, therefore the multidomain problems have their own start routine. The interfacemeshcreator should fit the general infracstructure and multidomain problems should call the common start routine.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/301FS#301 Solution dependent spatial parameters2018-04-18T12:43:28ZAlexander KissingerFS#301 Solution dependent spatial parameters# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Alexander Kissinger (alexander.kissinger@iws.uni-stuttgart.de) |
| Reported at | Oct 21, 2015 15:12 |
| Type | Featu...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Alexander Kissinger (alexander.kissinger@iws.uni-stuttgart.de) |
| Reported at | Oct 21, 2015 15:12 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Last edited at | Jan 22, 2016 09:25 |
# Description
In many applications there is a need to make parameters like porosity, permeability etc. dependent on the solution, e.g. porosity or permeability depending on pressure or chemical species or whatever.
It would be very convenient for these cases to have a function call from the volume variables that passes the current volume variables along as an argument.
This would greatly increase the flexibility for users who would not have to change anything on the model level if they want solution dependent spatial params but could implement all their changes on the application level.
The function calls could be implemented on the common and model level in such a way that the function calls as they are now would still be valid, i.e. no changes needed in existing spatial params on the application level.
I already implemented something like this for the dfm models in dumux-devel.