dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues2019-07-19T14:23:41Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/741BoundaryFlag for ALUGrid with Gmsh mesh file2019-07-19T14:23:41ZSamuel ScherrerBoundaryFlag for ALUGrid with Gmsh mesh fileA while ago I had problems with the `BoundaryFlag` specialization for `ALUGrid`, as described [on the mailing list](https://listserv.uni-stuttgart.de/pipermail/dumux/2019q2/002307.html)
Timo did propose a clean solution, however, this was beyond my C++ skills. Since it is also not easy to change the value of `DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS`, would it be possible to add an additional compile time flag to the check whether the BoundaryFlag specialization for ALUGrid should be used?
That is, changing line 198 of dumux/io/grid/gridmanager_alu.hh from
```
#if DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS
```
to
```
#if DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS && !defined(USE_GMSH_BOUNDARY_FLAGS_WITH_ALUGRID)
```
If so, are there any naming preferences?A while ago I had problems with the `BoundaryFlag` specialization for `ALUGrid`, as described [on the mailing list](https://listserv.uni-stuttgart.de/pipermail/dumux/2019q2/002307.html)
Timo did propose a clean solution, however, this was beyond my C++ skills. Since it is also not easy to change the value of `DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS`, would it be possible to add an additional compile time flag to the check whether the BoundaryFlag specialization for ALUGrid should be used?
That is, changing line 198 of dumux/io/grid/gridmanager_alu.hh from
```
#if DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS
```
to
```
#if DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS && !defined(USE_GMSH_BOUNDARY_FLAGS_WITH_ALUGRID)
```
If so, are there any naming preferences?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/742Unused reference solutions2019-07-19T12:53:09ZBernd FlemischUnused reference solutionsThese reference solutions are currently not used:
```text
1p2ctestccmpfa-reference.vtu
1pnctestbox-00009.vtu
1pnctestcc-00009.vtu
1ptestccmpfa-reference.vtu
2cnistokes2p2cniboundarylayer-ff-reference.vtu
2cnistokes2p2cni-ff-reference.vtu
2cnistokes2p2cni-pm-reference.vtu
2cnizeroeq2p2cni-ff-reference.vtu
2cstokes2p2c-ff-reference.vtu
2czeroeq2p2c-ff-reference.vtu
2pdfm-reference.vtu
box1pncmin-00042.vtu
box2pmincdist-reference.vtu
box2pmincvol-reference.vtu
cc1pncmin-00042.vtu
ccmpfatracer-reference.vtu
el1p2c-reference.vtu
el2p-parallel-reference.vtu
el2p-reference.vtu
elasticmatrix-reference.vtu
forchheimer1p-reference.vtp
forchheimer2p-reference.vtu
generalizeddirichlet-reference.vtp
generallens_box-reference.vtu
generallens_cc-reference.vtu
generallens_sequential-reference.vtu
rosi2c-root-reference.vtp
rosi2c-soil-reference.vtu
test_adaptive2p2c2d-reference.vtu
test_adaptive2p2c3d-reference.vtu
test_ff_navierstokes_sincos_stationary-reference.vtu
test_md_boundary_darcy2p2cni_stokes1p2cni_vertical_darcy-reference.vtu
test_md_boundary_darcy2p2cni_stokes1p2cni_vertical_stokes-reference.vtu
test_md_boundary_darcy2p2c_stokes1p2c_vertical_darcy-reference.vtu
test_md_boundary_darcy2p2c_stokes1p2c_vertical_stokes-reference.vtu
```
If nobody objects in general or against individual files before July 21, I will file a merge request that deletes the (remaining) files.These reference solutions are currently not used:
```text
1p2ctestccmpfa-reference.vtu
1pnctestbox-00009.vtu
1pnctestcc-00009.vtu
1ptestccmpfa-reference.vtu
2cnistokes2p2cniboundarylayer-ff-reference.vtu
2cnistokes2p2cni-ff-reference.vtu
2cnistokes2p2cni-pm-reference.vtu
2cnizeroeq2p2cni-ff-reference.vtu
2cstokes2p2c-ff-reference.vtu
2czeroeq2p2c-ff-reference.vtu
2pdfm-reference.vtu
box1pncmin-00042.vtu
box2pmincdist-reference.vtu
box2pmincvol-reference.vtu
cc1pncmin-00042.vtu
ccmpfatracer-reference.vtu
el1p2c-reference.vtu
el2p-parallel-reference.vtu
el2p-reference.vtu
elasticmatrix-reference.vtu
forchheimer1p-reference.vtp
forchheimer2p-reference.vtu
generalizeddirichlet-reference.vtp
generallens_box-reference.vtu
generallens_cc-reference.vtu
generallens_sequential-reference.vtu
rosi2c-root-reference.vtp
rosi2c-soil-reference.vtu
test_adaptive2p2c2d-reference.vtu
test_adaptive2p2c3d-reference.vtu
test_ff_navierstokes_sincos_stationary-reference.vtu
test_md_boundary_darcy2p2cni_stokes1p2cni_vertical_darcy-reference.vtu
test_md_boundary_darcy2p2cni_stokes1p2cni_vertical_stokes-reference.vtu
test_md_boundary_darcy2p2c_stokes1p2c_vertical_darcy-reference.vtu
test_md_boundary_darcy2p2c_stokes1p2c_vertical_stokes-reference.vtu
```
If nobody objects in general or against individual files before July 21, I will file a merge request that deletes the (remaining) files.3.12019-07-21Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/744Unused headers2019-07-19T12:39:45ZBernd FlemischUnused headersThe following headers are currently not used in Dumux itself. Please change the table to mark the headers for something else than "delete", if you think that they should be kept. Please do so before July 26.
| header | delete | test | keep w/o test |
| -------------------------------------- |:------:|:----:|:-------------:|
| common/intrange.hh | X | | |
| discretization/basefvgridgeometry.hh | X | | |
| io/grid/cakegridcreator.hh | X | | |
| io/grid/subgridgridcreator.hh | X | | |
| material/binarycoefficients/h2o_ch4.hh | X | | |The following headers are currently not used in Dumux itself. Please change the table to mark the headers for something else than "delete", if you think that they should be kept. Please do so before July 26.
| header | delete | test | keep w/o test |
| -------------------------------------- |:------:|:----:|:-------------:|
| common/intrange.hh | X | | |
| discretization/basefvgridgeometry.hh | X | | |
| io/grid/cakegridcreator.hh | X | | |
| io/grid/subgridgridcreator.hh | X | | |
| material/binarycoefficients/h2o_ch4.hh | X | | |3.12019-07-26Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/743Strongly enforced Dirichlet constraints for box (all, only multidomain) and c...2019-07-16T15:10:45ZTimo Kochtimo.koch@iws.uni-stuttgart.deStrongly enforced Dirichlet constraints for box (all, only multidomain) and cell-centered (internal, core+multidomain) not correct<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
* For box multidomain:
If Dirichlet is set for a dof that also has a coupling derivative the entire matrix line has to be set to zero. Currently this is only done for the diagonal block. This bug might be actually in use for the boundary coupling code where this kind of incorporation is wanted, but also this is not a Dirichlet constraint (equation is not replaced by the Dirichlet constraint but by the coupling condition).
* For cell-centered (internal Dirichlet):
The Dirichlet conditions are currently enforced in the local assembler. However due to the assembly procedure the matrix rows are overwritten again later in the assembly of other elements. In order to fix this the constraints need to be either implemented after the whole matrix has been assembled (local caches cannot be reused), or (more complicated to read but maybe more efficient) they have to be incorporated during the assembly (don't write anything in rows of Dirichlet dofs)
**What happened / Problem description**:
Jacobian is corrupted.
**What you expected to happen**:
Dirichlet constraints are strongly enforced in the matrix.
**How to reproduce it (as minimally and precisely as possible)**:
The internal Dirichlet test for cell-centered.
**Anything else we need to know?**:
We should think about a better solution how and when to incorporate Dirichlet constraints.
**Environment**:
- DuMux version: master (the cell-centered part was only instroduced recently), 3.0 (box)<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
* For box multidomain:
If Dirichlet is set for a dof that also has a coupling derivative the entire matrix line has to be set to zero. Currently this is only done for the diagonal block. This bug might be actually in use for the boundary coupling code where this kind of incorporation is wanted, but also this is not a Dirichlet constraint (equation is not replaced by the Dirichlet constraint but by the coupling condition).
* For cell-centered (internal Dirichlet):
The Dirichlet conditions are currently enforced in the local assembler. However due to the assembly procedure the matrix rows are overwritten again later in the assembly of other elements. In order to fix this the constraints need to be either implemented after the whole matrix has been assembled (local caches cannot be reused), or (more complicated to read but maybe more efficient) they have to be incorporated during the assembly (don't write anything in rows of Dirichlet dofs)
**What happened / Problem description**:
Jacobian is corrupted.
**What you expected to happen**:
Dirichlet constraints are strongly enforced in the matrix.
**How to reproduce it (as minimally and precisely as possible)**:
The internal Dirichlet test for cell-centered.
**Anything else we need to know?**:
We should think about a better solution how and when to incorporate Dirichlet constraints.
**Environment**:
- DuMux version: master (the cell-centered part was only instroduced recently), 3.0 (box)3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/740Enforce constraints in fluid state or algorithm?2019-07-15T15:18:34ZBeatrix 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.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/739Unit test for compositional flash2019-07-15T15:14:19ZBeatrix BeckerUnit test for compositional flashThere is none currentlyThere is none currently3.1Beatrix BeckerBeatrix Beckerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/738ParamterFile is shown as unused parameter2019-07-14T22:01:23ZTimo Kochtimo.koch@iws.uni-stuttgart.deParamterFile is shown as unused parameterIf a parameter file is passed it is shown under unused parameters. This is confusing.If a parameter file is passed it is shown under unused parameters. This is confusing.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/737Creating a bounding box tree for a vector of geometries2019-07-12T15:19:36ZTimo 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.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/736Plot over line class2019-07-12T15:15:55ZTimo 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)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/724[Navier Stokes] Gravity upwinding2019-07-04T11:53:43ZMelanie 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?Melanie LippMelanie Lipphttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/734Make cakegridcreator work for the case that the well is not excluded from the...2019-07-03T10:10:37ZMartin SchneiderMake cakegridcreator work for the case that the well is not excluded from the gridAt the moment it seems that the cakegridcreator only works if the well is
excluded from the grid. This allows to use cubic cells.
However, if the well is for example modelled using a line source, the well
should not be excluded from the grid.
Thus, it would be nice if this gridcreator could generate a grid where the well is not excluded.
This could be done by using prism cells at the well location.At the moment it seems that the cakegridcreator only works if the well is
excluded from the grid. This allows to use cubic cells.
However, if the well is for example modelled using a line source, the well
should not be excluded from the grid.
Thus, it would be nice if this gridcreator could generate a grid where the well is not excluded.
This could be done by using prism cells at the well location.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/733Make MPFA handle zero coefficients (like effective diffusion coefficient)2019-07-02T09:01:26ZTimo 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.1Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/448Discussion: Reintroduce model class as a way to specify model properties / Re...2019-06-28T09:46:56ZTimo 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/721[Navier-Stokes] Revise definition of transporting velocity on boundary for mo...2019-06-27T12:07:55ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[Navier-Stokes] Revise definition of transporting velocity on boundary for momentum upwindingThe transporting velocity is always
```
const Scalar transportingVelocity = faceVars.velocityLateralInside(localSubFaceIdx);
```
However, if the own scvf lies on a boundary and a tangential slip velocity is specified, we should probably rather take this value.The transporting velocity is always
```
const Scalar transportingVelocity = faceVars.velocityLateralInside(localSubFaceIdx);
```
However, if the own scvf lies on a boundary and a tangential slip velocity is specified, we should probably rather take this value.3.1https://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/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/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 avoidhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/719FVElementGeometry public alias FVGridGeometry is not generic enough2019-06-26T13:39:07ZTimo 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.Simon ScholzSimon Scholzhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/729Timeout with grid data communication and parallel alugrid (Dune master only)2019-06-25T16:39:24ZTimo Kochtimo.koch@iws.uni-stuttgart.deTimeout with grid data communication and parallel alugrid (Dune master only)<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
test_gridmanager_gmsh_3d_alu_parallel fails on dune master with a timeout.
**Environment**:
- Dune version: master
- DuMux version: master
- Others: gcc and clang<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
test_gridmanager_gmsh_3d_alu_parallel fails on dune master with a timeout.
**Environment**:
- Dune version: master
- DuMux version: master
- Others: gcc and clang3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/524(Re-)Implement CFL criterion2019-06-25T16:32:50ZTimo Kochtimo.koch@iws.uni-stuttgart.de(Re-)Implement CFL criterionAs a first step of porting the decoupled/sequential models to the new structure, it would be a good thing to implement a CFL criterion for the time step control for the current porousmediumflow models. Add good start is e.g. a CFL is e.g. the 1p_tracer test (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/tree/master/test/porousmediumflow/tracer/1ptracer) that uses an explicit Euler for the transport but currently has a constant time step that is small enough for the test. CFL would be a big improvement.
@martins Maybe you are the best to deal with this?As a first step of porting the decoupled/sequential models to the new structure, it would be a good thing to implement a CFL criterion for the time step control for the current porousmediumflow models. Add good start is e.g. a CFL is e.g. the 1p_tracer test (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/tree/master/test/porousmediumflow/tracer/1ptracer) that uses an explicit Euler for the transport but currently has a constant time step that is small enough for the test. CFL would be a big improvement.
@martins Maybe you are the best to deal with this?3.1Martin SchneiderMartin Schneider