dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2020-03-17T21:36:02Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/519Constraint solvers shouldn't calculate viscosity and enthalpy2020-03-17T21:36:02ZBernd FlemischConstraint solvers shouldn't calculate viscosity and enthalpyThe "implicit" constraint solvers offer options to calculate viscosity and enthalpy. This seems to be outside their intended responsibilities.
Might facilitate #505 a bit.The "implicit" constraint solvers offer options to calculate viscosity and enthalpy. This seems to be outside their intended responsibilities.
Might facilitate #505 a bit.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/487Boundary conditions for FreeFlow2019-08-26T10:51:45ZKilian WeishauptBoundary conditions for FreeFlowWe should rethink the way boundary conditions for the Navier-Stokes models are handled.
Versteeg and Malalasekera suggest the following boundary conditions:
* inlet
* outlet
* wall
* prescribed pressure
* symmetry
* periodicity (or cyc...We should rethink the way boundary conditions for the Navier-Stokes models are handled.
Versteeg and Malalasekera suggest the following boundary conditions:
* inlet
* outlet
* wall
* prescribed pressure
* symmetry
* periodicity (or cyclic boundary condition)
Until now, "outlet" and "prescribed pressure" are somehow combined into the "outflow" BC, which does not always make sense.
Should we adapt to these kind of fixed conditions or provide at least some convenience methods?
What do we need to consider for coupling to other domains?3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/635Proofread handbook2018-12-20T16:11:08ZTimo Kochtimokoch@math.uio.noProofread handbook* [x] Throw out/improve stuff that is not correct
* [x] Run spell-checker
* [x] Shorten gnuplot section and remove stuff that is not general* [x] Throw out/improve stuff that is not correct
* [x] Run spell-checker
* [x] Shorten gnuplot section and remove stuff that is not general3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/638test_md_facet_1p1p_box_convergence fails with clang2018-12-19T15:30:47ZTimo Kochtimokoch@math.uio.notest_md_facet_1p1p_box_convergence fails with clang3.0Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/637Issue with UMFPack and opm-grid2018-12-19T14:15:53ZTimo Kochtimokoch@math.uio.noIssue with UMFPack and opm-gridThere seems to be an issue that UMFPack is found (by CMake) but HAVE_UMFPACK (in C++ / config.h) is false when using opm.
The configure log actually says neither suitesparse nor superlu is found although it is installed on the system. op...There seems to be an issue that UMFPack is found (by CMake) but HAVE_UMFPACK (in C++ / config.h) is false when using opm.
The configure log actually says neither suitesparse nor superlu is found although it is installed on the system. opm seems to mess with something.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/596Bring Doxygen up to date2018-12-19T12:01:32ZSimon EmmertBring Doxygen up to dateI had a quick lock at Doxygen today.
The question that we should discuss is:
**What do we (not) want to document in Doxygen?**
Under **Modules** we currently have a list of available `models` and `discretization schemes`.
This seem...I had a quick lock at Doxygen today.
The question that we should discuss is:
**What do we (not) want to document in Doxygen?**
Under **Modules** we currently have a list of available `models` and `discretization schemes`.
This seems good to me and maybe could get a small update.
The newly established `Multidomain simulations` part should also be in there in my opinion.
We also list our `Material/Fluid Framework`, which looks good to me.
Then we have `Benchmarks and Tests,` which is not really a module in my opinion and could be replaced by our examples in the near future (3.1). **So we could get rid of this.**
And then there is `Adaptive`
`Assembly`
`Common`
`Input Output`
`Linear`
`Nonlinear`
`Parallel`
where I am not sure if we could combine them maybe.
**We used to have a feature list and a parameter list.**
**Do we want to have them also in 3.0? And if so, in which detail level?**
The last time I tried this, we opted more towards a general feature/parameter list without listing all the possible combinations and variations.
Comments?3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/636Missing CMake guards in tests2018-12-18T20:08:07ZTimo Kochtimokoch@math.uio.noMissing CMake guards in testsSome freeflow tests have missing CMake guards for UMFPack.Some freeflow tests have missing CMake guards for UMFPack.3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/484Bring handbook up to date2018-12-18T19:36:05ZBeatrix BeckerBring handbook up to dateThere are a few larger TODOs in the handbook:
* [x] Check and update chapter 2 Getting started (@hommel): maybe split in two chapters ("Getting started" including the quick guide and something else...) or rename chapter, add grids (@kw...There are a few larger TODOs in the handbook:
* [x] Check and update chapter 2 Getting started (@hommel): maybe split in two chapters ("Getting started" including the quick guide and something else...) or rename chapter, add grids (@kweis), delete mentioning of dumux-devel
* [x] Check and update chapter 3 Tutorial (@nedc): explain check out of dumux-course with the dumux-course tag, mention that dumux-course will be updated soon to work with 3.0 release and that examples will be added in 3.1 release, delete tutorial
* [x] Update chapter 4.1, 4.2, 4.3 plus change file for naming conventions to md-file (@kweis)
* [x] Update chapter 5.4 Restart (@timok)
* [x] Add Input/Output chapter with paraview, gmsh... Move 5.5 Grid Handling to this chapter (@leopold.stadler, @utz)
* [x] Write subsection on grid (e.g., cornerpoint, @martins) in 5_grids.tex
* [x] Write subsubsection on temporal discretization in 5_models.tex (@felixw, with help from @holle)
* [x] Write subsubsection on MPFA (@martins) in 5_spatialdiscretizations.tex
* [x] Revise subsubsection on Staggered grid (@melaniel) in 5_spatialdiscretizations.tex
* [x] Revise section about implementation structure and revise figure in 5_stepsofasimulation.tex (link to main file from course) (@melaniel)
* [x] Check and update 5.4 Property System (@seitz)
* [x] Check and update 5.5 Grid Handling (@nedc): ICEM raus
* [x] Write section on how to use DuMuX in parallel (@leopold.stadler, @utz): mpirun, only AMG, Multidomain and freeflow not in parallel, depends on grid (dune)
* [x] Add section on gas mixing laws
* ~~[ ] Add chapter on physics of porous media flow (e.g. pc-sw curves) (@holle)~~
* [x] Link to wiki about changes from 2.12 to 3.0 (@becker)3.0Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/631Check CMakeLists.txt (install paths and files) in the `test` folder2018-12-18T10:05:53ZTimo Kochtimokoch@math.uio.noCheck CMakeLists.txt (install paths and files) in the `test` folderWe have a script to generate the correct CMakeLists.txt in the `dumux` folder.
However, there are still mistakes in the `test` folder.We have a script to generate the correct CMakeLists.txt in the `dumux` folder.
However, there are still mistakes in the `test` folder.3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://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/632Headercheck fails for facet mpfa localassembler2018-12-11T08:29:17ZTimo Kochtimokoch@math.uio.noHeadercheck fails for facet mpfa localassembler@DennisGlaeser header check fails for this header:
`multidomain/facet/cellcentered/mpfa/localassembler.hh`
There is a template specialization in there but it doesn't seem to exist anymore. Is this file actually tested anywhere?@DennisGlaeser header check fails for this header:
`multidomain/facet/cellcentered/mpfa/localassembler.hh`
There is a template specialization in there but it doesn't seem to exist anymore. Is this file actually tested anywhere?3.0Dennis GläserDennis Gläserhttps://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/553Possible dead-lock when reading parallel grid data with ug grid2018-12-09T14:45:44ZTimo Kochtimokoch@math.uio.noPossible dead-lock when reading parallel grid data with ug gridThere seems to be a problem the way we create the data handle for the grid data communication, which causes ug to hang on some systems.There seems to be a problem the way we create the data handle for the grid data communication, which causes ug to hang on some systems.3.0Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/629Box dfm tests fail with dune master2018-12-04T14:05:56ZTimo Kochtimokoch@math.uio.noBox dfm tests fail with dune mastersee BuildBotsee BuildBot3.0Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/541Test restart functionality2018-12-03T08:34:12ZBernd FlemischTest restart functionalityWith !1039, the possibility of reading an initial solution from a Vtk file has been introduced. This is implemented quite general, but a model-specific part remains that defines the primary variable names of the model that are expected t...With !1039, the possibility of reading an initial solution from a Vtk file has been introduced. This is implemented quite general, but a model-specific part remains that defines the primary variable names of the model that are expected to be found in the Vtk file. Since this is sensitive to changes of these names in the output routines, it should be tested thoroughly:
- Adapt relevant main files such that the restart functionality will work again.
- Add one restart test in the corresponding CMakeLists.txt.
- Add more parallel tests in `test/porousmediumflow/richards/implicit` (depends on #535).
Examples can be found in `test/porousmediumflow/2p/implicit/incompressible`, `test/porousmediumflow/2p2c/implicit` and `test/freeflow/navierstokes`.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/545[cc/staggered] Caching boundary volVars with time-dependend Dirichlet BCs is ...2018-12-03T06:46:26ZKilian Weishaupt[cc/staggered] Caching boundary volVars with time-dependend Dirichlet BCs is wrongFor the cc and staggered discretization, Dirichlet values are assigned to boundary volVars on the domain boundary. When caching is on, the volVars are updated after each Newton iteration. However, if time-depended Dirichlet values are us...For the cc and staggered discretization, Dirichlet values are assigned to boundary volVars on the domain boundary. When caching is on, the volVars are updated after each Newton iteration. However, if time-depended Dirichlet values are used, the wrong Dirichlet (i.e. those of the previous time step) are still used within the first Newton iteration of the new time step.
One could update the volVars before each Newton step or, which might be more effective, __not__ cache the boundary volVars at
all and build them ad hoc during `bind()`.3.0Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/551[box][compositional] Dirichlet condition for box method does not use setState...2018-11-30T17:06:35ZKatharina Heck[box][compositional] Dirichlet condition for box method does not use setState methodWhen using the box-method the setState method which is used in compositional models to set the state of your primary variables is not used. It looks like the primary variables are always pressure and saturation. Therefore it is not possi...When using the box-method the setState method which is used in compositional models to set the state of your primary variables is not used. It looks like the primary variables are always pressure and saturation. Therefore it is not possible to use a one-phase system and a mole fraction instead of saturation.
Problem
--------
The (initial) solution can have different states than the Dirichlet values, either because they are differently set at the beginning or in time dependent Dirichlet BC problems (connection to #545, should be actually a problem for tpfa then as well). The residual is then wrong because it is set (sol - Dirichlet) and sol and dirichlet have different states.3.0Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/530ModelTraits::numPhases should be ModelTraits::numFluidPhases2018-11-30T16:06:39ZTimo Kochtimokoch@math.uio.noModelTraits::numPhases should be ModelTraits::numFluidPhasesleads to inconsistency with geomechanics e.g. otherwise. We should also export numSolidPhases/Componentsleads to inconsistency with geomechanics e.g. otherwise. We should also export numSolidPhases/Components3.0Theresa SchollenbergerTheresa Schollenbergerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/625MultiDomain Traits define types inconsistently as const2018-11-30T09:17:24ZTimo Kochtimokoch@math.uio.noMultiDomain Traits define types inconsistently as constSome of the types are `tuple`s of `shared_ptr`s to `const` types, some to non-const types.
This way done in an inconsistent way.
I propose to change it as follows
* Do not provide any tuple types, as we already have `MakeTuple` (could ...Some of the types are `tuple`s of `shared_ptr`s to `const` types, some to non-const types.
This way done in an inconsistent way.
I propose to change it as follows
* Do not provide any tuple types, as we already have `MakeTuple` (could be renamed to simply `Tuple`)
* Provide only subdomain types with template arugment `size_t i`
* Provide other helpers that create a `TupleOfSharedPtr` and `TupleOfSharedPtrConst`
This is necessary to implement !1350.
@kweis, @DennisGlaeser3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/620Most tests with Neumann no-flow and velocity output fail2018-11-28T17:42:01ZTimo Kochtimokoch@math.uio.noMost tests with Neumann no-flow and velocity output fail!1319 changed the velocity output at Neumann no-flow boundaries. See buildbot for affected tests. References need to be adjusted (there should be only a different in the velocity field -> only change that field in the reference solution).!1319 changed the velocity output at Neumann no-flow boundaries. See buildbot for affected tests. References need to be adjusted (there should be only a different in the velocity field -> only change that field in the reference solution).3.0Martin SchneiderMartin Schneider