dumux-repositories issueshttps://git.iws.uni-stuttgart.de/groups/dumux-repositories/-/issues2019-08-30T08:46:24Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/761Cleanup explicit flash of implicit 2p2c model2019-08-30T08:46:24ZBeatrix 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/737Creating a bounding box tree for a vector of geometries2019-08-28T09:56:45ZTimo 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/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/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.2https://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/675[freeflow] Remove property NormalizePressure2019-08-28T08:59:00ZKilian 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.2Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/661Possibly include update of Box flux variables cache2019-08-28T09:07:23ZDennis 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.2https://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/652Provide interface for more parallel solvers/preconditioners of ISTL2019-02-01T07:13:01ZLeopold StadlerProvide interface for more parallel solvers/preconditioners of ISTLSo far we have only the AMG-backend (parallel linear solver based on the ISTL AMG preconditioner and the ISTL BiCGSTAB solver). It would be great to add support for more preconditioners and solvers of ISTL.
The following combinations should be available:
* SSOR with BiCGSTAB
* ILU with BiCGSTAB
* ILU with GMRES
Are there any further wishes ?So far we have only the AMG-backend (parallel linear solver based on the ISTL AMG preconditioner and the ISTL BiCGSTAB solver). It would be great to add support for more preconditioners and solvers of ISTL.
The following combinations should be available:
* SSOR with BiCGSTAB
* ILU with BiCGSTAB
* ILU with GMRES
Are there any further wishes ?Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/524(Re-)Implement CFL criterion2019-08-28T09:37:51ZTimo 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.2Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/436Minimize private alias declarations and static constants?2018-02-28T13:59:35ZBernd FlemischMinimize private alias declarations and static constants?Currently, each Dumux class that takes a TypeTag as template parameter typically contains several/many private alias declarations and static constant definitions extracted from the TypeTag. This may happen hundreds of lines above the first usage of the declared names.
An alternative would be to put the declarations as close as possible to the place where they are used. If the declarations are used as function parameter / return types, one could use template parameters / auto instead.
The expected benefit would be an improved readability of the code and the avoidance of unused declarations and definitions.
In order to discuss this, I set up !741. Please have a look and share your opinions here.Currently, each Dumux class that takes a TypeTag as template parameter typically contains several/many private alias declarations and static constant definitions extracted from the TypeTag. This may happen hundreds of lines above the first usage of the declared names.
An alternative would be to put the declarations as close as possible to the place where they are used. If the declarations are used as function parameter / return types, one could use template parameters / auto instead.
The expected benefit would be an improved readability of the code and the avoidance of unused declarations and definitions.
In order to discuss this, I set up !741. Please have a look and share your opinions here.https://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/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/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/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/756Periodic Boundary Conditions for FreeFlow2019-08-29T04:38:01ZLars 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.1