dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2017-04-26T08:57:59Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/342Implement classes facilitating a custom start.hh2017-04-26T08:57:59ZTimo Kochtimokoch@math.uio.noImplement classes facilitating a custom start.hhI often feel restricted by the way our `start.hh` and the `main.cc` file is structured. The idea is to make it simple to run a problem in dumux so the start function is predefined. However it's currently annoying to implement your own ma...I often feel restricted by the way our `start.hh` and the `main.cc` file is structured. The idea is to make it simple to run a problem in dumux so the start function is predefined. However it's currently annoying to implement your own main function since many of the steps in the standard `start.hh` method are just written out sequentially or in simple functions. It would be nice to make it more customizable by some OO programming. E.g. a simple class called the `DumuxMessageGenerator` and more important classes like a grid setup class or a parameter file / command line option reading class.
Simple examples would be:
1. I want to write a grid convergence test with a simple loop in main refining the grid and output the errors and rates.
2. I want to solve a problem with two grids.
3. I want to have objects or variables living outside the scope of a problem
These things are overly complicated now I think.2.11https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/613Fix deprecation warning related to `gridvariables.init`2018-11-25T11:29:53ZTimo Kochtimokoch@math.uio.noFix deprecation warning related to `gridvariables.init`3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/555Free all spatial params of property system2018-11-22T20:58:17ZTimo Kochtimokoch@math.uio.noFree all spatial params of property systemUsually FVGridGeometry and Scalar (like in the base class) should be enough. Add more only if absolutely necessary.Usually FVGridGeometry and Scalar (like in the base class) should be enough. Add more only if absolutely necessary.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/544Need for unit test for CheckPointTimeLoop2018-08-03T06:01:19ZTimo Kochtimokoch@math.uio.noNeed for unit test for CheckPointTimeLoopThe check pointing can be tricky with floating point operations. We should have a unit test testing corner cases, very small and very big time step size and so on.The check pointing can be tricky with floating point operations. We should have a unit test testing corner cases, very small and very big time step size and so on.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/5222p1c primary variable switch and mixed wettability concept not consistent wit...2018-08-16T08:54:19ZTimo Kochtimokoch@math.uio.no2p1c primary variable switch and mixed wettability concept not consistent with other 2p compositional modelsThe 2p1c model is not adapted (at least in some parts) to the new mixed-wettability concept for two-phase flow.The 2p1c model is not adapted (at least in some parts) to the new mixed-wettability concept for two-phase flow.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/489Generic CO2 Component2018-06-27T10:22:22ZSimon EmmertGeneric CO2 ComponentWe currently have a ``simpleco2.hh`` for when CO2 is used as an ideal gas and a ``co2.hh``, which uses the values from the CO2Tables.
We would like to have a CO2 component that chooses automatically between a "simple CO2" formulation (...We currently have a ``simpleco2.hh`` for when CO2 is used as an ideal gas and a ``co2.hh``, which uses the values from the CO2Tables.
We would like to have a CO2 component that chooses automatically between a "simple CO2" formulation (when used in the ideal gas regime) or the tabulated values from the CO2 tables (when used in the super-critical regime) or some interpolation between the two.
* [ ] Define/Look up regime for ideal gas and super-critical state
* [ ] Think of good and efficient interpolation
* [ ] implement all
**Discussion:**
Should we include the option to "force" the use of either one, in case you really want to use CO2-Tables or the ideal gas law all the time?3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/485Compiler error with dune 2.52018-04-27T13:33:20ZThomas FetzerCompiler error with dune 2.5As we officially still support dune 2.5 (maybe it is worth rethinking that, because we already break so many dependencies):
/home/temp/fetzer/dumux-30/dumux/dumux/io/vtkfunction.hh:48:70: error: wrong number of template arguments (1, sh...As we officially still support dune 2.5 (maybe it is worth rethinking that, because we already break so many dependencies):
/home/temp/fetzer/dumux-30/dumux/dumux/io/vtkfunction.hh:48:70: error: wrong number of template arguments (1, should be 2)
using Mapper = Dune::MultipleCodimMultipleGeomTypeMapper<GridView>;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/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/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/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/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/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/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/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/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/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/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/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/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 Heck