dumux-repositories issueshttps://git.iws.uni-stuttgart.de/groups/dumux-repositories/-/issues2019-09-20T14:40:51Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/766Dumux handbook should contain a building date and a git-version-hashmark on t...2019-09-20T14:40:51ZDavid WernerDumux handbook should contain a building date and a git-version-hashmark on titlepageWhile it is also possible to provide to provide meta-information on the webpage, it would be nice to have them also inside the pdf-file. It should not be that hard to add it, I think \today would do it for the date. Think also about to include branch or tag if available. Maybe a small script could generate some latex-output to handle over information. Or there is also latex-package like [gitinfo2](http://ctan.math.washington.edu/tex-archive/macros/latex/contrib/gitinfo2/gitinfo2.pdf).While it is also possible to provide to provide meta-information on the webpage, it would be nice to have them also inside the pdf-file. It should not be that hard to add it, I think \today would do it for the date. Think also about to include branch or tag if available. Maybe a small script could generate some latex-output to handle over information. Or there is also latex-package like [gitinfo2](http://ctan.math.washington.edu/tex-archive/macros/latex/contrib/gitinfo2/gitinfo2.pdf).https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/756Periodic Boundary Conditions for FreeFlow2019-09-19T11:45:52ZLars KaiserPeriodic Boundary Conditions for FreeFlow<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Periodic Boundary Conditions for FreeFlow
**What does this feature / why does DuMux need it**:
Periodic Boundary Conditions are a common and useful BC and help to overcome the problem of finding appropriate BC for finite domains.
**Which issue does this feature fix (if any)**
It would enable using Periodic Boundary Conditions in a coupled Darcy-FreeFlow model.
Periodic Boundary Conditions are already implemented for Darcy's law but can't be used reasonable in a coupled model with freeflow, because freeflow doesn't allow Periodic Boundary Conditions.
**Anything else we need to know?**:
Already mentioned in dumux-repositories/dumux#487<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Periodic Boundary Conditions for FreeFlow
**What does this feature / why does DuMux need it**:
Periodic Boundary Conditions are a common and useful BC and help to overcome the problem of finding appropriate BC for finite domains.
**Which issue does this feature fix (if any)**
It would enable using Periodic Boundary Conditions in a coupled Darcy-FreeFlow model.
Periodic Boundary Conditions are already implemented for Darcy's law but can't be used reasonable in a coupled model with freeflow, because freeflow doesn't allow Periodic Boundary Conditions.
**Anything else we need to know?**:
Already mentioned in dumux-repositories/dumux#4873.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/761Cleanup explicit flash of implicit 2p2c model2019-09-19T09:10:29ZBeatrix 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 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.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.1Beatrix BeckerBeatrix Beckerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/765Add pre-commit hook for generating README.md in the examples folder2019-09-18T13:36:07ZBernd FlemischAdd pre-commit hook for generating README.md in the examples folderThe script `merge_cpp_and_md.sh` in `bin/doc/` can be used to create for each example folder a `README.md` out of the relevant C++ and Markdown files. Automate this generation by installing a pre-commit hook.The script `merge_cpp_and_md.sh` in `bin/doc/` can be used to create for each example folder a `README.md` out of the relevant C++ and Markdown files. Automate this generation by installing a pre-commit hook.3.2Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/739Unit test for compositional flash2019-09-18T07:30:04ZBeatrix BeckerUnit test for compositional flashThere is none currentlyThere is none currently3.1Beatrix BeckerBeatrix Beckerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/448Discussion: Reintroduce model class as a way to specify model properties / Re...2019-09-14T11:31:14ZTimo Kochtimo.koch@iws.uni-stuttgart.deDiscussion: Reintroduce model class as a way to specify model properties / Remove TypeTag as template argument whereever feasibleI think it might make sense to reintroduce the model class as a place to specify things associated with a specific mathematical model, e.g. 2-phase 2-component porousmedium flow. In contrast to the old model class this class would know nothing about the linear algebra (solution, Jacobian), temporal or spatial discretization. Its member functions / data members would probably ~~most~~ all be static and constexpr. An idea would be something like
```c++
namespace Properties {
SET_PROP(TwoPTwoC, Model)
{
private:
// Some easy customization points through the property system
using FluidSystem = GET_PROP_TYPE(TypeTag, FluidSystem);
using ...
public:
// there are quite many template arguments but they can be conveniently set through the property system
using type = TwoPNCModel<FluidSystem, FluidState, ...>;
};
} // end namespace Properties
template<FSystem, BalanceTraits, ...>
class TwoPNCModel
{
// model specific constants
static constexpr std::size_t numEq() { return 2; }
static constexpr std::size_t numComponents() { return FSystem::numComponents; }
....
// model specific options, template parameters offer customization points through Traits/Policies
static constexpr bool useMoles() { return BalanceTraits::useMoles(); }
...
// model specific types
enum class Index // might be also a struct templated by formulation
{
pressureIdx = 0,
saturationIdx = 1
};
...
// model specific functions
template<typename Scalar>
static constexpr void checkPhysicalBounds(Scalar priVar, Index i)
{ ... }
static constexpr void defaultParams(Dune::ParameterTree& params, const std::string& paramGroup = "")
{ ... }
...
};
```
Other classes could get the model as a template parameter and extract a lot of types and other information from it.
I think it might make sense to reintroduce the model class as a place to specify things associated with a specific mathematical model, e.g. 2-phase 2-component porousmedium flow. In contrast to the old model class this class would know nothing about the linear algebra (solution, Jacobian), temporal or spatial discretization. Its member functions / data members would probably ~~most~~ all be static and constexpr. An idea would be something like
```c++
namespace Properties {
SET_PROP(TwoPTwoC, Model)
{
private:
// Some easy customization points through the property system
using FluidSystem = GET_PROP_TYPE(TypeTag, FluidSystem);
using ...
public:
// there are quite many template arguments but they can be conveniently set through the property system
using type = TwoPNCModel<FluidSystem, FluidState, ...>;
};
} // end namespace Properties
template<FSystem, BalanceTraits, ...>
class TwoPNCModel
{
// model specific constants
static constexpr std::size_t numEq() { return 2; }
static constexpr std::size_t numComponents() { return FSystem::numComponents; }
....
// model specific options, template parameters offer customization points through Traits/Policies
static constexpr bool useMoles() { return BalanceTraits::useMoles(); }
...
// model specific types
enum class Index // might be also a struct templated by formulation
{
pressureIdx = 0,
saturationIdx = 1
};
...
// model specific functions
template<typename Scalar>
static constexpr void checkPhysicalBounds(Scalar priVar, Index i)
{ ... }
static constexpr void defaultParams(Dune::ParameterTree& params, const std::string& paramGroup = "")
{ ... }
...
};
```
Other classes could get the model as a template parameter and extract a lot of types and other information from it.
Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/764[multidomain][boundary][stokesdarcy] couplingmapper does not need couplingman...2019-09-13T15:06:18ZKatharina Heck[multidomain][boundary][stokesdarcy] couplingmapper does not need couplingmanager<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
The couplingmapper could be simplified and not depend on the couplingmanager. The couplingmanager is only needed to get the FVGridgeometries in one function, which seems unnecessary.
**What does this feature / why does DuMux need it**:
The dependency of the mapper on the couplingmanager create issues when trying to combine several couplingmangers. Removing that also means that the constructor of the couplingmanager can be removed, which is also nice and easier for inheritance.<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
The couplingmapper could be simplified and not depend on the couplingmanager. The couplingmanager is only needed to get the FVGridgeometries in one function, which seems unnecessary.
**What does this feature / why does DuMux need it**:
The dependency of the mapper on the couplingmanager create issues when trying to combine several couplingmangers. Removing that also means that the constructor of the couplingmanager can be removed, which is also nice and easier for inheritance.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/719FVElementGeometry public alias FVGridGeometry is not generic enough2019-09-12T14:02:54ZTimo Kochtimo.koch@iws.uni-stuttgart.deFVElementGeometry public alias FVGridGeometry is not generic enoughFor compatibilty with FEM this alias should be called GridGeometry. In the FEElementGeoemtry this alias is actually still missing. This is needed to implement elementSolution/evalSolution for FEM.For compatibilty with FEM this alias should be called GridGeometry. In the FEElementGeoemtry this alias is actually still missing. This is needed to implement elementSolution/evalSolution for FEM.3.1Simon EmmertSimon Emmerthttps://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/757Reformulate diffusion laws to match with mass reference velocities2019-09-05T09:54:14ZKatharina HeckReformulate diffusion laws to match with mass reference velocitiesAs discussed previously: if Darcys law and Navier Stokes law give mass averaged velocities we need to adapt the diffusion laws to calculate the gradient based on mass fractions not mole fractions.As discussed previously: if Darcys law and Navier Stokes law give mass averaged velocities we need to adapt the diffusion laws to calculate the gradient based on mass fractions not mole fractions.3.1Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/763[FreeFlow] No Newton convergence for pressure Dirichlet BCs at high Re2019-09-05T07:39:06ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[FreeFlow] No Newton convergence for pressure Dirichlet BCs at high ReFor simple pipe flow, setting Dirichlet BCs for the pressure both at the inlet and outlet
works well for low Re. For higher Re, the Newton scheme does not converge anymore.
Setting the inlet BCs to Dirichlet for velocity works.
This should be investigated. Maybe the assumption of
$`\nabla \mathbf{v} \cdot \mathbf{n} = 0 `$
and
$`\nabla p \cdot \mathbf{n} = 0 `$
used for the pressure BC causes this problem?For simple pipe flow, setting Dirichlet BCs for the pressure both at the inlet and outlet
works well for low Re. For higher Re, the Newton scheme does not converge anymore.
Setting the inlet BCs to Dirichlet for velocity works.
This should be investigated. Maybe the assumption of
$`\nabla \mathbf{v} \cdot \mathbf{n} = 0 `$
and
$`\nabla p \cdot \mathbf{n} = 0 `$
used for the pressure BC causes this problem?3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/762Dumux release 3.12019-09-04T06:38:08ZKatharina HeckDumux release 3.1All major changes that should be included and are not yet committed should be announced.
Add a comment here describing the feature and areas affected by the change.All major changes that should be included and are not yet committed should be announced.
Add a comment here describing the feature and areas affected by the change.3.12019-10-11Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/760Tests for flashs don't test anything2019-08-29T12:59:01ZBeatrix BeckerTests for flashs don't test anythingThey never fail, just print an error.They never fail, just print an error.3.1Beatrix BeckerBeatrix Beckerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/759compositionalflash.hh: iterate saturation and pressure within flash2019-08-28T15:13:56ZBeatrix Beckercompositionalflash.hh: iterate saturation and pressure within flashThe function `concentrationFlash2p2c` gets both phase pressures as input. Since the saturation is unknown, one of these pressures (more precisely, the capillary pressure) is unknown, too. In the code the pressure is iterated outside of the flash, e.g., in the routine that updates the secondary variables, and the flash is called several times during that iteration. This is not consistent with the implicit code, in my opinion, and also not very convenient. The flash should take care of iterating saturation and pressure, in my opinion.The function `concentrationFlash2p2c` gets both phase pressures as input. Since the saturation is unknown, one of these pressures (more precisely, the capillary pressure) is unknown, too. In the code the pressure is iterated outside of the flash, e.g., in the routine that updates the secondary variables, and the flash is called several times during that iteration. This is not consistent with the implicit code, in my opinion, and also not very convenient. The flash should take care of iterating saturation and pressure, in my opinion.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/758compositionalflash.hh: porosity is not used2019-08-28T15:03:37ZBeatrix Beckercompositionalflash.hh: porosity is not usedSome functions in CompositionalFlash require porosity as input, which is never used. Needs to be deleted and deprecated.Some functions in CompositionalFlash require porosity as input, which is never used. Needs to be deleted and deprecated.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/689Create meaningful new 2pncmin NI test2019-08-28T14:15:32ZSimon EmmertCreate 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/654Allow C++172019-08-28T10:22:45ZTimo Kochtimo.koch@iws.uni-stuttgart.deAllow C++17I think quite some new features speak for allowing C++17. There are some compilers supporting all features, gcc 8 or gcc 7 (without std::filesystem), clang 8 or 5 (without std::filesystem). https://en.cppreference.com/w/cpp/compiler_support. However, there seems to be no cray compiler.
Who is using the newest Dumux version on a platform without C++17 support?I think quite some new features speak for allowing C++17. There are some compilers supporting all features, gcc 8 or gcc 7 (without std::filesystem), clang 8 or 5 (without std::filesystem). https://en.cppreference.com/w/cpp/compiler_support. However, there seems to be no cray compiler.
Who is using the newest Dumux version on a platform without C++17 support?3.2https://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-08-28T10:09:12ZTimo 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.1Timo Kochtimo.koch@iws.uni-stuttgart.deTimo Kochtimo.koch@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/711Access to problem quantities (like thermal conductivity) model dependent2019-08-28T10:03:55ZAlexander 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.2