dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues2020-01-22T08:34:48Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/801[Box] variable switch at boundary2020-01-22T08:34:48ZMartin Schneider[Box] variable switch at boundaryIt seems that there is a bug in the variable switch for box at the boundary.
In the `initPriVarSwitch_` method, the states of Dirichlet nodes are corrected.
This method is called in `newtonBegin`, which however is called after the initialization
of `uLastIter`.
Therefore, when calling the `newtonUpdate` method, the corrected states of `uCurrentIter`
are overwritten.
We could fix this by either calling `initPriVarSwitch_` before `uLastIter` is initialized
or by setting this vector after `newtonBeginStep`.
So we could simply change
```c++
if (numSteps_ > 0)
uLastIter = uCurrentIter;
```
to
```c++
if (numSteps_ >= 0)
uLastIter = uCurrentIter;
```It seems that there is a bug in the variable switch for box at the boundary.
In the `initPriVarSwitch_` method, the states of Dirichlet nodes are corrected.
This method is called in `newtonBegin`, which however is called after the initialization
of `uLastIter`.
Therefore, when calling the `newtonUpdate` method, the corrected states of `uCurrentIter`
are overwritten.
We could fix this by either calling `initPriVarSwitch_` before `uLastIter` is initialized
or by setting this vector after `newtonBeginStep`.
So we could simply change
```c++
if (numSteps_ > 0)
uLastIter = uCurrentIter;
```
to
```c++
if (numSteps_ >= 0)
uLastIter = uCurrentIter;
```3.2Timo Kochtimo.koch@iws.uni-stuttgart.deTimo Kochtimo.koch@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/800[shallowwater] upwind mobility for shallow water flux.2020-01-10T08:32:25ZLeopold Stadler[shallowwater] upwind mobility for shallow water flux.<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Upwind mobility for shallow water flux
**What does this feature / why does DuMux need it**:
Wetting and drying of elements is actually stabilized with a mobility term which acts only on the mass equation and not on the momentum equations. The average water depth of the left and right cell is used to compute the mobility. For cases with small water depths (e.g. oscillating front in a bowl) and a fine mesh resolution, the current mobility treatment may have bad convergence properties.
I exported the Jacobian/Defect and used Scipy to solve/analyze the linear system. I figured out that the convergence properties strongly depend on the chosen preconditioner/linear solver/precision. Solving the system imprecisely may lead to a wrong solution and a non-converging Newton-solver. Trying to solve the linear system with a high acurracy with an inappropriate linear solver/perconditioner may fail.
In a short test I used the information (wave pattern) of the Riemann solver in combination with an upwind formulation of the mobility and applied it to the full system of euqations (mass and momentum). This improved the convergence properties dramatically. I suggest to compute the mobility depending on the wave pattern:
* left wave: only the water depth of the left side
* right wave: only water depth of the right side
* in between: water depth of the left and right side
and apply it on the full system.
**Which issue does this feature fix (if any)**
This feature will help to improve the convergence for test cases with small water depths when wetting and drying of elements occur.
**Anything else we need to know?**:
I will implement and test the new version to ensure that it outperforms the old one.<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Upwind mobility for shallow water flux
**What does this feature / why does DuMux need it**:
Wetting and drying of elements is actually stabilized with a mobility term which acts only on the mass equation and not on the momentum equations. The average water depth of the left and right cell is used to compute the mobility. For cases with small water depths (e.g. oscillating front in a bowl) and a fine mesh resolution, the current mobility treatment may have bad convergence properties.
I exported the Jacobian/Defect and used Scipy to solve/analyze the linear system. I figured out that the convergence properties strongly depend on the chosen preconditioner/linear solver/precision. Solving the system imprecisely may lead to a wrong solution and a non-converging Newton-solver. Trying to solve the linear system with a high acurracy with an inappropriate linear solver/perconditioner may fail.
In a short test I used the information (wave pattern) of the Riemann solver in combination with an upwind formulation of the mobility and applied it to the full system of euqations (mass and momentum). This improved the convergence properties dramatically. I suggest to compute the mobility depending on the wave pattern:
* left wave: only the water depth of the left side
* right wave: only water depth of the right side
* in between: water depth of the left and right side
and apply it on the full system.
**Which issue does this feature fix (if any)**
This feature will help to improve the convergence for test cases with small water depths when wetting and drying of elements occur.
**Anything else we need to know?**:
I will implement and test the new version to ensure that it outperforms the old one.Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/796[tabulation] adaptive linear tables2019-12-19T13:25:39ZBeatrix 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/795[tabulation] Generalize tabulation and interpolation2019-12-19T13:26:46ZBeatrix 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.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/793[examples] Allow to exclude/fold code in the example README.md2019-11-29T13:17:49ZTimo Kochtimo.koch@iws.uni-stuttgart.de[examples] Allow to exclude/fold code in the example README.mdFor long files and class with a lot of boilerplate code it might be good to be able to exclude stuff from the automatically generated doc. This is probably possible by defining a keyword like
```c++
//[begin exclude]
...
//[end exclude]
```
Another idea would be (as an alternative or additionally to the suggestion above) to allow collapsible code snippet as demonstrated here:
<details>
<summary>Click to expand code snippet</summary>
```c++
class Class {
using Boilerplate = Code;
using Boilerplate = Code;
using Boilerplate = Code;
using Boilerplate = Code;
using Boilerplate = Code;
};
```
</details>
This could be also achieved with a keyword like
```c++
//[begin fold]
...
//[end fold]
```For long files and class with a lot of boilerplate code it might be good to be able to exclude stuff from the automatically generated doc. This is probably possible by defining a keyword like
```c++
//[begin exclude]
...
//[end exclude]
```
Another idea would be (as an alternative or additionally to the suggestion above) to allow collapsible code snippet as demonstrated here:
<details>
<summary>Click to expand code snippet</summary>
```c++
class Class {
using Boilerplate = Code;
using Boilerplate = Code;
using Boilerplate = Code;
using Boilerplate = Code;
using Boilerplate = Code;
};
```
</details>
This could be also achieved with a keyword like
```c++
//[begin fold]
...
//[end fold]
```3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/792MultiDomain does not work for solution-dependent spatial params in instationa...2020-01-09T16:34:10ZDennis 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), 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.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.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/788Variable Permeability and coupling free-flow-porous-media problems2019-12-03T05:51:48ZJohannes HommelVariable Permeability and coupling free-flow-porous-media problemsThe coupling manager as of now requires the spatial parameters of the porous-media problem to provide a permeabilityAtPos() function. However, when modeling evaporation-driven mineral precipitation, the permeability is not simply depending on the location, but on the solution of the porous-media problem. However, one does not really want to give the porous-media problem solution to the coupling manager.
I guess evaporation-driven mineral precipitation is one of the fancier applications for our free-flow-porous-media coupling and might become more popular, so we should think about a solution to this problem.The coupling manager as of now requires the spatial parameters of the porous-media problem to provide a permeabilityAtPos() function. However, when modeling evaporation-driven mineral precipitation, the permeability is not simply depending on the location, but on the solution of the porous-media problem. However, one does not really want to give the porous-media problem solution to the coupling manager.
I guess evaporation-driven mineral precipitation is one of the fancier applications for our free-flow-porous-media coupling and might become more popular, so we should think about a solution to this problem.Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/787New example for rotation symmetric problem2019-11-29T12:46:58ZTimo Kochtimo.koch@iws.uni-stuttgart.deNew example for rotation symmetric problemWe can now compute problems on rotation symmetric grids.
The results can be nicely visualized with ParaView using the `Rotational Extrusion` filter :).
It would be nice to have an example in the examples folder.
Possibly a comparison with an analytical solution so we can also demonstrate how to compute l2 errors for example.We can now compute problems on rotation symmetric grids.
The results can be nicely visualized with ParaView using the `Rotational Extrusion` filter :).
It would be nice to have an example in the examples folder.
Possibly a comparison with an analytical solution so we can also demonstrate how to compute l2 errors for example.3.2Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/777get rid of remaining `FV`s in names with `FVGridGeometry`2019-10-30T09:10:23ZBernd Flemischget rid of remaining `FV`s in names with `FVGridGeometry`There's several occurrences of names containing `FVGridGeometry`, for example:
* the property `EnableFVGridGeometryCache`
* several implementing classes `CCMpfaFVGridGeometry`, `CellCenterFVGridGeometry`...
* lots of local variables `bulkFvGridGeometry`, `stokesFvGridGeometry`...There's several occurrences of names containing `FVGridGeometry`, for example:
* the property `EnableFVGridGeometryCache`
* several implementing classes `CCMpfaFVGridGeometry`, `CellCenterFVGridGeometry`...
* lots of local variables `bulkFvGridGeometry`, `stokesFvGridGeometry`...Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/772Implement strongly enforced (internal) Dirichlet constraints for cell-centere...2019-10-02T14:55:10ZTimo Kochtimo.koch@iws.uni-stuttgart.deImplement strongly enforced (internal) Dirichlet constraints for cell-centered modelsThis is a follow up of #743. The cell-centered implementation of internal Dirichlet contrainst was incorrectly introduced with !1664. The wrong implementation is removed in !1725 and replaced by an error. Hence, this is a reminder that a correct implementation is still missing.
This is a feature request:
* Implement strongly enforced Dirichlet constraints for any user-chosen cell, using the interface implemented in !1664.This is a follow up of #743. The cell-centered implementation of internal Dirichlet contrainst was incorrectly introduced with !1664. The wrong implementation is removed in !1725 and replaced by an error. Hence, this is a reminder that a correct implementation is still missing.
This is a feature request:
* Implement strongly enforced Dirichlet constraints for any user-chosen cell, using the interface implemented in !1664.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/768[md][cc] Dirichlet-Dirichlet coupling does not work with setCouplingDirichlet2019-12-18T09:52:09ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[md][cc] Dirichlet-Dirichlet coupling does not work with setCouplingDirichletFor a Dirichlet-Dirichlet coupling, the boundary volVars of the own domain receive Dirichlet values from the other domain thus need to be deflected properly.
This only works if `setDirichlet()` is used in the poblem, not if `setCouplingDirichlet()` (which would be more intuitive).
The elemVolVars consider the boundary types' `hasOnlyDirichlet` which does not take `couplingDirichlet` into account.
One possible solution would be to also consider `couplingDirichlet` for `hasOnlyDirichlet`.
What do you think?For a Dirichlet-Dirichlet coupling, the boundary volVars of the own domain receive Dirichlet values from the other domain thus need to be deflected properly.
This only works if `setDirichlet()` is used in the poblem, not if `setCouplingDirichlet()` (which would be more intuitive).
The elemVolVars consider the boundary types' `hasOnlyDirichlet` which does not take `couplingDirichlet` into account.
One possible solution would be to also consider `couplingDirichlet` for `hasOnlyDirichlet`.
What do you think?3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/766Dumux handbook should contain a building date and a git-version-hashmark on t...2019-09-20T14:40:51ZDavid WernerDumux handbook should contain a building date and a git-version-hashmark on titlepageWhile it is also possible to provide to provide meta-information on the webpage, it would be nice to have them also inside the pdf-file. It should not be that hard to add it, I think \today would do it for the date. Think also about to include branch or tag if available. Maybe a small script could generate some latex-output to handle over information. Or there is also latex-package like [gitinfo2](http://ctan.math.washington.edu/tex-archive/macros/latex/contrib/gitinfo2/gitinfo2.pdf).While it is also possible to provide to provide meta-information on the webpage, it would be nice to have them also inside the pdf-file. It should not be that hard to add it, I think \today would do it for the date. Think also about to include branch or tag if available. Maybe a small script could generate some latex-output to handle over information. Or there is also latex-package like [gitinfo2](http://ctan.math.washington.edu/tex-archive/macros/latex/contrib/gitinfo2/gitinfo2.pdf).https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/765Add pre-commit hook for generating README.md in the examples folder2019-09-18T13:36:07ZBernd FlemischAdd pre-commit hook for generating README.md in the examples folderThe script `merge_cpp_and_md.sh` in `bin/doc/` can be used to create for each example folder a `README.md` out of the relevant C++ and Markdown files. Automate this generation by installing a pre-commit hook.The script `merge_cpp_and_md.sh` in `bin/doc/` can be used to create for each example folder a `README.md` out of the relevant C++ and Markdown files. Automate this generation by installing a pre-commit hook.3.2Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/763[FreeFlow] No Newton convergence for pressure Dirichlet BCs at high Re2019-09-05T07:39:06ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[FreeFlow] No Newton convergence for pressure Dirichlet BCs at high ReFor simple pipe flow, setting Dirichlet BCs for the pressure both at the inlet and outlet
works well for low Re. For higher Re, the Newton scheme does not converge anymore.
Setting the inlet BCs to Dirichlet for velocity works.
This should be investigated. Maybe the assumption of
$`\nabla \mathbf{v} \cdot \mathbf{n} = 0 `$
and
$`\nabla p \cdot \mathbf{n} = 0 `$
used for the pressure BC causes this problem?For simple pipe flow, setting Dirichlet BCs for the pressure both at the inlet and outlet
works well for low Re. For higher Re, the Newton scheme does not converge anymore.
Setting the inlet BCs to Dirichlet for velocity works.
This should be investigated. Maybe the assumption of
$`\nabla \mathbf{v} \cdot \mathbf{n} = 0 `$
and
$`\nabla p \cdot \mathbf{n} = 0 `$
used for the pressure BC causes this problem?3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/761Cleanup explicit flash of implicit 2p2c model2019-10-26T08:13:33ZBeatrix BeckerCleanup explicit flash of implicit 2p2c modelThe volumevariables of the 2p2c model have an explicit flash directly implemented in the volumevariables itself.
* In general I like the idea of a specialized 2p2c flash that is easy to understand and fast, but it shouldn't be included in the volumevariables. I would propose implementing it as a separate class in a separate header, like the other constraintsolvers.
* The flash is only used if `useConstraintSolver` is false and the default is true. For the 2p2c model I would make the flash the default, since it is a faster calculation than using the more general `MiscibleMultiPhaseComposition` constraintsolver which solves a linear system of equations. Maybe we should even completely delete `useConstraintSolver` because in my opinion the solver has no benefit here, it solves the same equations, just less efficiently.
* For the case of one phase we may use the `ComputeFromReferencePhase` constraintsolver since it does exactly what the flash does.
* I don't think the flash is currently tested, so this should be added. It should have the same result as the other constraintsolvers.
What do you think? Another solution could be to delete the flash code and always use the solvers that we already have, but as mentioned above, I prefer having a 2p2c-specific flash.
There are a few points that I'm not sure of, maybe @holle can comment on this:
* In my opinion this flash is not as correct as it could be because it uses the assumption that vapor pressure of the liquid component and partial pressure of the liquid component in the gas phase are the same. This is only the case if we neglect the presence of other components in the gas phase. There is an equally quick method to calculate the mass fractions without using this assumption, see the 2p2c flash of the sequential models.
* It seems that the flash assumes that we deal with one liquid and one gas phase and that the liquid phase is the first phase. I think the 2p2c flash of the sequential models doesn't have this constraint.
* There seems to be a bug in the case that only the first phase is present, in the calculation of the mole fraction of the first component in the second phase. A multiplication with the mole fraction of the first component in the first phase is probably missing.The volumevariables of the 2p2c model have an explicit flash directly implemented in the volumevariables itself.
* In general I like the idea of a specialized 2p2c flash that is easy to understand and fast, but it shouldn't be included in the volumevariables. I would propose implementing it as a separate class in a separate header, like the other constraintsolvers.
* The flash is only used if `useConstraintSolver` is false and the default is true. For the 2p2c model I would make the flash the default, since it is a faster calculation than using the more general `MiscibleMultiPhaseComposition` constraintsolver which solves a linear system of equations. Maybe we should even completely delete `useConstraintSolver` because in my opinion the solver has no benefit here, it solves the same equations, just less efficiently.
* For the case of one phase we may use the `ComputeFromReferencePhase` constraintsolver since it does exactly what the flash does.
* I don't think the flash is currently tested, so this should be added. It should have the same result as the other constraintsolvers.
What do you think? Another solution could be to delete the flash code and always use the solvers that we already have, but as mentioned above, I prefer having a 2p2c-specific flash.
There are a few points that I'm not sure of, maybe @holle can comment on this:
* In my opinion this flash is not as correct as it could be because it uses the assumption that vapor pressure of the liquid component and partial pressure of the liquid component in the gas phase are the same. This is only the case if we neglect the presence of other components in the gas phase. There is an equally quick method to calculate the mass fractions without using this assumption, see the 2p2c flash of the sequential models.
* It seems that the flash assumes that we deal with one liquid and one gas phase and that the liquid phase is the first phase. I think the 2p2c flash of the sequential models doesn't have this constraint.
* There seems to be a bug in the case that only the first phase is present, in the calculation of the mole fraction of the first component in the second phase. A multiplication with the mole fraction of the first component in the first phase is probably missing.3.2Beatrix BeckerBeatrix Beckerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/759compositionalflash.hh: iterate saturation and pressure within flash2019-08-28T15:13:56ZBeatrix Beckercompositionalflash.hh: iterate saturation and pressure within flashThe function `concentrationFlash2p2c` gets both phase pressures as input. Since the saturation is unknown, one of these pressures (more precisely, the capillary pressure) is unknown, too. In the code the pressure is iterated outside of the flash, e.g., in the routine that updates the secondary variables, and the flash is called several times during that iteration. This is not consistent with the implicit code, in my opinion, and also not very convenient. The flash should take care of iterating saturation and pressure, in my opinion.The function `concentrationFlash2p2c` gets both phase pressures as input. Since the saturation is unknown, one of these pressures (more precisely, the capillary pressure) is unknown, too. In the code the pressure is iterated outside of the flash, e.g., in the routine that updates the secondary variables, and the flash is called several times during that iteration. This is not consistent with the implicit code, in my opinion, and also not very convenient. The flash should take care of iterating saturation and pressure, in my opinion.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/758compositionalflash.hh: porosity is not used2019-08-28T15:03:37ZBeatrix Beckercompositionalflash.hh: porosity is not usedSome functions in CompositionalFlash require porosity as input, which is never used. Needs to be deleted and deprecated.Some functions in CompositionalFlash require porosity as input, which is never used. Needs to be deleted and deprecated.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/756Periodic Boundary Conditions for FreeFlow2019-09-19T11:45:52ZLars KaiserPeriodic Boundary Conditions for FreeFlow<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Periodic Boundary Conditions for FreeFlow
**What does this feature / why does DuMux need it**:
Periodic Boundary Conditions are a common and useful BC and help to overcome the problem of finding appropriate BC for finite domains.
**Which issue does this feature fix (if any)**
It would enable using Periodic Boundary Conditions in a coupled Darcy-FreeFlow model.
Periodic Boundary Conditions are already implemented for Darcy's law but can't be used reasonable in a coupled model with freeflow, because freeflow doesn't allow Periodic Boundary Conditions.
**Anything else we need to know?**:
Already mentioned in dumux-repositories/dumux#487<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Periodic Boundary Conditions for FreeFlow
**What does this feature / why does DuMux need it**:
Periodic Boundary Conditions are a common and useful BC and help to overcome the problem of finding appropriate BC for finite domains.
**Which issue does this feature fix (if any)**
It would enable using Periodic Boundary Conditions in a coupled Darcy-FreeFlow model.
Periodic Boundary Conditions are already implemented for Darcy's law but can't be used reasonable in a coupled model with freeflow, because freeflow doesn't allow Periodic Boundary Conditions.
**Anything else we need to know?**:
Already mentioned in dumux-repositories/dumux#4873.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/754Automatic Differentiation2019-11-27T09:17:52ZNed 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 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 (...)<!--
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 (...)3.2Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/751[test] Unit test intersectspointgeometry incomplete2019-08-28T09:54:58ZTimo Kochtimo.koch@iws.uni-stuttgart.de[test] Unit test intersectspointgeometry incompletepoint-tetrahedron and point-pyramid is not tested
Maybe a dedicated unit test for this header would be good and easy to implement.point-tetrahedron and point-pyramid is not tested
Maybe a dedicated unit test for this header would be good and easy to implement.3.2