dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2021-12-01T15:53:17Zhttps://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/1081Port free flow tests to new staggered2021-11-30T10:47:38ZBernd FlemischPort free flow tests to new staggeredTests should be ported one by one in separate merge requests. In principle, the new implementations are available in !2201. Move changes from `problem_new.hh` and `main_new.hh` to `problem.hh`, `main.hh`and `properties.hh`. Be careful as...Tests should be ported one by one in separate merge requests. In principle, the new implementations are available in !2201. Move changes from `problem_new.hh` and `main_new.hh` to `problem.hh`, `main.hh`and `properties.hh`. Be careful as !2201 is already partly outdated. !2830 is a port based on the current master.
- [x] `navierstokes/angeli`: @heck
- [x] `navierstokes/channel/1d`: @RoWin
- [x] `navierstokes/channel/pipe`: @hanchuan
- [x] `examples/liddrivencavity`: @nedc
- [ ] `navierstokes/kovaszny`: @yue (needs higher order upwinding)3.5https://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/1101Update parameterlist2021-11-24T16:54:17ZTimo Kochtimokoch@math.uio.noUpdate parameterlistThe parameter list is now generated by a new script !2933. The script still reports several errors that should be fixed. Some of these result from wrong configuration in the new input file. Some of them are related to old parameter which...The parameter list is now generated by a new script !2933. The script still reports several errors that should be fixed. Some of these result from wrong configuration in the new input file. Some of them are related to old parameter which have been removed. Some of them are related to new parameters.
The script can be run by
```
python3 bin/doc/generate_parameterlist.py
```
This creates a log file with all info in the current directory.
Debug output can be added to the log file by running
```
DUMUX_DEBUG_LEVEL=Debug python3 bin/doc/generate_parameterlist.py
```3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/807[RANS] Evaluate possibility to chose turbulence model at runtime2021-11-24T10:04:15ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[RANS] Evaluate possibility to chose turbulence model at runtimeCurrently, we have a myriad of different RANS models (zeroeq, oneeq, twoeq-kepsilon, twoeq-komega, twoeq-lowrekepsilon).
Maybe we could choose the turbulence model (at least for the two-eq models) at runtime.
This would decrease the nu...Currently, we have a myriad of different RANS models (zeroeq, oneeq, twoeq-kepsilon, twoeq-komega, twoeq-lowrekepsilon).
Maybe we could choose the turbulence model (at least for the two-eq models) at runtime.
This would decrease the number of executables for the tests and maybe also decrease the effort to add new turbulence models.3.5Ned ColtmanNed Coltmanhttps://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/1102[python] Add doc for Python with Dune 2.92021-11-20T02:10:31ZTimo Kochtimokoch@math.uio.no[python] Add doc for Python with Dune 2.93.5https://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/1097Harmonic mean and other helpers in spatial params2021-10-28T11:01:30ZTimo Kochtimokoch@math.uio.noHarmonic mean and other helpers in spatial paramsThe spatialparams contain an harmonic mean function and a special averaging for tensors. Why is this part of the spatial params interface? It should probably be out-sourced.
The following discussion from !2888 should be addressed:
- [ ...The spatialparams contain an harmonic mean function and a special averaging for tensors. Why is this part of the spatial params interface? It should probably be out-sourced.
The following discussion from !2888 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2888#note_67814): (+3 comments)
> Is this still used? Seems like the wrong place for such a function.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/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/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/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/1085Staggered problem dirichlet/neumann return convention2021-10-19T14:07:12ZTimo Kochtimokoch@math.uio.noStaggered problem dirichlet/neumann return conventionThe following discussion from !2852 should be addressed:
- [ ] @martins started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2852#note_66920): (+2 comments)
> I aggree and I also think ...The following discussion from !2852 should be addressed:
- [ ] @martins started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2852#note_66920): (+2 comments)
> I aggree and I also think that there should be some direct traits mechanics.
>
> However, this issue might also exist for user-defined functions. I think the discrepancy here is between how we actually think of `PrimaryVariables` and how it is used in the test cases. So maybe using for both situations the name `PrimaryVariables` might be confusing?
The staggered Navier-Stokes code expects full velocities fluxes (in all dimensions) from the problem. This makes it easier to set boundary conditions for when complex treatment due to the discretization is needed in the background.
The correct sizes are now statically asserted !2852. Still the problem uses the type names `PrimaryVariables` and `NumEqVector` but means different types than the corresponding types specified via properties and used in the assembly. This makes this error-prone and confusing. Moreover, it is currently necessary to overload all such functions inherited from the `FVProblem` because the type information is not properly propagated into the base class.
One solution would be to overload the functions in the navierstokes problem and actually use different type names such as `Velocity` and `MomentumFlux` so that it's completely clear that these are different.
TODO: how does this generalize to more complex models? Is it always only the momentum model affected by this? How to treat the difference with the mass model since both are currently implemented in one class with template switches.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1013SimpleH20 does not consider enthalpy of vaporization2021-10-01T12:36:42ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deSimpleH20 does not consider enthalpy of vaporizationI suggest to add $`h_\mathrm{vap}`$ here:
```c++
static const Scalar gasEnthalpy(Scalar temperature,
Scalar pressure)
{
static const Scalar tRef = getParam<Scalar>("SimpleH2O.Reference...I suggest to add $`h_\mathrm{vap}`$ here:
```c++
static const Scalar gasEnthalpy(Scalar temperature,
Scalar pressure)
{
static const Scalar tRef = getParam<Scalar>("SimpleH2O.ReferenceTemperature", 293.15);
return gasHeatCapacity(temperature, pressure)*(temperature - tRef) + 2453.5e3;
}
```
We could even make $`h_\mathrm{vap}`$ depending on $`T_\mathrm{ref}`$ as there as simple equations for that.
http://www.personal.psu.edu/users/m/r/mrh318/physical-consts/Popiel-Wojtkawiak-HTE-1998.pdf
https://www.scirp.org/pdf/AS20120200008_25514260.pdf (Bananas!)
It would still be a constant.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1074Spatialparams folder2021-09-29T10:40:13ZTimo Kochtimokoch@math.uio.noSpatialparams folderThe spatial parameter classes are located under material/spatialparams. I think this historically may have made sense when only porous media were considered. However, the spatial parameters are more general that. With parameters like `gr...The spatial parameter classes are located under material/spatialparams. I think this historically may have made sense when only porous media were considered. However, the spatial parameters are more general that. With parameters like `gravity` and `extrusionFactor` (see #1001) that are not necessarily connected to some material, we interpret the spatial parameters really just as (potentially) spatially varying parameter fields.
What would be a better place? `common/spatialparams`? Or just move the headers to the respective subfolders, i.e. porousmediumflow spatial params to `porousmediumflow` and porenetwork spatial params to `porenetwork` and so on?3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1071Tracer is not conserved2021-08-15T09:40:08ZBernd FlemischTracer is not conserved**Problem description:**
In a multi-phase setting, the amount of a tracer in one fluid phase is possibly not conserved from one time step to the next.
**Explanation:**
When solving the flow problem, the phase distribution usually chang...**Problem description:**
In a multi-phase setting, the amount of a tracer in one fluid phase is possibly not conserved from one time step to the next.
**Explanation:**
When solving the flow problem, the phase distribution usually changes. For example, the saturation in one cell increases. Since flow and tracer problems are decoupled, one should assume in this flow step that the added fluid doesn't contain tracer. For conserving the amount of tracer in each cell, the tracer concentration should be adapted to this change. While the concentration should be reduced in case of an increasing saturation, it stays the same and therefore the amount of tracer in the cell is increased. This is not corrected by the tracer solution step, as that step just redistributes the tracer according to the volume flux and the given (possibly wrong) concentration.
**How to reproduce it:**
Check out the branch `fix/tracer-concentration` and consider [test/porousmediumflow/tracer/conservation](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/fix/tracer-conservation/test/porousmediumflow/tracer/conservation). Comment the line
```cpp
equilibrateTracer(xOld, oldSaturation_, saturation_);
```
of `main.cc`.
**Possible fix:**
Equilibrate the tracer after each flow solve and before each tracer solve. To be discussed in !2767.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/703Spatial parameters cannot be time dependent if not solution-dependent2021-08-15T09:38:11ZTimo Kochtimokoch@math.uio.noSpatial parameters cannot be time dependent if not solution-dependentIf we compute the tracer model in combination with a fluid that changes properties over time, we
need the old properties to evaluate the storage.
The problem is, the volvars currently don't know anything about time, so we can't pass tha...If we compute the tracer model in combination with a fluid that changes properties over time, we
need the old properties to evaluate the storage.
The problem is, the volvars currently don't know anything about time, so we can't pass that information
to the spatial params. That's why we currently assume that all secondary variables are either constant
or solution-dependent but not time-dependent without being solution-dependent. This is a big drawback
in general and a bug or at least an imprecision in the tracer model.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/792MultiDomain does not work for solution-dependent spatial params in instationa...2021-08-15T09:37:48ZDennis GläserMultiDomain does not work for solution-dependent spatial params in instationary problemsThis issue is related to #619, #703 and #788.
**What happened / Problem description**:
If a spatial param, e.g. porosity, depends on the solution of another domain (for example deformation-dependent porosities in poroelastic models), ...This issue is related to #619, #703 and #788.
**What happened / Problem description**:
If a spatial param, e.g. porosity, depends on the solution of another domain (for example deformation-dependent porosities in poroelastic models), there is currently no way to evaluate it on the correct time level during the creation of the previous volume variables. This causes the Newton solver to fail even for simple problems. A local (hacky) bugfix showed that good convergence is obtained when this is fixed.
This means that currently the Geomechanics module cannot be used for time-dependent problems in which deformation-dependent porosities are used, which is a standard capability.
A similar problem is reported in #703, where time-dependent spatial saturation distributions are needed.
Since several issues are related to this, an idea was to think about a more general way of handling time discretization schemes and hopefully fix all three issues at once.
One idea was to have a local view on the spatial parameters as well, and change all __bind__ functions such that they not only bind to an element but also to a time level somehow.3.5https://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.5