dumux-repositories issueshttps://git.iws.uni-stuttgart.de/groups/dumux-repositories/-/issues2019-05-21T12:19:00Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/657Turbulent diffusion in shallow water equations2019-05-21T12:19:00ZFrank PlatzekTurbulent diffusion in shallow water equationsAdd diffusion terms to the shallow water equations. One or more turbulence models will follow later. For now a rudimentary implementation is chosen which is only accurate on orthogonal grids. Possible non-orthogonal corrections will be added later on.Add diffusion terms to the shallow water equations. One or more turbulence models will follow later. For now a rudimentary implementation is chosen which is only accurate on orthogonal grids. Possible non-orthogonal corrections will be added later on.Frank PlatzekFrank Platzekhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/660Pass FluxVarsCache to Neumann Function2019-06-25T12:31:26ZDennis GläserPass FluxVarsCache to Neumann FunctionWe build the flux variable caches for boundary faces, but do not hand them into the Neumann function, where it could be used. For box, we actually never use the object, so it's unnecessary overhead.We build the flux variable caches for boundary faces, but do not hand them into the Neumann function, where it could be used. For box, we actually never use the object, so it's unnecessary overhead.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/661Possibly include update of Box flux variables cache2019-05-18T11:37:21ZDennis GläserPossibly include update of Box flux variables cacheThe flux variable caches for the box scheme are always assumed to be solution-independent. We should think of a way to support user-defined, solution-dependent caches.The flux variable caches for the box scheme are always assumed to be solution-independent. We should think of a way to support user-defined, solution-dependent caches.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/670[md][stokesdarcy] Upwinding of component enthalpy is probably wrong2019-05-18T11:52:06ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[md][stokesdarcy] Upwinding of component enthalpy is probably wrong```c++
const bool insideDiffFluxIsUpstream = std::signbit(diffusiveFlux[domainICompIdx]);
```
should probably be
```c++
const bool insideDiffFluxIsUpstream = diffusiveFlux[domainICompIdx] > 0.0;
```
* [ ] Furthermore, we should check if all fluidsystems implement `componentEnthalpy`.```c++
const bool insideDiffFluxIsUpstream = std::signbit(diffusiveFlux[domainICompIdx]);
```
should probably be
```c++
const bool insideDiffFluxIsUpstream = diffusiveFlux[domainICompIdx] > 0.0;
```
* [ ] Furthermore, we should check if all fluidsystems implement `componentEnthalpy`.3.1Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/674Test make geometry fails sporadically2019-03-14T17:52:30ZTimo Kochtimo.koch@iws.uni-stuttgart.deTest make geometry fails sporadicallyFrom time to time the make geometry tests fails. It does so only sporadically, so there seems to be some random component.
```
testing for non axis-aligned quadrilateral
testing for quadrilateral with normal in z direction
testing for quadrilateral with normal in y direction
testing for quadrilateral with normal in x direction
Dune::InvalidStateException [permutatePointsAndTest:/data/src/dumux/test/common/geometry/test_makegeometry.cc:69]: Area of quadrilateral after permuation of input points is wrong
Test #9: test_makegeometry ................***Failed 0.23 sec
```From time to time the make geometry tests fails. It does so only sporadically, so there seems to be some random component.
```
testing for non axis-aligned quadrilateral
testing for quadrilateral with normal in z direction
testing for quadrilateral with normal in y direction
testing for quadrilateral with normal in x direction
Dune::InvalidStateException [permutatePointsAndTest:/data/src/dumux/test/common/geometry/test_makegeometry.cc:69]: Area of quadrilateral after permuation of input points is wrong
Test #9: test_makegeometry ................***Failed 0.23 sec
```3.1Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/675[freeflow] Remove property NormalizePressure2019-04-02T06:11:33ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[freeflow] Remove property NormalizePressureWhen enabled, all pressure related calculations for the momentum equations are done with `p - p_const`. The idea was to lower the numerical values of the pressure in the hope of decreasing numerical errors when further processing the values in for the Jacobian. However, `p - p_const` probably already introduces the same error we wanted to avoid in the first place.
The property and the pressure normalization should therefore be removed after a check of the Matrix' condition number.When enabled, all pressure related calculations for the momentum equations are done with `p - p_const`. The idea was to lower the numerical values of the pressure in the hope of decreasing numerical errors when further processing the values in for the Jacobian. However, `p - p_const` probably already introduces the same error we wanted to avoid in the first place.
The property and the pressure normalization should therefore be removed after a check of the Matrix' condition number.3.1Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/676[components] TabulatedComponent cannot be used for all components (e.g., air)2019-05-18T11:53:38ZKilian 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.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/682Test tabulation doesn't actually test anything2019-03-27T19:33:51ZTimo 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.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/684Fingering in freeflow test test_ff_stokes2c_densitydrivenflow to be expected?2019-04-05T05:35:59ZBeatrix BeckerFingering in freeflow test test_ff_stokes2c_densitydrivenflow to be expected?The freeflow test `test_ff_stokes2c_densitydrivenflow` in `/test/freeflow/navierstokesnc/densitydrivenflow` shows fingers depending on Newton.MaxRelativeShift. As an example, a comparison of the magnitude of the velocity with Newton.MaxRelativeShift = 1e-14 (left) and Newton.MaxRelativeShift = 1e-8 (right) is shown below:
![Screenshot_20190328_103436](/uploads/c41421f0e0d85e05452f35ddbd0aeb6c/Screenshot_20190328_103436.png)
We should investigate if there is a physical basis for the appearance of fingers in this test.The freeflow test `test_ff_stokes2c_densitydrivenflow` in `/test/freeflow/navierstokesnc/densitydrivenflow` shows fingers depending on Newton.MaxRelativeShift. As an example, a comparison of the magnitude of the velocity with Newton.MaxRelativeShift = 1e-14 (left) and Newton.MaxRelativeShift = 1e-8 (right) is shown below:
![Screenshot_20190328_103436](/uploads/c41421f0e0d85e05452f35ddbd0aeb6c/Screenshot_20190328_103436.png)
We should investigate if there is a physical basis for the appearance of fingers in this test.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/686Improve usage of container types in staggered2019-06-25T12:29:55ZKilian 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.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/689Create meaningful new 2pncmin NI test2019-04-24T07:48:32ZSimon ScholzCreate meaningful new 2pncmin NI testWe forgot to add the thermal conductivity law for the 2pncmin **NI** cases because there is no test available. This is addressed in !1560
We should come up with a (in my opinion) **new** test that uses the NI. I think a new test would be beneficial, because the current 2pncmin test is already relatively unstable.We forgot to add the thermal conductivity law for the 2pncmin **NI** cases because there is no test available. This is addressed in !1560
We should come up with a (in my opinion) **new** test that uses the NI. I think a new test would be beneficial, because the current 2pncmin test is already relatively unstable.3.1Theresa KurzTheresa Kurzhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/690[material][co2] create co2 tables with pressures less than 1 bar2019-05-20T07:02:22ZKatharina 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/700Test virtual interface for Problem2019-05-16T15:50:49ZTimo Kochtimo.koch@iws.uni-stuttgart.deTest virtual interface for ProblemGetting rid of the problem template would be a huge improvement in the code.
We should do performance measurement and check what run-time penalty a virtual problem interface would bring.
For that we have to first check which functions actually need to be virtual, add the virtual keyword, we could then exchange templates for a base class pointer one-by-one, and check for performance penalties.
The highest penalty is probably expected for a grid with a high boundary to internal cell ratio, and simple boundary and initial conditions so that the possible virtual function call would actually matter.Getting rid of the problem template would be a huge improvement in the code.
We should do performance measurement and check what run-time penalty a virtual problem interface would bring.
For that we have to first check which functions actually need to be virtual, add the virtual keyword, we could then exchange templates for a base class pointer one-by-one, and check for performance penalties.
The highest penalty is probably expected for a grid with a high boundary to internal cell ratio, and simple boundary and initial conditions so that the possible virtual function call would actually matter.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/703Spatial parameters cannot be time dependent if not solution-dependent2019-05-20T13:40:24ZTimo 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.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/704Multiphase tracer produces singular matrix if saturation is zero2019-05-28T13:31:05ZTimo 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.Timo 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-06-27T09:36:36ZTimo 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.1Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/711Access to problem quantities (like thermal conductivity) model dependent2019-06-27T09:31:31ZAlexander 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 avoid