dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2021-11-02T17:17:19Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1100Add documentation on website on how to install external dependencies so that ...2021-11-02T17:17:19ZTimo Kochtimokoch@math.uio.noAdd documentation on website on how to install external dependencies so that Dune finds themSome explanations on build system, how to work with dunecontrol, on the website would be nice.Some explanations on build system, how to work with dunecontrol, on the website would be nice.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1015Add enthalpy of vaporization to constant component2021-10-27T08:43:35ZTimo Kochtimokoch@math.uio.noAdd enthalpy of vaporization to constant componentRelated to #1013 !2563
We could just add a function vaporizationEnthalpy that is also read from the input file.
This also allows to estimate the vapor pressure: https://en.wikipedia.org/wiki/Clausius%E2%80%93Clapeyron_relation#Applica...Related to #1013 !2563
We could just add a function vaporizationEnthalpy that is also read from the input file.
This also allows to estimate the vapor pressure: https://en.wikipedia.org/wiki/Clausius%E2%80%93Clapeyron_relation#Applications (if e.g. triplePointPressure/Temperature is supplied)3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/997Add non-Darcy flow upscaling example2021-05-17T09:10:42ZTimo Kochtimokoch@math.uio.noAdd non-Darcy flow upscaling exampleThe following discussion from !2420 should be addressed:
- [x] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2420#note_54324): (+2 comments)
> I would be awesome to have a...The following discussion from !2420 should be addressed:
- [x] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2420#note_54324): (+2 comments)
> I would be awesome to have a test that computes permeability in one direction for a network e.g. extracted from the Berea sandstone sample for different pressure gradients. Then we could do at least a qualitative comparison with Muljadi et al. https://doi.org/10.1016/j.advwatres.2015.05.019 (essentially reproduce one of the plots of El-Zehairy et al. https://doi.org/10.1016/j.advwatres.2019.103378)3.5Maziar VeyskaramiMaziar Veyskaramihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/542add restart functionality for elastic models2021-03-09T12:22:04ZBernd Flemischadd restart functionality for elastic modelsOne has to
- generalize `loadSolution` such that a field with `numComponents > 1` can be read from a Vtk file into a solution vector,
- implement `primaryVariableName` in the model traits of the elastic models,
- add a corresponding test.One has to
- generalize `loadSolution` such that a field with `numComponents > 1` can be read from a Vtk file into a solution vector,
- implement `primaryVariableName` in the model traits of the elastic models,
- add a corresponding test.3.5Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/892[Box] Numeric differentiation not correct if volume variables depend on dofs ...2021-03-25T08:41:00ZTimo Kochtimokoch@math.uio.no[Box] Numeric differentiation not correct if volume variables depend on dofs other than the scv dof[Bug reported here](https://listserv.uni-stuttgart.de/pipermail/dumux/2020q2/002540.html) by Dmitry Pavlov on the mailing list.
When deflecting the solution to compute the numerical derivative of the element residual in the box method, ...[Bug reported here](https://listserv.uni-stuttgart.de/pipermail/dumux/2020q2/002540.html) by Dmitry Pavlov on the mailing list.
When deflecting the solution to compute the numerical derivative of the element residual in the box method, currently only the volume variables associated with the deflected dof are updated. However, since volume variables may depend on all dofs of the element, also the other volume variables on the element have to be updated.
This leads to an inexact Jacobian. Fixing the issue may lead to a significant overhead for most models as volume variable updates are typically the most expensive step in the local residual calculation.3.5Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/990Broken parallel helpers (again)2021-04-09T07:38:34ZTimo Kochtimokoch@math.uio.noBroken parallel helpers (again)The current implementation does not work for grids that cannot communicate since the functions are actually called regardless of whether the grid can communicate or not trusting that the function will handle it.
There at least two ways ...The current implementation does not work for grids that cannot communicate since the functions are actually called regardless of whether the grid can communicate or not trusting that the function will handle it.
There at least two ways to solve this. Example `makeNonOverlappingConsistent`:
* check if num processors is more than 1 otherwise return, if grid cannot communicate but num processors is greater 1 throw
* do none of the checks inside the function but outside
I'm tending to the latter because otherwise `makeNonOverlappingConsistent` is doing more than one thing (SRP).
If you call the function and read the name you expect it to do something. So you should just call it if your grid can communicate and if the number of processors is more than 1. But it also means more code at the call site but also more transparent.
@DennisGlaeser @bernd3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1091Central place for geometry intersection tolerances2021-10-27T08:21:28ZDennis GläserCentral place for geometry intersection tolerancesIn the `GeometryIntersection` algorithms we define a `baseEps_ = 1.5e-7` in every specialization. I think it could be beneficial to define the tolerance once in a central place. Something like
```
template<typename ctype>
class Precisio...In the `GeometryIntersection` algorithms we define a `baseEps_ = 1.5e-7` in every specialization. I think it could be beneficial to define the tolerance once in a central place. Something like
```
template<typename ctype>
class Precision
{
public:
static ctype relativeTolerance()
{ return 1.5e-7; } // or get from parameter tree as a static const variable? or from configure step?
};
```
Personally, I would be in favor of the solution with the parameter tree such that users can change the tolerance via the input file.3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1068Change construction and update of MultiDomainFVGridGeometry2021-11-26T10:39:52ZMartin SchneiderChange construction and update of MultiDomainFVGridGeometryIn MR !2737 the construction of grid geometries is such that no further call of `update` is needed after construction. For some gg this requires to pass additional objects to the constructor. Therefore, the MultiDomainFVGridGeometry has ...In MR !2737 the construction of grid geometries is such that no further call of `update` is needed after construction. For some gg this requires to pass additional objects to the constructor. Therefore, the MultiDomainFVGridGeometry has to be changed such that the grid geometries of the sub-problems are set and not constructed within this class.3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/970Check brine fluidsystem2021-11-24T09:00:08ZTheresa SchollenbergerCheck brine fluidsystemThe binary diffusion coefficient of NaCl seems to be wrong. Also there is no source available for the implemented one. Because of that the implemented parameters should be checked and sources sould be added.
Further there are relations e...The binary diffusion coefficient of NaCl seems to be wrong. Also there is no source available for the implemented one. Because of that the implemented parameters should be checked and sources sould be added.
Further there are relations e.g. for density where the source is not mentioned in the comments. Also there are some todos left to do which could be essential.
- [x] correct diffusion coefficient
- [ ] check parameters and add sources
- [ ] improve comments and add sources for relationships
- [ ] todo check contribution of NaCl on thermal conductivity
- [ ] todo find better description for calculation of the isobaric heat capacity
- [x] check solid heat capacity of NaCl which is given in J/mol K3.5Theresa SchollenbergerTheresa Schollenbergerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1041[ci] Test cornerpoint grid + OPM2021-07-23T10:42:18ZTimo Kochtimokoch@math.uio.no[ci] Test cornerpoint grid + OPMMaybe just on the release branch. Needs a different Docker image?
Many people seem to have difficulties getting OPM to run (e.g. #1036), so a Dockerfile might help to at least show the minimal steps required to set it up on a new system...Maybe just on the release branch. Needs a different Docker image?
Many people seem to have difficulties getting OPM to run (e.g. #1036), so a Dockerfile might help to at least show the minimal steps required to set it up on a new system. I also have the feeling from the mailing list posts that cornerpoint grids quite a popular feature for external users.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/966[ci] Test installation scripts in CI2021-10-27T08:01:01ZTimo Kochtimokoch@math.uio.no[ci] Test installation scripts in CIWe could add a Docker container for testing the new installation script and maybe the install external in the CI.We could add a Docker container for testing the new installation script and maybe the install external in the CI.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/761Cleanup explicit flash of implicit 2p2c model2021-03-09T12:21:50ZBeatrix BeckerCleanup explicit flash of implicit 2p2c modelThe volumevariables of the 2p2c model have an explicit flash directly implemented in the volumevariables itself.
* In general I like the idea of a specialized 2p2c flash that is easy to understand and fast, but it shouldn't be included...The volumevariables of the 2p2c model have an explicit flash directly implemented in the volumevariables itself.
* In general I like the idea of a specialized 2p2c flash that is easy to understand and fast, but it shouldn't be included in the volumevariables. I would propose implementing it as a separate class in a separate header, like the other constraintsolvers.
* The flash is only used if `useConstraintSolver` is false and the default is true. For the 2p2c model I would make the flash the default, since it is a faster calculation than using the more general `MiscibleMultiPhaseComposition` constraintsolver which solves a linear system of equations. Maybe we should even completely delete `useConstraintSolver` because in my opinion the solver has no benefit here, it solves the same equations, just less efficiently.
* For the case of one phase we may use the `ComputeFromReferencePhase` constraintsolver since it does exactly what the flash does.
* I don't think the flash is currently tested, so this should be added. It should have the same result as the other constraintsolvers.
What do you think? Another solution could be to delete the flash code and always use the solvers that we already have, but as mentioned above, I prefer having a 2p2c-specific flash.
There are a few points that I'm not sure of, maybe @holle can comment on this:
* In my opinion this flash is not as correct as it could be because it uses the assumption that vapor pressure of the liquid component and partial pressure of the liquid component in the gas phase are the same. This is only the case if we neglect the presence of other components in the gas phase. There is an equally quick method to calculate the mass fractions without using this assumption, see the 2p2c flash of the sequential models.
* It seems that the flash assumes that we deal with one liquid and one gas phase and that the liquid phase is the first phase. I think the 2p2c flash of the sequential models doesn't have this constraint.
* There seems to be a bug in the case that only the first phase is present, in the calculation of the mole fraction of the first component in the second phase. A multiplication with the mole fraction of the first component in the first phase is probably missing.3.5Beatrix BeckerBeatrix Beckerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/826Diffusion confusion (implementation)2021-03-25T08:37:24ZTimo Kochtimokoch@math.uio.noDiffusion confusion (implementation)We decided at some point that diffusion laws, e.g. `FicksLaw`, should compute all component fluxes in one go. This means two things
* we can now more efficiently compute the diffusive fluxes depending on the law (Fick / Maxwell-Stefan)
...We decided at some point that diffusion laws, e.g. `FicksLaw`, should compute all component fluxes in one go. This means two things
* we can now more efficiently compute the diffusive fluxes depending on the law (Fick / Maxwell-Stefan)
* `FicksLaw` now depends on the equation system
__Example:__
1. If I want to neglect diffusion in one phase, i can set the diffusion coefficient to zero. However, then the diffusive fluxes are still computed and I can throw them away in the custom local residual.
2. The Richards model is an immiscible two-phase two-component model but the air phase is never balanced. To integrate this in the current framework, we introduced `BalanceEqOpts::mainComponentIsBalanced(phaseIdx)` which is overloaded for the Richards model and used in Fick's law. In this case the dependency is actually there in the code in form of the additional dependency on `BalanceEqOpts`.
__One thought for a possible solution:__
If we would have a class `DiffusionFlux` replacing the current `FicksLaw`, then we could have a custom implementation `RichardsDiffusionFlux` which takes care of special requirements. `DiffusionFlux` would be a class on the level of `LocalResidual` only containing physics/equations. Internally it could use something like `FicksLaw` (new implementation that only contains the transmissibility part and discretization specifics) to compute the actual individual fluxes. `DiffusionFlux` may need to be specialized on the Law type (Fick / Maxwell-Stefan) but not the discretization.
Maybe, this would essentially be a code renaming / reordering. But that needs to be further investigated.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/908[disc] Implementation of nonlinear fv schemes2021-03-25T08:35:41ZMartin Schneider[disc] Implementation of nonlinear fv schemes3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1057Document Python generator classes2021-07-23T08:37:29ZTimo Kochtimokoch@math.uio.noDocument Python generator classesFollow-up from "Feature/python main file"
The following discussion from !2681 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2681#note_62023):
> ...Follow-up from "Feature/python main file"
The following discussion from !2681 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2681#note_62023):
> we have to document these generators very well because it's the interface used from the Python side. But I think that's a separate task for when the bindings are a bit more stable...3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/816Do not use term "handle" in mpfa2021-03-25T08:59:26ZDennis GläserDo not use term "handle" in mpfaThe term `DataHandle` used in mpfa should be replaced as it actually stores the data.The term `DataHandle` used in mpfa should be replaced as it actually stores the data.3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/814Extract "constraint solvers" from volume variables2021-03-09T12:17:04ZTimo Kochtimokoch@math.uio.noExtract "constraint solvers" from volume variablesThe computation of the secondary variables from the primary variables is currently often coded inside the volume variables' `update` function. For the purpose of potential code reusage, readability, and testability it is IMO better to mo...The computation of the secondary variables from the primary variables is currently often coded inside the volume variables' `update` function. For the purpose of potential code reusage, readability, and testability it is IMO better to move this functionality to constraint solver classes. Even if the computation is quite simple. This is sometimes done in the form of the `computeFluidState` function. However, there is no general interface for all models.
If the constraint solver is in a separate class it is much easier to write unit tests. Volume variables have a lot of dependencies but the constraint solver can easily be tested and mock object are simple to construct for values obtained from e.g. the spatial params or some physical law.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1064Extract module script CMake macros not considered2021-10-27T08:30:17ZTimo Kochtimokoch@math.uio.noExtract module script CMake macros not consideredThe extract module script does not consider cmake macros. So if you extract from a module that defines some cmake macros/functions and then use them, the extracted module will not find these functions because it shouldn't depend on its p...The extract module script does not consider cmake macros. So if you extract from a module that defines some cmake macros/functions and then use them, the extracted module will not find these functions because it shouldn't depend on its parent module anymore.
Maybe we can simply copy the cmake/modules folder (might need some renaming) of the module extracted from.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1001extrusionFactor should be a spatial parameter interface2021-12-01T15:53:17ZTimo Kochtimokoch@math.uio.noextrusionFactor should be a spatial parameter interfaceDeprecate `extrusionFactor`/`extrusionFactorAtPos` in problem and add spatial parameter interface instead.Deprecate `extrusionFactor`/`extrusionFactorAtPos` in problem and add spatial parameter interface instead.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/951[freeflow] Introduce full shear stress terms, or document assumptions properly2021-03-25T08:38:24ZNed Coltman[freeflow] Introduce full shear stress terms, or document assumptions properlyWe ran into a few discussions this summer/fall regarding terms that we may have either not implemented in the navier-stokes environment, or terms that we have neglected, but have not documented the assumptions properly.
These should be...We ran into a few discussions this summer/fall regarding terms that we may have either not implemented in the navier-stokes environment, or terms that we have neglected, but have not documented the assumptions properly.
These should be included, in either both new and old staggereds, or only the new staggered.
These terms include:
- the dilataion term
```math
\tau = \mu (\nabla v + \nabla v^T) + ( \lambda \nabla v ) I
```
- with stokes hypothesis
```math
(\lambda = 2/3 \mu)
```
- the second term of the linear eddy viscosity reynolds stress: [cfdOnline](https://www.cfd-online.com/Wiki/Linear_eddy_viscosity_models)
```math
\tau_t = 2 \mu_t S - 2/3 \rho k \delta_{ij}
```
- any others?
From what I've seen, some of this is already underway. This issue is only a location to collect problems and track progress.3.5