dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2020-03-18T09:22:07Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/436Minimize private alias declarations and static constants?2020-03-18T09:22:07ZBernd 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 fir...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/448Discussion: Reintroduce model class as a way to specify model properties / Re...2021-03-25T08:42:17ZTimo Kochtimokoch@math.uio.noDiscussion: 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 n...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/351Replace gas viscosity calculations2021-03-25T08:36:01ZBernd FlemischReplace gas viscosity calculationsSee #333. What is done for air, can also be done for N2, O2, ...See #333. What is done for air, can also be done for N2, O2, ...Holger ClassHolger Classhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/320Implementation of dispersion2020-08-26T08:02:11ZAlexander KissingerImplementation of dispersionA dispersion interface should be implemented that hopefully works for all discretizations.
## Old flyspray description
#### Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by |...A dispersion interface should be implemented that hopefully works for all discretizations.
## Old flyspray description
#### Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Alexander Kissinger (alexander.kissinger@iws.uni-stuttgart.de) |
| Reported at | Mar 30, 2016 15:18 |
| Type | Bug Report |
| Version | 2.9 |
#### Description
I noticed that the implementation of dispersion in the 1p2c model may not be correct for applications using the cell centered discretization.
The dispersion tensor needs to be evaluated at the interface between two dofs. It requires the velocity at that location.
For the Box method this can easily be achieved using the potential gradient evaluated from multiple dofs in the element. For the CC method however the potential gradient calculated currently at the interface only depends on the two opposing dofs (i and j). This will generally not result in the correct velocity.
A correct implementation would require an interpolation of the two cell velocities i and j at the interface.
Example:
Flow parallel to the interface between i and j would result in a zero velocity at the interface as there is no potential gradient between i and j and the velocity component parallel to the interface is not considered. As a result also the transverse dispersion would be zero.Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/264FS#264 Adaptivity with Parallelization2021-03-09T12:18:04ZMartin SchneiderFS#264 Adaptivity with Parallelization# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Implicit models |
| Reported by | Martin Schneider (martin.schneider@iws.uni-stuttgart.de) |
| Reported at | May 5, 2015 06:40 |
| Type | Feat...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Implicit models |
| Reported by | Martin Schneider (martin.schneider@iws.uni-stuttgart.de) |
| Reported at | May 5, 2015 06:40 |
| Type | Feature Request |
| Version | 2.7 |
# Description
The adaptive implicit problems are not yet implementented for parallelization.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/214FS#214 Implement naming rules for class names2020-05-27T06:52:38ZBernd FlemischFS#214 Implement naming rules for class names# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Nov 4, 2013 09:34 |
| Type | Feature Request |
| Versi...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Nov 4, 2013 09:34 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Last edited at | Jan 22, 2016 10:18 |
# Description
From 2.3 to 2.4, all member functions and enums have been adapted to our naming conventions. We want to evaluate how we want to do this for class names. Currently, we have inconsistencies like TwoPTwoCNI and Stokes2cni. We discuss in particular the issue about digits in class names.
Newer compilers should provide easier deprecation possibilities. An example will follow.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/210FS#210 enthalpy of dissolved component2020-10-30T00:57:57ZFSFS#210 enthalpy of dissolved component# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Fluid systems |
| Reported by | Philipp Nuske (philipp.nuske@iws.uni-stuttgart.de) |
| Reported at | Oct 16, 2013 08:40 |
| Type | Potential T...# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Fluid systems |
| Reported by | Philipp Nuske (philipp.nuske@iws.uni-stuttgart.de) |
| Reported at | Oct 16, 2013 08:40 |
| Type | Potential Thesis/Job |
| Version | Git |
| Last edited by | Nicolas Schwenck (nicolas.schwenck@iws.uni-stuttgart.de) |
| Last edited at | Sep 22, 2015 06:52 |
# Description
In the fluidsystems currently used in \\\\\\\\Dumux (those that do not use tables), the enthalpy of the dissolved component is either neglected (e.g. n2 in H2O in h2on2fluidsystem) or the enthalpy of the gas state is used (h2on2fluidsystemkinetic).
In either case the enthalpy of dissolution http://en.wikipedia.org/wiki/Enthalpy_change_of_solution is neglected.
If this is on purpose, it should be somewhere documented.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/510Introduce WallFunction Boundary condition for FF2019-05-04T20:09:50ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deIntroduce WallFunction Boundary condition for FFTo make to use of the wall function more clear and explicit, we could introduce a wall function boundary condition
which can only be set (using `std::enable_if`) if the FF model actually support it.To make to use of the wall function more clear and explicit, we could introduce a wall function boundary condition
which can only be set (using `std::enable_if`) if the FF model actually support it.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/524(Re-)Implement CFL criterion2021-03-25T08:35:28ZTimo Kochtimokoch@math.uio.no(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...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?Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/538[RANS] Make calculation of velocity gradients and wall functions more general2020-08-26T08:01:41ZNed Coltman[RANS] Make calculation of velocity gradients and wall functions more generalInspired by #532.
When considering a domain that features a pointy tip like illustrated below, it might be the case that the cell at the tip does not have any vertical or horizontal neighbors. Right now, in this case, the gradient in th...Inspired by #532.
When considering a domain that features a pointy tip like illustrated below, it might be the case that the cell at the tip does not have any vertical or horizontal neighbors. Right now, in this case, the gradient in this case will be set to 0 (!1130).
```cpp
++++++
+++
+
```
The should be further generalized to such that all wall functions, gradients, and functions for the boundaries are created in a separate class, rather than in each problem file.Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/540restart for adaptive grids2021-03-09T12:13:45ZBernd Flemischrestart for adaptive gridsEvolved from #458.
For enabling restart on adaptive grids, it is necessary to backup/restore the complete grid hierarchy. Dune offers the [BackupRestoreFacility](https://dune-project.org/doxygen/2.6.0/structDune_1_1BackupRestoreFacility...Evolved from #458.
For enabling restart on adaptive grids, it is necessary to backup/restore the complete grid hierarchy. Dune offers the [BackupRestoreFacility](https://dune-project.org/doxygen/2.6.0/structDune_1_1BackupRestoreFacility.html) for this. Which might not be implemented by `UGGrid` which offers its own [`save/loadState` routines](https://dune-project.org/doxygen/2.6.0/classDune_1_1UGGrid.html).https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/542add restart functionality for elastic models2021-03-09T12:22:04ZBernd Flemischadd restart functionality for elastic modelsOne has to
- generalize `loadSolution` such that a field with `numComponents > 1` can be read from a Vtk file into a solution vector,
- implement `primaryVariableName` in the model traits of the elastic models,
- add a corresponding test.One has to
- generalize `loadSolution` such that a field with `numComponents > 1` can be read from a Vtk file into a solution vector,
- implement `primaryVariableName` in the model traits of the elastic models,
- add a corresponding test.3.5Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/559Add incremental formulation for geomechanics2020-03-18T10:07:07ZBernd FlemischAdd incremental formulation for geomechanicsEspecially for subsurface applications, the incremental formulation is superior to the currently implemented absolute one. Should be implemented such that the user has the choice between the incremental and the absolute formulation.Especially for subsurface applications, the incremental formulation is superior to the currently implemented absolute one. Should be implemented such that the user has the choice between the incremental and the absolute formulation.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/586Analytical differentiation with MultiDomain2020-03-18T10:06:59ZDennis GläserAnalytical differentiation with MultiDomainIt seems like the interfaces for analytical differentiation disappeared from the base coupling manager, but are still called from the local assemblers.
We should clean this up and revise the assemble routines for analytical differentiat...It seems like the interfaces for analytical differentiation disappeared from the base coupling manager, but are still called from the local assemblers.
We should clean this up and revise the assemble routines for analytical differentiation in the local multidomain assemblers. Also, we should introduce the respective interfaces to the base coupling managers and throw proper error messages.
@timok, didn't you have an implementation for analytical differentiation in the embedded framework? I don't see it anymore...Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/619Output module doesn't work for multidomain when depending on coupling2021-03-09T12:22:20ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deOutput module doesn't work for multidomain when depending on couplingf9668a803c076bfb32d2a442d95d3db439f65e80 introduces a call to `neumann()` function.
For coupled StokesDarcy problems, `neumann()` depends on a bound coupling context.f9668a803c076bfb32d2a442d95d3db439f65e80 introduces a call to `neumann()` function.
For coupled StokesDarcy problems, `neumann()` depends on a bound coupling context.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/626Decouple physics and discretization (Do not always include all discretization...2020-03-18T10:06:44ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deDecouple physics and discretization (Do not always include all discretization schemes for flux laws?)When making a change, e.g., to the MPFA-version of Fick's law, all porousmediumflow and freeflow test have to be rebuild.
Is there a way to circumvent this?
This goes in a similar direction as #583.
Do we really need to include the ac...When making a change, e.g., to the MPFA-version of Fick's law, all porousmediumflow and freeflow test have to be rebuild.
Is there a way to circumvent this?
This goes in a similar direction as #583.
Do we really need to include the actual implementations in the flux headers? Couldn't we include them somewhere else?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/634Add chapter on physics of porous media flow in handbook2020-03-18T10:06:37ZBeatrix BeckerAdd chapter on physics of porous media flow in handbooke.g. pc-sw curvese.g. pc-sw curvesHolger ClassHolger Classhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/661Possibly include update of Box flux variables cache2020-07-29T08:46:49ZDennis 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.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/690[material][co2] create co2 tables with pressures less than 1 bar2021-07-20T09:14:51ZKatharina 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 le...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.3.5Johannes HommelJohannes Hommelhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/703Spatial parameters cannot be time dependent if not solution-dependent2021-08-15T09:38:11ZTimo Kochtimokoch@math.uio.noSpatial 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 tha...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.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/707Generic implementation of L2-norm calculation using generic L2-projection2021-03-09T12:17:45ZTimo Kochtimokoch@math.uio.noGeneric 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
Tha...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.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/726More tools for regression tests2020-04-30T13:03:55ZTimo Kochtimokoch@math.uio.noMore tools for regression tests<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
New ideas for regression tests. It should be possible to ignore changes at let's say a saturation front,...<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
New ideas for regression tests. It should be possible to ignore changes at let's say a saturation front, maybe by allowing a certain number of dofs to have a error higher tolerance. Another idea would be to map the solution of an adaptive grid to some reference grid and compare the solution there (we have some L2-projection capabilities now (only 2d for non-matching grids)).
**What does this feature / why does DuMux need it**:
It would make it possible to create more robust tests in cases where this is desired / physically-sensible.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/740Enforce constraints in fluid state or algorithm?2020-10-30T00:56:21ZBeatrix 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 c...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.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/754Automatic Differentiation2020-03-18T09:56:58ZNed ColtmanAutomatic Differentiation<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Automatic Differentiation (AD)
**What does this feature / why does DuMux need it**:
Often used in othe...<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Automatic Differentiation (AD)
**What does this feature / why does DuMux need it**:
Often used in other software packages, should be more accurate than numerical differentiation
**Which issue does this feature fix (if any)**
Removes numerical differentiation imprecision, more similar to a hand built jacobian.
**Anything else we need to know?**:
OPM has implemented this already, and their method seems compatible with Dumux. Dumux AD could likely be copied from OPM for the most part.
OPM does Forward AD, set up with operator overloading.
See MR (...)Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/759compositionalflash.hh: iterate saturation and pressure within flash2020-10-30T00:56:26ZBeatrix 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 t...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.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/761Cleanup explicit flash of implicit 2p2c model2021-03-09T12:21:50ZBeatrix 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...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.5Beatrix BeckerBeatrix Beckerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/763[FreeFlow] No Newton convergence for pressure Dirichlet BCs at high Re2021-03-25T08:39:24ZKilian 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 sh...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.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/792MultiDomain does not work for solution-dependent spatial params in instationa...2021-08-15T09:37:48ZDennis GläserMultiDomain does not work for solution-dependent spatial params in instationary problemsThis issue is related to #619, #703 and #788.
**What happened / Problem description**:
If a spatial param, e.g. porosity, depends on the solution of another domain (for example deformation-dependent porosities in poroelastic models), ...This issue is related to #619, #703 and #788.
**What happened / Problem description**:
If a spatial param, e.g. porosity, depends on the solution of another domain (for example deformation-dependent porosities in poroelastic models), there is currently no way to evaluate it on the correct time level during the creation of the previous volume variables. This causes the Newton solver to fail even for simple problems. A local (hacky) bugfix showed that good convergence is obtained when this is fixed.
This means that currently the Geomechanics module cannot be used for time-dependent problems in which deformation-dependent porosities are used, which is a standard capability.
A similar problem is reported in #703, where time-dependent spatial saturation distributions are needed.
Since several issues are related to this, an idea was to think about a more general way of handling time discretization schemes and hopefully fix all three issues at once.
One idea was to have a local view on the spatial parameters as well, and change all __bind__ functions such that they not only bind to an element but also to a time level somehow.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/795[tabulation] Generalize tabulation and interpolation2021-03-09T12:17:25ZBeatrix Becker[tabulation] Generalize tabulation and interpolationShould be possible to switch to splines, Should work for pc-sw tooShould be possible to switch to splines, Should work for pc-sw too3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/796[tabulation] adaptive linear tables2021-02-25T20:47:35ZBeatrix Becker[tabulation] adaptive linear tablesTabulation test shows that equally spaced tables have errors of more than 10% for some values at reasonable resolution.
This could be a Bachelor's thesis, maybe.Tabulation test shows that equally spaced tables have errors of more than 10% for some values at reasonable resolution.
This could be a Bachelor's thesis, maybe.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/807[RANS] Evaluate possibility to chose turbulence model at runtime2021-03-25T08:19:56ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[RANS] Evaluate possibility to chose turbulence model at runtimeCurrently, we have a myriad of different RANS models (zeroeq, oneeq, twoeq-kepsilon, twoeq-komega, twoeq-lowrekepsilon).
Maybe we could choose the turbulence model (at least for the two-eq models) at runtime.
This would decrease the nu...Currently, we have a myriad of different RANS models (zeroeq, oneeq, twoeq-kepsilon, twoeq-komega, twoeq-lowrekepsilon).
Maybe we could choose the turbulence model (at least for the two-eq models) at runtime.
This would decrease the number of executables for the tests and maybe also decrease the effort to add new turbulence models.3.5Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/812[parallel] Load balancing for UG with PTScotch2020-03-18T12:50:49ZTimo Kochtimokoch@math.uio.no[parallel] Load balancing for UG with PTScotchThere is a helper in Dune that shows how to load balance a UGGrid with ParMETIS at https://gitlab.dune-project.org/core/dune-grid/blob/master/dune/grid/utility/parmetisgridpartitioner.hh
Background is that the native load balancer in UG...There is a helper in Dune that shows how to load balance a UGGrid with ParMETIS at https://gitlab.dune-project.org/core/dune-grid/blob/master/dune/grid/utility/parmetisgridpartitioner.hh
Background is that the native load balancer in UGGrid seems to produce quite bad partitions. AluGrid's partitions are based on ZOLTAN/ParMETIS/Scotch and seem to be much better.
Since ParMETIS has a weird license (education-only), it would be be nice to have the same feature using (PT)Scotch which is (licensed under CeCILL - compatible with GNU GPL). Scotch offers similar capabilities and we already have a scotch backend for matrix reordering.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/814Extract "constraint solvers" from volume variables2021-03-09T12:17:04ZTimo Kochtimokoch@math.uio.noExtract "constraint solvers" from volume variablesThe computation of the secondary variables from the primary variables is currently often coded inside the volume variables' `update` function. For the purpose of potential code reusage, readability, and testability it is IMO better to mo...The computation of the secondary variables from the primary variables is currently often coded inside the volume variables' `update` function. For the purpose of potential code reusage, readability, and testability it is IMO better to move this functionality to constraint solver classes. Even if the computation is quite simple. This is sometimes done in the form of the `computeFluidState` function. However, there is no general interface for all models.
If the constraint solver is in a separate class it is much easier to write unit tests. Volume variables have a lot of dependencies but the constraint solver can easily be tested and mock object are simple to construct for values obtained from e.g. the spatial params or some physical law.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/816Do not use term "handle" in mpfa2021-03-25T08:59:26ZDennis GläserDo not use term "handle" in mpfaThe term `DataHandle` used in mpfa should be replaced as it actually stores the data.The term `DataHandle` used in mpfa should be replaced as it actually stores the data.3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/826Diffusion confusion (implementation)2021-03-25T08:37:24ZTimo Kochtimokoch@math.uio.noDiffusion confusion (implementation)We decided at some point that diffusion laws, e.g. `FicksLaw`, should compute all component fluxes in one go. This means two things
* we can now more efficiently compute the diffusive fluxes depending on the law (Fick / Maxwell-Stefan)
...We decided at some point that diffusion laws, e.g. `FicksLaw`, should compute all component fluxes in one go. This means two things
* we can now more efficiently compute the diffusive fluxes depending on the law (Fick / Maxwell-Stefan)
* `FicksLaw` now depends on the equation system
__Example:__
1. If I want to neglect diffusion in one phase, i can set the diffusion coefficient to zero. However, then the diffusive fluxes are still computed and I can throw them away in the custom local residual.
2. The Richards model is an immiscible two-phase two-component model but the air phase is never balanced. To integrate this in the current framework, we introduced `BalanceEqOpts::mainComponentIsBalanced(phaseIdx)` which is overloaded for the Richards model and used in Fick's law. In this case the dependency is actually there in the code in form of the additional dependency on `BalanceEqOpts`.
__One thought for a possible solution:__
If we would have a class `DiffusionFlux` replacing the current `FicksLaw`, then we could have a custom implementation `RichardsDiffusionFlux` which takes care of special requirements. `DiffusionFlux` would be a class on the level of `LocalResidual` only containing physics/equations. Internally it could use something like `FicksLaw` (new implementation that only contains the transmissibility part and discretization specifics) to compute the actual individual fluxes. `DiffusionFlux` may need to be specialized on the Law type (Fick / Maxwell-Stefan) but not the discretization.
Maybe, this would essentially be a code renaming / reordering. But that needs to be further investigated.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/832Reduce code duplication in nonequilibrium/volumevariables.hh2021-03-09T12:14:59ZTimo Kochtimokoch@math.uio.noReduce code duplication in nonequilibrium/volumevariables.hhhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/porousmediumflow/nonequilibrium/volumevariables.hh
For example, the dimensionless numbers could be put in a separate class.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/porousmediumflow/nonequilibrium/volumevariables.hh
For example, the dimensionless numbers could be put in a separate class.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/839[freeflow][test] Add analytical solution to non-isothermal test2021-03-25T08:20:25ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[freeflow][test] Add analytical solution to non-isothermal testThere are analytical solutions for some non-isothermal porous medium tests.
We could do the same for the free flow model.There are analytical solutions for some non-isothermal porous medium tests.
We could do the same for the free flow model.3.5Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/840Add concepts for PrimaryVariables and SwitchablePrimaryVariables2021-03-09T12:14:47ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deAdd concepts for PrimaryVariables and SwitchablePrimaryVariablesUsing concepts (!1902) would probably lead to a more concise syntax at many places dealing with PrimaryVariables.
PrimaryVariables:
* `[ ]` operator
* scalar-valued entries
SwitchablePrimaryVariables
* PrimaryVariables + `state()`Using concepts (!1902) would probably lead to a more concise syntax at many places dealing with PrimaryVariables.
PrimaryVariables:
* `[ ]` operator
* scalar-valued entries
SwitchablePrimaryVariables
* PrimaryVariables + `state()`https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/846[staggered] Memory requirements2020-04-29T08:41:16ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[staggered] Memory requirementsThe (free flow) staggered model requires huge amounts of memory for larger systems, especially in 3D
and when caching is enabled.
As an example, a 3D domain with 4332960 cells takes around 50GB RAM when caching is enabled.
Investigatin...The (free flow) staggered model requires huge amounts of memory for larger systems, especially in 3D
and when caching is enabled.
As an example, a 3D domain with 4332960 cells takes around 50GB RAM when caching is enabled.
Investigating a smaller 2D domain with valgrind massif revealed that 8% of the total memory consumption
is caused by the `StaggeredSubControlVolumeFace`. This kind of makes sense because we store a lot of
information, such a neighboring dof indices and distances within the scvf (needed to calculate velocity gradients, etc.)
We even store large parts of the same information twice (two scvfs per intersection).
Would it make sense to put all the information stored so far in the scvf into a staggered fvGeometry?
We could then store one fvGeometry per intersection and avoid duplication.
I could image something like
```c++
void fu(const FVGeometry& fvGeometry)
{
const auto& ccFVGeometry = fvGeometry.cellCenterFVGeometry(); // regular fvGeometry as for tpfa
const auto& faceFVGeometry = fvGeometry.faceFVGeometry(); // new fvGeometry, centered around element faces
for (const auto& scvf : scvfs(ccFVGeometry))
// do stuff with "normal" scvfs, defined on element faces
for (const auto& scvf: scvfs(faceFVGeometry))
// do stuff with scvf defined for staggered control volume
}
```
As still want element-wise assembly, the faceFVGeometry's scvfs would probably have to know
in which element they lie.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/850[staggered] Restructure staggered geometry, assembly, etc.2020-04-20T18:41:16ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[staggered] Restructure staggered geometry, assembly, etc.The current implementation of the staggered scheme is not very intuitive, at some parts even kind of "hacky".
Rather than considering dedicated geometries for the staggered control volumes,
we miss-use the `scvf`s in order to store all r...The current implementation of the staggered scheme is not very intuitive, at some parts even kind of "hacky".
Rather than considering dedicated geometries for the staggered control volumes,
we miss-use the `scvf`s in order to store all relevant geometrical quantities, as well es DOF indices, to
assemble the momentum balance equations defined on the staggered volumes.
We should discuss the introduction of a "real" staggered grid geometry which handles only the staggered control volumes
and behaves more natural, or in other words, more like the classes of the other discretization schemes.
The discussion already started in #846 and my feeling is that this will need some substantial changes to the code.
I therefore propose to form some sort of task force to discuss everything in detail.
We could use the issue to collect ideas and and potential issues.
__Current issues__
* Geometrical information and dof indices are stored twice, we should only store this once per intersection
* If caching is not enabled, gathering above mentioned information is very costly. This again calls for doing it only once.
* This may conflict with our element-wise assembly strategy, which we also use for the staggered variables so far.
* The scheme is currently limited to structured grids . Having the new, dedicated staggered geometry could make life easier for unstructured stuff
See !2012 for some first ideas.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/864Wrong residual norm in parallel2020-12-03T16:20:25ZBernd FlemischWrong residual norm in parallelFor calculating the norm of a `residual` in our `NewtonSolver`, we simply sum `residual.two_norm2()` over all processes and take the square root. In parallel, this is wrong or at least inconsistent with the norm that the linear solvers a...For calculating the norm of a `residual` in our `NewtonSolver`, we simply sum `residual.two_norm2()` over all processes and take the square root. In parallel, this is wrong or at least inconsistent with the norm that the linear solvers are using. For example, in a cell-centered method, the entries for the overlapping cells are also considered, while they are already accounted for on the corresponding interior cells. The linear solvers take the scalar product which knows about which entries have to be considered.Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/867Missing defaults for flux variable caching2020-06-01T11:02:15ZBernd FlemischMissing defaults for flux variable cachingIf a new model property is to be inherited from `ModelProperties` (instead of, e.g., `PorousMediumFlow`), one has to define the properties `FluxVariablesCache` and `FluxVariablesCacheFiller`. A default would be nice.If a new model property is to be inherited from `ModelProperties` (instead of, e.g., `PorousMediumFlow`), one has to define the properties `FluxVariablesCache` and `FluxVariablesCacheFiller`. A default would be nice.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/881some interfaces in FVLocalResidual receive problem as function argument2021-06-07T13:06:20ZDennis Gläsersome interfaces in FVLocalResidual receive problem as function argumentIn the base local residual for finite-volume schemes we have some interfaces that receive a problem instance and some that use the private variable `problem_` which is instantiated in the class constructor. For some functions, there exis...In the base local residual for finite-volume schemes we have some interfaces that receive a problem instance and some that use the private variable `problem_` which is instantiated in the class constructor. For some functions, there exist two overloads - one receiving problem and one using the private variable.
I find this a bit confusing at the moment. The functions are not static, so you need the local residual object - which was instantiated with a specific problem instance, i.e. we have the constructor
```cpp
//! the constructor
FVLocalResidual(const Problem* problem,
const TimeLoop* timeLoop = nullptr)
: problem_(problem)
, timeLoop_(timeLoop)
{}
```
What I find even more surprising is that `Problem` comes out of the property system, so I can potentially only call the interfaces receiving a problem with another instance of the same problem type.
So, I am wondering if the functions receiving a problem instance were designed to allow for evaluations for any problem, independent of how the class was instantiated? But then I'd assume the function the function to be static, or, to be free functions that temporarily instantiate a local residual using the provided problem and then calling these functions on that local variable without passing `problem`.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/883Translate shell scripts to Python2021-06-07T11:40:04ZTimo Kochtimokoch@math.uio.noTranslate shell scripts to PythonAs I recently work quite a lot on macOS I found the following problem:
Due to the many different shells it's quite hard to write portable shell scripts. Most of the command just don't work exactly the same.
__Suggestion__
using Python ...As I recently work quite a lot on macOS I found the following problem:
Due to the many different shells it's quite hard to write portable shell scripts. Most of the command just don't work exactly the same.
__Suggestion__
using Python (version 3) instead it should be much easier to get things portable and maybe more people also understand Python scripts.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/884Group arguments in assembly rountines2021-03-09T12:19:15ZTimo Kochtimokoch@math.uio.noGroup arguments in assembly rountinesI think fv element geometry, elem volvars and flux vars cache belong together in an element-wise assembly view point.
This could be expressed, e.g. by grouping these objects together. This might reduce the number of arguments for some fu...I think fv element geometry, elem volvars and flux vars cache belong together in an element-wise assembly view point.
This could be expressed, e.g. by grouping these objects together. This might reduce the number of arguments for some functions.
It's not completely trivial since there are several sensible combination possible.
I added a suggestion for an element view in !2125.
Suggestions for improvement? What that speaks for/against this?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/885[reproducible research] Collect meta data2021-09-29T08:55:26ZTimo Kochtimokoch@math.uio.no[reproducible research] Collect meta dataTo reproduce results it is important to collect meta data. This includes simple stuff like date&time of the run, but also runtime parameters e.g. output of the logging parameter tree, runtime data like number of Newton iterations, and co...To reproduce results it is important to collect meta data. This includes simple stuff like date&time of the run, but also runtime parameters e.g. output of the logging parameter tree, runtime data like number of Newton iterations, and compile time specifications like discretisation. For extracting meta data from a simulation run, we have to find a suitable mechanism.
Ideally all such data can be collected by one object and be formatted in a structured way, e.g. XML or JSON format (e.g. https://github.com/nlohmann/json). This output could then also be used to automatically generate meta data for other places, like DataVerse (e.g. using the ExtractIng project). Or just stored alongside simulations results elsewhere.
This is to collect ideas, MRs, issues related to how to design such a system within Dumux (in a way that the data can be easily collected by other tools but also be useful on it's own).
Some meta data could be also interesting for testing to compare against reference meta data.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/892[Box] Numeric differentiation not correct if volume variables depend on dofs ...2021-03-25T08:41:00ZTimo Kochtimokoch@math.uio.no[Box] Numeric differentiation not correct if volume variables depend on dofs other than the scv dof[Bug reported here](https://listserv.uni-stuttgart.de/pipermail/dumux/2020q2/002540.html) by Dmitry Pavlov on the mailing list.
When deflecting the solution to compute the numerical derivative of the element residual in the box method, ...[Bug reported here](https://listserv.uni-stuttgart.de/pipermail/dumux/2020q2/002540.html) by Dmitry Pavlov on the mailing list.
When deflecting the solution to compute the numerical derivative of the element residual in the box method, currently only the volume variables associated with the deflected dof are updated. However, since volume variables may depend on all dofs of the element, also the other volume variables on the element have to be updated.
This leads to an inexact Jacobian. Fixing the issue may lead to a significant overhead for most models as volume variable updates are typically the most expensive step in the local residual calculation.3.5Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/895Freeflow neumann function arguments2021-03-25T08:36:39ZMartin SchneiderFreeflow neumann function argumentsIs there any reason why the freeflow problems do not pass the ElementFluxVariablesCache to the Neumann function?
Most of the functions implemented in the FluxVariables do require such a FluxVariablesCache.Is there any reason why the freeflow problems do not pass the ElementFluxVariablesCache to the Neumann function?
Most of the functions implemented in the FluxVariables do require such a FluxVariablesCache.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/898[md] Constructor of MultiDomainFVAssembler only accepts rvalue argument tuples2020-06-09T13:30:20ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[md] Constructor of MultiDomainFVAssembler only accepts rvalue argument tuples```cpp
MultiDomainFVAssembler(ProblemTuple&& problem,
GridGeometryTuple&& gridGeometry,
GridVariablesTuple&& gridVariables,
std::shared_ptr<CouplingMana...```cpp
MultiDomainFVAssembler(ProblemTuple&& problem,
GridGeometryTuple&& gridGeometry,
GridVariablesTuple&& gridVariables,
std::shared_ptr<CouplingManager> couplingManager)
```
The constructor of MultiDomainFVAssembler only accepts rvalue tuples for `gridGeometry` and `gridVariables`.
What is the rationale behind this? Can we change it to
```cpp
template<class GGT, class GVT>
MultiDomainFVAssembler(ProblemTuple&& problem,
GGT&& gridGeometry,
GVT&& gridVariables,
std::shared_ptr<CouplingManager> couplingManager)
{
static_assert(std::is_same_v<std::decay_t<decltype(GGT)>, GridGeometryTuple>);
static_assert(std::is_same_v<std::decay_t<decltype(GVT)>, GridVariablesTuple>);
}
```
I am asking because I need to pass the same tuples also to `couplingmanager` so I could reuse the tuple here.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/908[disc] Implementation of nonlinear fv schemes2021-03-25T08:35:41ZMartin Schneider[disc] Implementation of nonlinear fv schemes3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/911Check intersection tests for completeness2021-04-12T13:16:06ZTim JupeCheck intersection tests for completenessThere are intersection tests for different geometries in different dimensions. Check existing intersection tests for completeness.There are intersection tests for different geometries in different dimensions. Check existing intersection tests for completeness.Tim JupeTim Jupehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/923Revise use of mappers2021-03-09T12:18:37ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deRevise use of mappers!2218 allows to use `SingleCodimSingleGeomTypeMapper` instead of our default `MultipleCodimMultipleGeomTypeMapper`, which can be a bit faster.
Using SingleCodimSingleGeomTypeMapper as ElementMapper works fine.
However, the code does no...!2218 allows to use `SingleCodimSingleGeomTypeMapper` instead of our default `MultipleCodimMultipleGeomTypeMapper`, which can be a bit faster.
Using SingleCodimSingleGeomTypeMapper as ElementMapper works fine.
However, the code does not compile when `gridGeometry.vertexMapper()` is passed in the context of `gridView.communicate(...)` or `VectorP0VTKFunction`.
I think in these cases, one is actually forced to use the MCMGMapper because the algorithm iterates over the entities of all codims during runtime.
We should check all of these occurrences. Maybe we should always provide a MultipleCodimMultipleGeomTypeMapper object
for vertices in our BaseGridGeometry which can be used for these special cases.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/926Discussion: Boundary condition types in new staggered implementation2020-09-03T13:23:21ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deDiscussion: Boundary condition types in new staggered implementationWhile re-implementing the staggered grid scheme, I thought it might be good to discuss which types of BCs we
want to offer. So far, I could implement most of the tests using only `dirichlet` and `neumann` BCs and some helper classes.
We...While re-implementing the staggered grid scheme, I thought it might be good to discuss which types of BCs we
want to offer. So far, I could implement most of the tests using only `dirichlet` and `neumann` BCs and some helper classes.
We could have additionally (as in the old implementation)
* symmetry (technically a combination of Dirichlet with v*n = 0 and zero shear stress)
* beaversJoseph (technically a solution dependent Dirichlet for the tangential velocity)
Symmetry can already be easily achieved by combining `dirichlet` and `neumann`.
This is not so easy for beaversJoseph because we do not support solution dependent Dirichlet BCs.
The old implementation circumvents that by not calling `dirichlet` but `beaversJoseph` with sol-dep arguments in the local residual.
It could be possible to implement beaversJoseph in terms of a Neumann BC, but that might become cumbersome, especially if
inertia terms are considered.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/933Discussion: Unify LocalAssemblers and SubDomainCouplingAssemblers2021-05-08T12:35:57ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deDiscussion: Unify LocalAssemblers and SubDomainCouplingAssemblersFrom a brief glance at `BoxLocalAssembler` and `SubDomainBoxLocalAssembler` it seems that there is a large degree of code duplication. I think it should be possible to make `SubDomainBoxLocalAssembler` inherit from `BoxLocalAssembler`.
...From a brief glance at `BoxLocalAssembler` and `SubDomainBoxLocalAssembler` it seems that there is a large degree of code duplication. I think it should be possible to make `SubDomainBoxLocalAssembler` inherit from `BoxLocalAssembler`.
The only critical parts are some calls to `couplingManager`. This could be replaced by some lambda calls which do nothing for the non-coupling assembler. The coupled assembler could then call the base class' function with a specialized lambda which .
, e.g., update the coupled variables.
We could evaluate the possibility of streamlining our code on the next Dumux day.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/940Clean incoporation of new time integration methods2021-03-25T09:23:04ZDennis GläserClean incoporation of new time integration methods@timok, @bernd, @kweis, @martins and I are currently discussing/developing the incorporation of a generic time integration framework in Dumux. In general, time handling is currently problematic in Dumux and leads to a bug in MultiDomain ...@timok, @bernd, @kweis, @martins and I are currently discussing/developing the incorporation of a generic time integration framework in Dumux. In general, time handling is currently problematic in Dumux and leads to a bug in MultiDomain (#792, #619).
The following work plan is currently envisioned to incorporate the features into an `Experimental` namespace while guaranteeing that the current features and tests on master still work:
1. [x] introduce new grid variables concept, where they represent the complete state of a simulation - thus, not only secondary but also primary variables and possibly a time level. (see !2285)
2. introduce new assembly concept <br>
- [x] make `NewtonSolver`, `PDESolver` accept both assemblers that assemble around given `SolutionVectors` or more generic `Variables` (see !2291) <br>
- [x] add time step methods (see !2296)<br>
- [ ] add generic version of `FVAssembler`, which assembles around `Variables` and uses the time integration methods (see !2519)<br>
- [ ] Introduce solution state (name is to be discussed) class that substitutes elementSolution during the assembly - that is, as argument to volume variables updates and in spatial parameters interfaces. The concept of this state class is to carry time information in addition to the element solution, that can be used within user interfaces. (!2520)
- [ ] Introduce context class, that wraps the local views after bind in order to pass that into the user interfaces. That reduces the number of arguments in a bunch of interfaces, and moreover, we usually have interfaces like `function(element, fvGeometry, elemVolVars,...)`, but `fvGeometry` makes little sense if not bound to `element` anyway and it also carries the bound element. With the same argument `elemVolVars` are basically unusable if you don't have the `scvs` at hand to access the corresponding volume variables. So in all those interfaces it makes sense to group the arguments. This is also introduced together with the solution state in !2520
- [ ] Extend problem/parameter/volvars interfaces to make it possible to inject some container with additionally required data, which in `MultiDomain` could be used to pass the coupling data. This is probably a lot of work and requires some thought regarding compatibility.<br>
- [ ] port the above concepts to `MultiDomain` (first goal: make `test_el2p` work, fixing the main bug)
Edit 25.03: We may postpone the introduction of the additional container to hold the coupling context for now and first realize multidomain in the new experimental framework but still with the context stored centrally in `CouplingManager` (an outdated but working draft is in !2448). This way, we can still reuse most interfaces in non-experimental namespace. Afterwards, we could address the issue of the central context separately, which would probably involve quite some interface changes... With either approach, the bug of non-converging Newton solver for poromechanics is addressed. Getting the context out of `CouplingManager` would additionally address thread safety in thread-parallel runs.
Problems that might need to be solved:
- The `assemble()` functions in the assembler now receive non-const GridVariables (introduced in 3d7068043ddb1cc7249aa0cd7d95ffa077733524). That was necessary because in the case of global caching we actually deflect the variables that come in. We should maybe think of a concept to circumvent this, and adapt !2519 accordingly.
Intermediate solutions/developments or related stuff, which should be deleted in case we favour the propositions above:
!2297, !2448, !2476, !2498, !2134, !2281, `feature/timestepmethods (now deleted)`
Things that should be revisited and adapted once this is ready:
!2130Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/943[tests][co2] co2 tests material parameters2021-03-25T08:40:27ZKatharina Heck[tests][co2] co2 tests material parametersI noticed that currently the materialparameters in the co2 tests are set to:
// Same material parameters for every layer
materialParams_.setSwr(0.2);
materialParams_.setSwr(0.05);
I guess this is a mistake and one of the...I noticed that currently the materialparameters in the co2 tests are set to:
// Same material parameters for every layer
materialParams_.setSwr(0.2);
materialParams_.setSwr(0.05);
I guess this is a mistake and one of these should be Snr. In order for the tests to pass in !1607 I set the parameters to this:
Swr = 0.05
Snr = 0.0
The question is if the parameters are in any way meaningful and a physical intention was behind them? If yes, we would need to change the reference solution.
@holle Do you think it is necessary to change them? If not I will close this issue again3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/951[freeflow] Introduce full shear stress terms, or document assumptions properly2021-03-25T08:38:24ZNed Coltman[freeflow] Introduce full shear stress terms, or document assumptions properlyWe ran into a few discussions this summer/fall regarding terms that we may have either not implemented in the navier-stokes environment, or terms that we have neglected, but have not documented the assumptions properly.
These should be...We ran into a few discussions this summer/fall regarding terms that we may have either not implemented in the navier-stokes environment, or terms that we have neglected, but have not documented the assumptions properly.
These should be included, in either both new and old staggereds, or only the new staggered.
These terms include:
- the dilataion term
```math
\tau = \mu (\nabla v + \nabla v^T) + ( \lambda \nabla v ) I
```
- with stokes hypothesis
```math
(\lambda = 2/3 \mu)
```
- the second term of the linear eddy viscosity reynolds stress: [cfdOnline](https://www.cfd-online.com/Wiki/Linear_eddy_viscosity_models)
```math
\tau_t = 2 \mu_t S - 2/3 \rho k \delta_{ij}
```
- any others?
From what I've seen, some of this is already underway. This issue is only a location to collect problems and track progress.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/959[getparamlist.py] Keep old parameter descriptions2021-07-28T09:00:55ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[getparamlist.py] Keep old parameter descriptionsWe should modify the script such that it extracts the parameter descriptions given in `parameterlist.txt`
and automatically uses them for the overwritten file.We should modify the script such that it extracts the parameter descriptions given in `parameterlist.txt`
and automatically uses them for the overwritten file.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/966[ci] Test installation scripts in CI2021-09-29T08:55:26ZTimo Kochtimokoch@math.uio.no[ci] Test installation scripts in CIWe could add a Docker container for testing the new installation script and maybe the install external in the CI.We could add a Docker container for testing the new installation script and maybe the install external in the CI.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/970Check brine fluidsystem2021-07-28T09:00:55ZTheresa SchollenbergerCheck brine fluidsystemThe binary diffusion coefficient of NaCl seems to be wrong. Also there is no source available for the implemented one. Because of that the implemented parameters should be checked and sources sould be added.
Further there are relations e...The binary diffusion coefficient of NaCl seems to be wrong. Also there is no source available for the implemented one. Because of that the implemented parameters should be checked and sources sould be added.
Further there are relations e.g. for density where the source is not mentioned in the comments. Also there are some todos left to do which could be essential.
- [x] correct diffusion coefficient
- [ ] check parameters and add sources
- [ ] improve comments and add sources for relationships
- [ ] todo check contribution of NaCl on thermal conductivity
- [ ] todo find better description for calculation of the isobaric heat capacity
- [x] check solid heat capacity of NaCl which is given in J/mol K3.5Theresa SchollenbergerTheresa Schollenbergerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/974Properties generator2021-07-28T18:29:28ZTimo Kochtimokoch@math.uio.noProperties generatorLooking some of the extracted properties, they mostly look very similar but it's a lot of tedious Boilerplate code to write.
One common mistake I often do it that I copy a property definition from another file but forget to adjust the ...Looking some of the extracted properties, they mostly look very similar but it's a lot of tedious Boilerplate code to write.
One common mistake I often do it that I copy a property definition from another file but forget to adjust the typetag I specialize for.
We could use try a code generation approach instead. Maybe properties could be written in YAML for example and then the property header can be generated from that with Python. Something like
```yml
name: properties.hh
tags:
- TestIncompressibleOneP:
- inherits_from: [BoxModel, CCTpfa]
includes:
- dune/grid/yaspgrid.hh
TestIncompressibleOneP:
properties:
- Grid: 'Dune::YaspGrid<3>'
```
Not sure if it gets too complicated. We could give it a try. I don't know if property traits can be cleanly implemented as a yml structure.
Using other properties could be something like
```yml
...
TracerTest:
properties:
- SpatialParams: 'TracerTestSpatialParams<{GridGeometry}, {Scalar}>'
```
which expands to
```c++
template<class TypeTag>
struct SpatialParams<TypeTag, TTag::TracerTest>
{
private:
using GridGeometry = GetPropType<TypeTag, Properties::GridGeometry>;
using Scalar = GetPropType<TypeTag, Properties::Scalar>;
public:
using type = TracerTestSpatialParams<GridGeometry, Scalar>;
};
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/976Discussion: naming of boundary condition functions / conditions2021-03-10T19:30:25ZTimo Kochtimokoch@math.uio.noDiscussion: naming of boundary condition functions / conditionsProblem currently need to implement `dirichlet` and `neumann` functions and we have the corresponding boundary conditions `dirichlet` and `neumann`. However we use `neumann` much more general than in there original meaning I believe. For...Problem currently need to implement `dirichlet` and `neumann` functions and we have the corresponding boundary conditions `dirichlet` and `neumann`. However we use `neumann` much more general than in there original meaning I believe. For example Robin/Cauchy boundary conditions can be realized in the `neumann` function.
Essentially `neumann` corresponds to the integrand of all boundary integrals in the equations. It's always a weakly enforced boundary condition. `dirichlet` corresponds to setting a fixed value and is strongly or weakly enforced depending on the discretization scheme.
Alternative naming schemes could be
* `boundaryFluxes` (for `neumann`) and BC type `flux`
* `boundaryValues` (for `dirichlet`) and BC type `value`/`fixed`
or only changing `neumann`
* `boundaryFluxes` (for `neumann`) and BC type `flux`
* `dirichlet` and BC type `dirichlet`
Other ideas and opinions?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/979Newton has too many dependencies2020-12-22T10:14:07ZTimo Kochtimokoch@math.uio.noNewton has too many dependenciesThe Newton solver has quite some requirements on the Assembler and LinearSolver types which makes it harder (though not impossible) to use in a generic setting. These dependencies are documented in `test/nonlinear/newton/test_newton.cc` ...The Newton solver has quite some requirements on the Assembler and LinearSolver types which makes it harder (though not impossible) to use in a generic setting. These dependencies are documented in `test/nonlinear/newton/test_newton.cc` where the minimal current interface requirements are implemented in Mock classes and a scalar nonlinear equation is solved.
This issue is here to remind us that these dependencies should be reduced to a minimum to decrease coupling in the code.
Ideas/issues towards this also involve #940 !2113 #978https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/988[Forchheimer] Does this work for multi-phase flow?2021-07-20T09:14:16ZDennis Gläser[Forchheimer] Does this work for multi-phase flow?In !2414, @martins and I discussed if Forchheimer (or our implementation of it) works for multi-phase settings. It is permitted in the code and, but some variables have names that suggest one-phase flow regimes. Moreover, there is this c...In !2414, @martins and I discussed if Forchheimer (or our implementation of it) works for multi-phase settings. It is permitted in the code and, but some variables have names that suggest one-phase flow regimes. Moreover, there is this comment:
```cpp
// This is important in the case of a one-phase region in two-phase flow. The non-existing
// phase has a velocity of zero (kr=0).
```
see line 472 in https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/59ee4e5e26d6646dcf7670df8b4f7193a6fe3fda/dumux/flux/cctpfa/forchheimerslaw.hhRoman WinterRoman Winterhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/990Broken parallel helpers (again)2021-04-09T07:38:34ZTimo Kochtimokoch@math.uio.noBroken parallel helpers (again)The current implementation does not work for grids that cannot communicate since the functions are actually called regardless of whether the grid can communicate or not trusting that the function will handle it.
There at least two ways ...The current implementation does not work for grids that cannot communicate since the functions are actually called regardless of whether the grid can communicate or not trusting that the function will handle it.
There at least two ways to solve this. Example `makeNonOverlappingConsistent`:
* check if num processors is more than 1 otherwise return, if grid cannot communicate but num processors is greater 1 throw
* do none of the checks inside the function but outside
I'm tending to the latter because otherwise `makeNonOverlappingConsistent` is doing more than one thing (SRP).
If you call the function and read the name you expect it to do something. So you should just call it if your grid can communicate and if the number of processors is more than 1. But it also means more code at the call site but also more transparent.
@DennisGlaeser @bernd3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/991Dumux handbook contains dumux-version hard coded, which is easily not updated2021-02-12T12:12:27ZDavid WernerDumux handbook contains dumux-version hard coded, which is easily not updatedThis might be ok, if it the right version. The master contains 0_dumux-handbook.tex
on master has currently ``\newcommand{\DumuxVersion}{3.3}`` . Also not so nice for docs on the webpage.This might be ok, if it the right version. The master contains 0_dumux-handbook.tex
on master has currently ``\newcommand{\DumuxVersion}{3.3}`` . Also not so nice for docs on the webpage.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/996[pnm] BoundaryFlux class only works for Dirichlet Boundaries2021-10-11T11:05:43ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[pnm] BoundaryFlux class only works for Dirichlet BoundariesThe [BoundaryFlux class](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/porenetwork/common/boundaryflux.hh) for evaluating fluxes entering or leaving the network only works if Dirichlet conditions are set o...The [BoundaryFlux class](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/porenetwork/common/boundaryflux.hh) for evaluating fluxes entering or leaving the network only works if Dirichlet conditions are set on the relevant boundaries.
This is because the class evaluates the local residual at the respective DOFs. For Dirichlet BCs, the value is not zero but equals the boundary flux.
One could maybe check if a Dirichlet BC is set and proceed as before and just evaluate the `source` term instead otherwise.
Note: `source` corresponds to a `neumann` BC at the boundary. The PNM does not support `neumann` but requires a `source` instead because there are no boundary `scvfs`.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/997Add non-Darcy flow upscaling example2021-05-17T09:10:42ZTimo Kochtimokoch@math.uio.noAdd non-Darcy flow upscaling exampleThe following discussion from !2420 should be addressed:
- [x] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2420#note_54324): (+2 comments)
> I would be awesome to have a...The following discussion from !2420 should be addressed:
- [x] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2420#note_54324): (+2 comments)
> I would be awesome to have a test that computes permeability in one direction for a network e.g. extracted from the Berea sandstone sample for different pressure gradients. Then we could do at least a qualitative comparison with Muljadi et al. https://doi.org/10.1016/j.advwatres.2015.05.019 (essentially reproduce one of the plots of El-Zehairy et al. https://doi.org/10.1016/j.advwatres.2019.103378)3.5Maziar VeyskaramiMaziar Veyskaramihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1000Properly include the volume work term in the energy balance2021-09-29T08:55:26ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deProperly include the volume work term in the energy balanceWe currently implement
$`\frac{\partial}{\partial t}(\rho u) = - \nabla \cdot (\rho \mathbf{v}h) + \nabla \cdot (\lambda \nabla T)`$
with $`h = u + \frac{p}{\rho}`$
However, the correct form of the energy balance equation is (see !2...We currently implement
$`\frac{\partial}{\partial t}(\rho u) = - \nabla \cdot (\rho \mathbf{v}h) + \nabla \cdot (\lambda \nabla T)`$
with $`h = u + \frac{p}{\rho}`$
However, the correct form of the energy balance equation is (see !2473, !2471)
$`\frac{\partial}{\partial t}(\rho u) = - \nabla \cdot (\rho \mathbf{v}u) -p \nabla \cdot \mathbf{v} + \nabla \cdot (\lambda \nabla T)`$
Replacing enthalpy with internal energy in the first divergence term is simple but
the discretization of
$`p \nabla \cdot \mathbf{v}`$
is not straight-forward.
A possible simple solution would be:
Include in calculation of flux terms, i.e., evaluate $`\nabla \cdot \mathbf{v}`$
and assume a cell-constant $`p`$ which is just multiplied to the term. This gives a first-order scheme but should be ok since the term is often small. For incompressible flow the term also vanishes discretely since $`\nabla \cdot \mathbf{v} = 0`$.
This seems to work for cell-centered schemes without much additional effort (!2494).
For the box method it seems more difficult since the code assumes that fluxes on scvfs are symmetric. However the energy contribution (assembled on the scvfs) is different depending on the control volume (different control volume pressure).https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1001extrusionFactor should be a spatial parameter interface2021-09-29T10:40:13ZTimo Kochtimokoch@math.uio.noextrusionFactor should be a spatial parameter interfaceDeprecate `extrusionFactor`/`extrusionFactorAtPos` in problem and add spatial parameter interface instead.Deprecate `extrusionFactor`/`extrusionFactorAtPos` in problem and add spatial parameter interface instead.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1013SimpleH20 does not consider enthalpy of vaporization2021-10-01T12:36:42ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deSimpleH20 does not consider enthalpy of vaporizationI suggest to add $`h_\mathrm{vap}`$ here:
```c++
static const Scalar gasEnthalpy(Scalar temperature,
Scalar pressure)
{
static const Scalar tRef = getParam<Scalar>("SimpleH2O.Reference...I suggest to add $`h_\mathrm{vap}`$ here:
```c++
static const Scalar gasEnthalpy(Scalar temperature,
Scalar pressure)
{
static const Scalar tRef = getParam<Scalar>("SimpleH2O.ReferenceTemperature", 293.15);
return gasHeatCapacity(temperature, pressure)*(temperature - tRef) + 2453.5e3;
}
```
We could even make $`h_\mathrm{vap}`$ depending on $`T_\mathrm{ref}`$ as there as simple equations for that.
http://www.personal.psu.edu/users/m/r/mrh318/physical-consts/Popiel-Wojtkawiak-HTE-1998.pdf
https://www.scirp.org/pdf/AS20120200008_25514260.pdf (Bananas!)
It would still be a constant.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1015Add enthalpy of vaporization to constant component2021-08-25T14:52:45ZTimo Kochtimokoch@math.uio.noAdd enthalpy of vaporization to constant componentRelated to #1013 !2563
We could just add a function vaporizationEnthalpy that is also read from the input file.
This also allows to estimate the vapor pressure: https://en.wikipedia.org/wiki/Clausius%E2%80%93Clapeyron_relation#Applica...Related to #1013 !2563
We could just add a function vaporizationEnthalpy that is also read from the input file.
This also allows to estimate the vapor pressure: https://en.wikipedia.org/wiki/Clausius%E2%80%93Clapeyron_relation#Applications (if e.g. triplePointPressure/Temperature is supplied)3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1041[ci] Test cornerpoint grid + OPM2021-07-23T10:42:18ZTimo Kochtimokoch@math.uio.no[ci] Test cornerpoint grid + OPMMaybe just on the release branch. Needs a different Docker image?
Many people seem to have difficulties getting OPM to run (e.g. #1036), so a Dockerfile might help to at least show the minimal steps required to set it up on a new system...Maybe just on the release branch. Needs a different Docker image?
Many people seem to have difficulties getting OPM to run (e.g. #1036), so a Dockerfile might help to at least show the minimal steps required to set it up on a new system. I also have the feeling from the mailing list posts that cornerpoint grids quite a popular feature for external users.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1046Replace tabulated2dfunction2021-06-28T11:56:48ZTimo Kochtimokoch@math.uio.noReplace tabulated2dfunctionMight be worth replacing this class ([common/tabulated2dfunction.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/common/tabulated2dfunction.hh)) by a specialization of `math.hh:interpolate` for `Bilinear...Might be worth replacing this class ([common/tabulated2dfunction.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/common/tabulated2dfunction.hh)) by a specialization of `math.hh:interpolate` for `BilinearTable` (Scalar = randomaccess container size 2). And some function that computes the sampling points.
Follow-up from !2692https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1054Discretization method as tag instead of enum2021-09-29T16:58:37ZTimo Kochtimokoch@math.uio.noDiscretization method as tag instead of enumTags (see https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/common/tag.hh) have some advantages over enums and, as far as I know, no disadvantages (edit: one disadvantage is that interfaces receiving a method ...Tags (see https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/common/tag.hh) have some advantages over enums and, as far as I know, no disadvantages (edit: one disadvantage is that interfaces receiving a method as an argument need to be templated while this is not necessary for the enum implementation). The most prominent advantage being that a new tag can be added in user code without modifying the `discretization/method.hh` header which is currently required. This makes is difficult/impossible to add a new discretization in a separate module.
Tags have been introduced for the `CouplingMode` in [couplingmanager1d3d.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/multidomain/embedded/couplingmanager1d3d.hh) which previously was an enum and enabled implemented new modes in downstream modules. There was also a deprecation period possible which should be possible for the discretization method as well.
!2795
!28443.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1057Document Python generator classes2021-07-23T08:37:29ZTimo Kochtimokoch@math.uio.noDocument Python generator classesFollow-up from "Feature/python main file"
The following discussion from !2681 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2681#note_62023):
> ...Follow-up from "Feature/python main file"
The following discussion from !2681 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2681#note_62023):
> we have to document these generators very well because it's the interface used from the Python side. But I think that's a separate task for when the bindings are a bit more stable...3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1059Use dynamic polymorphism in mpfa interaction volumes2021-07-23T06:42:38ZDennis GläserUse dynamic polymorphism in mpfa interaction volumesThe mpfa code is super difficult to understand. One thing that makes it additionally complicated is the fact that it allows for two different interaction volume types to be used - because some mpfa methods (like mpfa-l) cannot handle bou...The mpfa code is super difficult to understand. One thing that makes it additionally complicated is the fact that it allows for two different interaction volume types to be used - because some mpfa methods (like mpfa-l) cannot handle boundary conditions properly. So one approach is to use the o-method at boundaries.
To make it possible to implement such thing, one can define to use different interaction volumes around tagged vertices (default: boundary). But this introduces a bunch of if/else branches that clutter the code.
We could probably get rid of this by using dynamic polymorphism on interaction volumes. The computations to construct an interaction volume and to compute transmissibilities are typically expensive, so I guess the runtime penalty should not matter. We should give this a try to make the mpfa code (at least a tiny bit) less frustrating to read.3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1062DuMux Day 28.07.20212021-08-25T08:56:27ZHanchuan WuDuMux Day 28.07.2021- [x] Test the extract module script @yue @hanchuan
- [x] Fix Python CI @timok #1061
- [x] Simplify localView with bind(element) @nedc #1060 !2736
- [x] First to modify the GridGeometry update interface @martins #1056
- [ ] Discretiza...- [x] Test the extract module script @yue @hanchuan
- [x] Fix Python CI @timok #1061
- [x] Simplify localView with bind(element) @nedc #1060 !2736
- [x] First to modify the GridGeometry update interface @martins #1056
- [ ] Discretization method as tag instead of enum @IvBu #1054
- [ ] Consider enthalpy of vaporization for constant component (e.g. SimpleH2O) @heck #1013 #1015
- [ ] extrusionFactor should be a spatial parameter interface @felixw #1001
- [ ] #1000 @bernd
- [ ] !2565 @Maziar
- [ ] #970 @tschol
- [ ] #959 @RoWin, @yue3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1064Extract module script CMake macros not considered2021-07-28T12:31:27ZTimo Kochtimokoch@math.uio.noExtract module script CMake macros not consideredThe extract module script does not consider cmake macros. So if you extract from a module that defines some cmake macros/functions and then use them, the extracted module will not find these functions because it shouldn't depend on its p...The extract module script does not consider cmake macros. So if you extract from a module that defines some cmake macros/functions and then use them, the extracted module will not find these functions because it shouldn't depend on its parent module anymore.
Maybe we can simply copy the cmake/modules folder (might need some renaming) of the module extracted from.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1065Raise dependency to dune >= 2.82021-08-23T11:29:58ZTimo Kochtimokoch@math.uio.noRaise dependency to dune >= 2.8For release 3.5 I suggest to raise the Dune requirement to 2.8 (which will be released shortly). I suggest this now simply to decrease a bit of maintenance cost. For example we can drop testing against dune 2.7 for the master branch. Som...For release 3.5 I suggest to raise the Dune requirement to 2.8 (which will be released shortly). I suggest this now simply to decrease a bit of maintenance cost. For example we can drop testing against dune 2.7 for the master branch. Some version checks can be removed.
* __Agree?__ Click thumbs up :thumbsup:
* __Disagree?__ Write comment below3.5Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1066Documentation for python bindings2021-08-03T07:35:06ZTimo Kochtimokoch@math.uio.noDocumentation for python bindingsPython bindings are still experimental but we should think about how to generate docs for Python. Maybe have a look and follow what Dune does too. Sphinx is a popular tool for automated doc generation for Python.
For automated docs we a...Python bindings are still experimental but we should think about how to generate docs for Python. Maybe have a look and follow what Dune does too. Sphinx is a popular tool for automated doc generation for Python.
For automated docs we also need to decide on a docstring format (e.g. the google format understood by Sphinx)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1068Change construction and update of MultiDomainFVGridGeometry2021-08-15T17:19:20ZMartin SchneiderChange construction and update of MultiDomainFVGridGeometryIn MR !2737 the construction of grid geometries is such that no further call of `update` is needed after construction. For some gg this requires to pass additional objects to the constructor. Therefore, the MultiDomainFVGridGeometry has ...In MR !2737 the construction of grid geometries is such that no further call of `update` is needed after construction. For some gg this requires to pass additional objects to the constructor. Therefore, the MultiDomainFVGridGeometry has to be changed such that the grid geometries of the sub-problems are set and not constructed within this class.3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1071Tracer is not conserved2021-08-15T09:40:08ZBernd FlemischTracer is not conserved**Problem description:**
In a multi-phase setting, the amount of a tracer in one fluid phase is possibly not conserved from one time step to the next.
**Explanation:**
When solving the flow problem, the phase distribution usually chang...**Problem description:**
In a multi-phase setting, the amount of a tracer in one fluid phase is possibly not conserved from one time step to the next.
**Explanation:**
When solving the flow problem, the phase distribution usually changes. For example, the saturation in one cell increases. Since flow and tracer problems are decoupled, one should assume in this flow step that the added fluid doesn't contain tracer. For conserving the amount of tracer in each cell, the tracer concentration should be adapted to this change. While the concentration should be reduced in case of an increasing saturation, it stays the same and therefore the amount of tracer in the cell is increased. This is not corrected by the tracer solution step, as that step just redistributes the tracer according to the volume flux and the given (possibly wrong) concentration.
**How to reproduce it:**
Check out the branch `fix/tracer-concentration` and consider [test/porousmediumflow/tracer/conservation](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/fix/tracer-conservation/test/porousmediumflow/tracer/conservation). Comment the line
```cpp
equilibrateTracer(xOld, oldSaturation_, saturation_);
```
of `main.cc`.
**Possible fix:**
Equilibrate the tracer after each flow solve and before each tracer solve. To be discussed in !2767.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1073Dumux Day 25.08.20212021-09-29T08:16:10ZDennis GläserDumux Day 25.08.2021- [x] make progress on #885 (@martins)
- [x] #1047 (@DennisGlaeser)
- [x] !2792,!2793 (@melaniel)
- [x] !2708 (@timok)
- [ ] !2734 (@nedc)
- [ ] see #1062: @heck, @yue, @IvBu
- [x] all: test !2769 and report if test fails- [x] make progress on #885 (@martins)
- [x] #1047 (@DennisGlaeser)
- [x] !2792,!2793 (@melaniel)
- [x] !2708 (@timok)
- [ ] !2734 (@nedc)
- [ ] see #1062: @heck, @yue, @IvBu
- [x] all: test !2769 and report if test fails3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1074Spatialparams folder2021-09-29T10:40:13ZTimo Kochtimokoch@math.uio.noSpatialparams folderThe spatial parameter classes are located under material/spatialparams. I think this historically may have made sense when only porous media were considered. However, the spatial parameters are more general that. With parameters like `gr...The spatial parameter classes are located under material/spatialparams. I think this historically may have made sense when only porous media were considered. However, the spatial parameters are more general that. With parameters like `gravity` and `extrusionFactor` (see #1001) that are not necessarily connected to some material, we interpret the spatial parameters really just as (potentially) spatially varying parameter fields.
What would be a better place? `common/spatialparams`? Or just move the headers to the respective subfolders, i.e. porousmediumflow spatial params to `porousmediumflow` and porenetwork spatial params to `porenetwork` and so on?3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1075BaseGridGeometry Traits2021-08-25T16:33:42ZMartin SchneiderBaseGridGeometry TraitsIs there any reason why the type of the `Traits` class given as template argument to the `BaseGridGeometry` is not publicly available within this class? This would for example simplify checking if a class inherits from `BaseGridGeometry`...Is there any reason why the type of the `Traits` class given as template argument to the `BaseGridGeometry` is not publicly available within this class? This would for example simplify checking if a class inherits from `BaseGridGeometry`, without the need of any parameter pack.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1080Investigate alternatives for weak_ptr in coupling manager2021-10-08T12:22:43ZTimo Kochtimokoch@math.uio.noInvestigate alternatives for weak_ptr in coupling managerThe following discussion from !2823 should be addressed:
- [ ] @DennisGlaeser started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2823#note_66168): (+4 comments)
> is the call to `this...The following discussion from !2823 should be addressed:
- [ ] @DennisGlaeser started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2823#note_66168): (+4 comments)
> is the call to `this->problem()` expensive because of the `if` check I guess? But compared to the subsequent call to `bindCouplingContext` that `if` should be negligible, no? If that's the case, I would be in favor of removing the comment and the if/else block for clearer code.
>
> I'm not sure how expensive the call to `weakPtr.expired` is, but an `if` statement is generated here as well by checking if the context is empty..
In general the problem interface of the base coupling manager pops up in performance analysis so it's a non-negligible overhear involved with obtaining a reference to a sub-problem. We could switch to a raw pointer which has the only disadvantage that you get a segfault instead of a runtime error in case the you use the coupling manger _after_ the problem is destroyed. I the usual setup that should never occur. But it might occur in some future configurations...
Note that shared_ptr is not an option because that would lead to a cyclic dependency and a memory leak.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1081Port free flow tests to new staggered2021-09-29T13:11:52ZBernd FlemischPort free flow tests to new staggeredTests should be ported one by one in separate merge requests. In principle, the new implementations are available in !2201. Move changes from `problem_new.hh` and `main_new.hh` to `problem.hh`, `main.hh`and `properties.hh`. Be careful as...Tests should be ported one by one in separate merge requests. In principle, the new implementations are available in !2201. Move changes from `problem_new.hh` and `main_new.hh` to `problem.hh`, `main.hh`and `properties.hh`. Be careful as !2201 is already partly outdated. !2830 is a port based on the current master.
- [ ] `navierstokes/angeli`: @heck
- [ ] `navierstokes/channel/1d`: @RoWin
- [ ] `navierstokes/channel/pipe`: @hanchuan
- [ ] `navierstokes/closedsystem`: @nedc
- [ ] `navierstokes/kovaszny`: @yue3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1082DuMux Day 29.09.20212021-10-06T09:31:36ZBernd FlemischDuMux Day 29.09.2021- [ ] #1081: @heck, @RoWin, @hanchuan, @nedc, @yue
- [ ] #1054: @IvBu
- [ ] #1074, #1001: @DennisGlaeser starts, @nedc joins
- [ ] #1000: @bernd check how to include for new staggered
- [x] #1077, !2837 : @farid
- [ ] #885: @martins
-...- [ ] #1081: @heck, @RoWin, @hanchuan, @nedc, @yue
- [ ] #1054: @IvBu
- [ ] #1074, #1001: @DennisGlaeser starts, @nedc joins
- [ ] #1000: @bernd check how to include for new staggered
- [x] #1077, !2837 : @farid
- [ ] #885: @martins
- [ ] #996: @Maziar
- [x] Darcy-Stokes new staggered: @timok
- [ ] #966: @emmert
- [x] #983: @mathis
- [ ] dumux-lecture: @holle, @stefaniekiemlehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1084mpnc does not work with brineair fluidsystem2021-10-01T14:21:16ZTheresa Schollenbergermpnc does not work with brineair fluidsystemIf the brineair fluidsystem is used with the mpnc model you get a singular matrix immediately. The 2pncmin/nonisothermal test works using the brineair fluidsystem and the 2pncmin model.
On the branch fix/mpnc-with-brineair you can find t...If the brineair fluidsystem is used with the mpnc model you get a singular matrix immediately. The 2pncmin/nonisothermal test works using the brineair fluidsystem and the 2pncmin model.
On the branch fix/mpnc-with-brineair you can find this test now using the mpnc model. Here the mineralization part is removed. On the branch fix/mpncmin-with-brineair the test is using a mpncmin model. In both cases a singular matrix is obtained immediately.Theresa SchollenbergerTheresa Schollenbergerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1085Staggered problem dirichlet/neumann return convention2021-10-04T09:01:17ZTimo Kochtimokoch@math.uio.noStaggered problem dirichlet/neumann return conventionThe following discussion from !2852 should be addressed:
- [ ] @martins started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2852#note_66920): (+2 comments)
> I aggree and I also think ...The following discussion from !2852 should be addressed:
- [ ] @martins started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2852#note_66920): (+2 comments)
> I aggree and I also think that there should be some direct traits mechanics.
>
> However, this issue might also exist for user-defined functions. I think the discrepancy here is between how we actually think of `PrimaryVariables` and how it is used in the test cases. So maybe using for both situations the name `PrimaryVariables` might be confusing?
The staggered Navier-Stokes code expects full velocities fluxes (in all dimensions) from the problem. This makes it easier to set boundary conditions for when complex treatment due to the discretization is needed in the background.
The correct sizes are now statically asserted !2852. Still the problem uses the type names `PrimaryVariables` and `NumEqVector` but means different types than the corresponding types specified via properties and used in the assembly. This makes this error-prone and confusing. Moreover, it is currently necessary to overload all such functions inherited from the `FVProblem` because the type information is not properly propagated into the base class.
One solution would be to overload the functions in the navierstokes problem and actually use different type names such as `Velocity` and `MomentumFlux` so that it's completely clear that these are different.
TODO: how does this generalize to more complex models? Is it always only the momentum model affected by this? How to treat the difference with the mass model since both are currently implemented in one class with template switches.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1086Extractline data script does not work with pvpython 5.7.0, Kudo Paula2021-10-06T09:30:50ZHanchuan WuExtractline data script does not work with pvpython 5.7.0, Kudo Paula<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
The `extractlinedata.py` does not work with `Paraview` (`pvpython`) under version 5.7.0.
The following error me...<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
The `extractlinedata.py` does not work with `Paraview` (`pvpython`) under version 5.7.0.
The following error messages would be obtained:
```
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/paraview/servermanager.py", line 1312, in SetData
position = self.Available.index(values)
ValueError: 'Line' is not in list
```
**How to reproduce it (as minimally and precisely as possible)**:
Run `pvpython extractlinedata.py -f REVScale_BJS_darcy-00000.vtu -p1 0.0 0.0 0.0 -p2 0.0 0.5 0.0` for the attached file [REVScale_BJS_darcy-00001.vtu](/uploads/326e8bf4bac1444043e1a0df83e4d717/REVScale_BJS_darcy-00001.vtu). In principle, with `pvpython` version 5.7.0 use `extractline.py` in `bin` folder to extract a line data from any `vtu/vtp` file can reproduce the error.
**PS**:
The script works with Paraview 5.9.0 and some old versions.Hanchuan WuHanchuan Wu