dumux-repositories issueshttps://git.iws.uni-stuttgart.de/groups/dumux-repositories/-/issues2019-10-30T10:13:52Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/676[components] TabulatedComponent cannot be used for all components (e.g., air)2019-10-30T10:13:52ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[components] TabulatedComponent cannot be used for all components (e.g., air)Some components are lacking `vaporPressure()`, thus they cannot be compiled with a tabulation.
We could rethink this and only do the tabulation if the raw component acutally implements `vaporPressure()`, otherwise a runtime error could be thrown.Some components are lacking `vaporPressure()`, thus they cannot be compiled with a tabulation.
We could rethink this and only do the tabulation if the raw component acutally implements `vaporPressure()`, otherwise a runtime error could be thrown.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/682Test tabulation doesn't actually test anything2019-08-28T08:55:19ZTimo Kochtimo.koch@iws.uni-stuttgart.deTest tabulation doesn't actually test anythingNo matter if success is false or true the test always returns 0 exit code.No matter if success is false or true the test always returns 0 exit code.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/686Improve usage of container types in staggered2019-08-28T08:50:44ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deImprove usage of container types in staggered* Replace `std::vector` by `Dune::ReservedVector` or even `std::array`, where possible
* most sizes are known at compile time* Replace `std::vector` by `Dune::ReservedVector` or even `std::array`, where possible
* most sizes are known at compile time3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/690[material][co2] create co2 tables with pressures less than 1 bar2019-10-30T13:09:36ZKatharina Heck[material][co2] create co2 tables with pressures less than 1 barthe current co2 tables start at 1 bar pressure but in the fluidsystems e.g. brineco2 we calculate e.g. the gas density based on partial pressure (which can be less than 1 bar). That can lead to wrong results if the partial pressure is less than 1 bar. Then the value of 1 bar is taken from the table and added to the density calculation (which is especially wrong if no co2 is present at all)
Possibly this could be a task for a Hiwi to look into a meaningful relationship for densities etc for co2 and create new tables.the current co2 tables start at 1 bar pressure but in the fluidsystems e.g. brineco2 we calculate e.g. the gas density based on partial pressure (which can be less than 1 bar). That can lead to wrong results if the partial pressure is less than 1 bar. Then the value of 1 bar is taken from the table and added to the density calculation (which is especially wrong if no co2 is present at all)
Possibly this could be a task for a Hiwi to look into a meaningful relationship for densities etc for co2 and create new tables.Johannes HommelJohannes Hommelhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux-lecture/issues/9Fix deprecation warnings related to gravity2019-05-13T14:48:32ZTimo Kochtimo.koch@iws.uni-stuttgart.deFix deprecation warnings related to gravitygravity interface has been moved to the spatial params upstream. See dumux!1573gravity interface has been moved to the spatial params upstream. See dumux!15733.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/703Spatial parameters cannot be time dependent if not solution-dependent2019-08-28T10:10:44ZTimo Kochtimo.koch@iws.uni-stuttgart.deSpatial 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 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.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.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/704Multiphase tracer produces singular matrix if saturation is zero2019-10-02T12:56:00ZTimo Kochtimo.koch@iws.uni-stuttgart.deMultiphase tracer produces singular matrix if saturation is zeroA case that is like in two-phase models is that one phase disappears. If the tracer only exists in this
phase, the tracer also disappear, however that means that the local equation/residual degenerates.
This is automatically the case for all dofs where saturation is zero (over the whole time integration interval, see #703).
A robust solution could be to check for zero saturation and replace the equation for those dofs with the Dirichlet constraint that the concentration is zero. For that it would need to be possible to set Dirichlet for every dof even when not on the boundary, see #704.A case that is like in two-phase models is that one phase disappears. If the tracer only exists in this
phase, the tracer also disappear, however that means that the local equation/residual degenerates.
This is automatically the case for all dofs where saturation is zero (over the whole time integration interval, see #703).
A robust solution could be to check for zero saturation and replace the equation for those dofs with the Dirichlet constraint that the concentration is zero. For that it would need to be possible to set Dirichlet for every dof even when not on the boundary, see #704.3.2Timo Kochtimo.koch@iws.uni-stuttgart.deTimo Kochtimo.koch@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/706Add turbulent diffusion to shallow water model2019-05-21T12:20:07ZFrank PlatzekAdd turbulent diffusion to shallow water modelThe preliminary turbulent diffusion implementation in the shallow water model from Issue #657
(Turbulent diffusion in shallow water equations), is to be merged in the new structure for the shallow water model as part of the Freeflow model.The preliminary turbulent diffusion implementation in the shallow water model from Issue #657
(Turbulent diffusion in shallow water equations), is to be merged in the new structure for the shallow water model as part of the Freeflow model.Frank PlatzekFrank Platzekhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/707Generic implementation of L2-norm calculation using generic L2-projection2019-05-31T21:20:12ZTimo Kochtimo.koch@iws.uni-stuttgart.deGeneric implementation of L2-norm calculation using generic L2-projectionWith !1609 we get a generic l2-projection. In order to use it for interpolation between two arbitrary grids (arbitrary function spaces already works), we need to implement
* [x] 2d-2d intersections (!1625)
* [ ] 3d-3d intersections
That would be a great tool for convergence tests.With !1609 we get a generic l2-projection. In order to use it for interpolation between two arbitrary grids (arbitrary function spaces already works), we need to implement
* [x] 2d-2d intersections (!1625)
* [ ] 3d-3d intersections
That would be a great tool for convergence tests.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/710Follow-up from "Feature/simplify effective laws"2019-08-28T08:48:16ZTimo Kochtimo.koch@iws.uni-stuttgart.deFollow-up from "Feature/simplify effective laws"The following discussion from !1605 should be addressed:
- [ ] @DennisGlaeser started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1605#note_26777): (+3 comments)
> I thought we removed wPhaseIdx from the Indices and made this a runtime-thing? How does this actually compile?
* [ ] Make wetting phase index retrievable from 2p volvars
* [ ] Use them in Johansen effective thermal conductivity lawThe following discussion from !1605 should be addressed:
- [ ] @DennisGlaeser started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1605#note_26777): (+3 comments)
> I thought we removed wPhaseIdx from the Indices and made this a runtime-thing? How does this actually compile?
* [ ] Make wetting phase index retrievable from 2p volvars
* [ ] Use them in Johansen effective thermal conductivity law3.2Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/711Access to problem quantities (like thermal conductivity) model dependent2019-10-30T09:49:26ZAlexander JaustAccess to problem quantities (like thermal conductivity) model dependentI observed that it is problem-/model-dependent how to obtain the thermal conductivity. This make it hard to reuse some of my functions with different problems/models.
- Would it be possible to unify the interface?
- Is there a (smart) way to generalize functions that should work for different problems/models?
## Short description
The interface to obtain model properties is not unique. Obtaining the thermal conductivity `lambda` looks different for different types of problems used.
- Using `SolidEnergy` model: `lambda = ThermalConductivityModel::effectiveThermalConductivity(volVars,problem.spatialParams(),element,fvGeometry,scv)`
- Using `NavierStokesNI` model: `lambda = volVars.effectiveThermalConductivity()`
In my case, this makes is hard to reuse an already implemented function. Moreover, it does not feel intuitive that the interface to obtain the conductivity differs (that much) between two physical models.
## Longer description
Kilian and me have been recently worked on a routine that constructs the temperature on a boundary. It basically gets a heat flux `Q` on the face of an element and the temperature `T_cc` at the cell center. Together with the thermal conductivity `lambda` and the distance from the cell center to the face `distance` obtain the temperature on the face `T_face` from the following formula:
```
Q = - lambda ( T_face - T_center ) / distance
=> T_face = - Q * distance / lambda + T_center
```
It has been implement once for a heat equation problem that inherits from `SolidEnergy`. In this case heat conductivity is obtained via `ThermalConductivityModel::effectiveThermalConductivity`. In my particular case it looks like that:
```c++
const Scalar lambda = ThermalConductivityModel::effectiveThermalConductivity(volVars,
problem.spatialParams(),
element,
fvGeometry,
scv);
```
Now, I wanted to reuse the function for a Navier-Stokes based problem that inherits `NavierStokesNI`. I tried reuse the function we had already written, but this fails since the heat conductivity has to be obtained via the `effectiveThermalConductivity` member function of an object of type `ElementVolumeVariables`. In my case it looks like:
```c++
const Scalar insideLambda = volVars.effectiveThermalConductivity();
```
Due to that I had to implement the same function twice which I would like to avoidI observed that it is problem-/model-dependent how to obtain the thermal conductivity. This make it hard to reuse some of my functions with different problems/models.
- Would it be possible to unify the interface?
- Is there a (smart) way to generalize functions that should work for different problems/models?
## Short description
The interface to obtain model properties is not unique. Obtaining the thermal conductivity `lambda` looks different for different types of problems used.
- Using `SolidEnergy` model: `lambda = ThermalConductivityModel::effectiveThermalConductivity(volVars,problem.spatialParams(),element,fvGeometry,scv)`
- Using `NavierStokesNI` model: `lambda = volVars.effectiveThermalConductivity()`
In my case, this makes is hard to reuse an already implemented function. Moreover, it does not feel intuitive that the interface to obtain the conductivity differs (that much) between two physical models.
## Longer description
Kilian and me have been recently worked on a routine that constructs the temperature on a boundary. It basically gets a heat flux `Q` on the face of an element and the temperature `T_cc` at the cell center. Together with the thermal conductivity `lambda` and the distance from the cell center to the face `distance` obtain the temperature on the face `T_face` from the following formula:
```
Q = - lambda ( T_face - T_center ) / distance
=> T_face = - Q * distance / lambda + T_center
```
It has been implement once for a heat equation problem that inherits from `SolidEnergy`. In this case heat conductivity is obtained via `ThermalConductivityModel::effectiveThermalConductivity`. In my particular case it looks like that:
```c++
const Scalar lambda = ThermalConductivityModel::effectiveThermalConductivity(volVars,
problem.spatialParams(),
element,
fvGeometry,
scv);
```
Now, I wanted to reuse the function for a Navier-Stokes based problem that inherits `NavierStokesNI`. I tried reuse the function we had already written, but this fails since the heat conductivity has to be obtained via the `effectiveThermalConductivity` member function of an object of type `ElementVolumeVariables`. In my case it looks like:
```c++
const Scalar insideLambda = volVars.effectiveThermalConductivity();
```
Due to that I had to implement the same function twice which I would like to avoid3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/722(Not) modifying parameter tree during simulation2019-08-28T08:46:37ZTimo Kochtimo.koch@iws.uni-stuttgart.de(Not) modifying parameter tree during simulationI think in the design of the parameter tree, it was acutally desired that the tree shouldn't be modified after the initialization (but it can be initialized several times by overwriting previous initializaitons).
However currently it is technically possible to call init anywhere (globally) and modify the params which may lead to side effects in other classes.
It's technically possible to throw an error if the tree is modified by init after getParam has been called for the first time. However in some tests (some sequential tests and the fluid system test) this bug/feature is actually used/misused.
We should decide which way we want it and think about how to enforce it backwards-compatibly.I think in the design of the parameter tree, it was acutally desired that the tree shouldn't be modified after the initialization (but it can be initialized several times by overwriting previous initializaitons).
However currently it is technically possible to call init anywhere (globally) and modify the params which may lead to side effects in other classes.
It's technically possible to throw an error if the tree is modified by init after getParam has been called for the first time. However in some tests (some sequential tests and the fluid system test) this bug/feature is actually used/misused.
We should decide which way we want it and think about how to enforce it backwards-compatibly.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/724[Navier Stokes] Gravity upwinding2019-08-28T09:59:00ZMelanie Lipp[Navier Stokes] Gravity upwindingDo we want to use the upwind-density for both half-cells instead of the currently used density of the corresponding half-cell?Do we want to use the upwind-density for both half-cells instead of the currently used density of the corresponding half-cell?3.2Melanie LippMelanie Lipphttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/726More tools for regression tests2019-06-17T16:56:36ZTimo Kochtimo.koch@iws.uni-stuttgart.deMore tools for regression tests<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
New ideas for regression tests. It should be possible to ignore changes at let's say a saturation front, maybe by allowing a certain number of dofs to have a error higher tolerance. Another idea would be to map the solution of an adaptive grid to some reference grid and compare the solution there (we have some L2-projection capabilities now (only 2d for non-matching grids)).
**What does this feature / why does DuMux need it**:
It would make it possible to create more robust tests in cases where this is desired / physically-sensible.<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
New ideas for regression tests. It should be possible to ignore changes at let's say a saturation front, maybe by allowing a certain number of dofs to have a error higher tolerance. Another idea would be to map the solution of an adaptive grid to some reference grid and compare the solution there (we have some L2-projection capabilities now (only 2d for non-matching grids)).
**What does this feature / why does DuMux need it**:
It would make it possible to create more robust tests in cases where this is desired / physically-sensible.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/730Partial numerical differentiation2019-06-27T09:35:53ZMartin SchneiderPartial numerical differentiationIt would be nice to have the possibility in Dumux to choose which equation
is differentiated with respect to which variable.
For example if we solve a richardsni problem where we assume that the solution of richards equation
is independent of the temperature (e.g. if densities and viscosities are constant)
we do not need to calculate the derivatives of richards equation with respect to temperature.
This could be realized by introducing some table that lists if `eqIdx` should be differentiated
with respect to `pvIdx`. Furthermore, this could also help to decouple problems or to implement other solvers than Newton's method.It would be nice to have the possibility in Dumux to choose which equation
is differentiated with respect to which variable.
For example if we solve a richardsni problem where we assume that the solution of richards equation
is independent of the temperature (e.g. if densities and viscosities are constant)
we do not need to calculate the derivatives of richards equation with respect to temperature.
This could be realized by introducing some table that lists if `eqIdx` should be differentiated
with respect to `pvIdx`. Furthermore, this could also help to decouple problems or to implement other solvers than Newton's method.Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/733Make MPFA handle zero coefficients (like effective diffusion coefficient)2019-09-10T14:26:41ZTimo Kochtimo.koch@iws.uni-stuttgart.deMake MPFA handle zero coefficients (like effective diffusion coefficient)The following discussion from !1648 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1648#note_27837):
> before we merge this I think we have to fix first that MPFA can handle zero coefficients.The following discussion from !1648 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1648#note_27837):
> before we merge this I think we have to fix first that MPFA can handle zero coefficients.3.2Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/736Plot over line class2019-08-28T09:56:58ZTimo Kochtimo.koch@iws.uni-stuttgart.dePlot over line class<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Plot-over-line class
**What does this feature / why does DuMux need it**:
For post-processing it should be fairly easy to create a plot over line class that creates a user-defined number of points
along a line and evaluates the solution. (Using the bboxtree and its point search capabilities)<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Plot-over-line class
**What does this feature / why does DuMux need it**:
For post-processing it should be fairly easy to create a plot over line class that creates a user-defined number of points
along a line and evaluates the solution. (Using the bboxtree and its point search capabilities)3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/737Creating a bounding box tree for a vector of geometries2019-10-29T10:27:02ZTimo Kochtimo.koch@iws.uni-stuttgart.deCreating a bounding box tree for a vector of geometries<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Bounding box tree for a list of geometries without a grid
**What does this feature / why does DuMux need it**:
E.g. to intersect a polyline with a grid or some object where it would be
easier to just define the geometries instead of creating a Dune grid.
The bounding box tree is already general enough, it expects a EntitySet which only needs
to satisfy a certain subset of the interface of a Dune::GridView. So the task would be
to create a new EntitySet class which can be constructed from a vector of geometries instead
of from a grid view.<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Bounding box tree for a list of geometries without a grid
**What does this feature / why does DuMux need it**:
E.g. to intersect a polyline with a grid or some object where it would be
easier to just define the geometries instead of creating a Dune grid.
The bounding box tree is already general enough, it expects a EntitySet which only needs
to satisfy a certain subset of the interface of a Dune::GridView. So the task would be
to create a new EntitySet class which can be constructed from a vector of geometries instead
of from a grid view.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/740Enforce constraints in fluid state or algorithm?2019-08-28T08:40:50ZBeatrix BeckerEnforce constraints in fluid state or algorithm?Currently only one mass fraction has to be set for the compositional fluid state, the other one is internally deduced from that. This only works for two component models. In general: is it a good idea that the fluid state enforces such constraints or wouldn't it be better if the algorithm took care of that? @timok suggests that the fluid state could have a function like checkSumMoleFractions(Scalar value=1.0) to be able to assert the constraint before an algorithm that has that assumption about a fluid state.Currently only one mass fraction has to be set for the compositional fluid state, the other one is internally deduced from that. This only works for two component models. In general: is it a good idea that the fluid state enforces such constraints or wouldn't it be better if the algorithm took care of that? @timok suggests that the fluid state could have a function like checkSumMoleFractions(Scalar value=1.0) to be able to assert the constraint before an algorithm that has that assumption about a fluid state.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/745Implement HasResize2019-08-28T09:56:23ZTimo Kochtimo.koch@iws.uni-stuttgart.deImplement HasResizeThe following discussion from !1546 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1546#note_28434):
> I think has resize is also needed in other places. Theoretically we can just use a copy of https://web.math.pmf.unizg.hr/nastava/nrpdj/DuneDoc/release-2.6.1/dune-functions/doc/doxygen/html/a01948_source.html
> the implementation in dune functions and put it e.g. in dumux/common/concepts.hh
Also some other tiny "concepts" might be useful, however usually it's not real concepts so we should be careful.The following discussion from !1546 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1546#note_28434):
> I think has resize is also needed in other places. Theoretically we can just use a copy of https://web.math.pmf.unizg.hr/nastava/nrpdj/DuneDoc/release-2.6.1/dune-functions/doc/doxygen/html/a01948_source.html
> the implementation in dune functions and put it e.g. in dumux/common/concepts.hh
Also some other tiny "concepts" might be useful, however usually it's not real concepts so we should be careful.3.2