dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues2019-11-29T13:17:49Zhttps://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/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/784[test] Implement outflow BC for 1p tracer test2019-11-21T16:35:49ZSimon Emmert[test] Implement outflow BC for 1p tracer test<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Implement an outflow BC for the 1p tracer model to provide a better example for users.
**What does this feature / why does DuMux need it**:
Came up when fixing #782<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Implement an outflow BC for the 1p tracer model to provide a better example for users.
**What does this feature / why does DuMux need it**:
Came up when fixing #7823.2Simon EmmertSimon Emmerthttps://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-10-04T10:58:02ZKilian 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/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/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/745Implement HasResize2019-08-28T09:56:23ZTimo Kochtimo.koch@iws.uni-stuttgart.deImplement HasResizeThe following discussion from !1546 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1546#note_28434):
> I think has resize is also needed in other places. Theoretically we can just use a copy of https://web.math.pmf.unizg.hr/nastava/nrpdj/DuneDoc/release-2.6.1/dune-functions/doc/doxygen/html/a01948_source.html
> the implementation in dune functions and put it e.g. in dumux/common/concepts.hh
Also some other tiny "concepts" might be useful, however usually it's not real concepts so we should be careful.The following discussion from !1546 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1546#note_28434):
> I think has resize is also needed in other places. Theoretically we can just use a copy of https://web.math.pmf.unizg.hr/nastava/nrpdj/DuneDoc/release-2.6.1/dune-functions/doc/doxygen/html/a01948_source.html
> the implementation in dune functions and put it e.g. in dumux/common/concepts.hh
Also some other tiny "concepts" might be useful, however usually it's not real concepts so we should be careful.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/737Creating a bounding box tree for a vector of geometries2019-10-29T10:27:02ZTimo Kochtimo.koch@iws.uni-stuttgart.deCreating a bounding box tree for a vector of geometries<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Bounding box tree for a list of geometries without a grid
**What does this feature / why does DuMux need it**:
E.g. to intersect a polyline with a grid or some object where it would be
easier to just define the geometries instead of creating a Dune grid.
The bounding box tree is already general enough, it expects a EntitySet which only needs
to satisfy a certain subset of the interface of a Dune::GridView. So the task would be
to create a new EntitySet class which can be constructed from a vector of geometries instead
of from a grid view.<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Bounding box tree for a list of geometries without a grid
**What does this feature / why does DuMux need it**:
E.g. to intersect a polyline with a grid or some object where it would be
easier to just define the geometries instead of creating a Dune grid.
The bounding box tree is already general enough, it expects a EntitySet which only needs
to satisfy a certain subset of the interface of a Dune::GridView. So the task would be
to create a new EntitySet class which can be constructed from a vector of geometries instead
of from a grid view.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/736Plot over line class2019-08-28T09:56:58ZTimo Kochtimo.koch@iws.uni-stuttgart.dePlot over line class<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Plot-over-line class
**What does this feature / why does DuMux need it**:
For post-processing it should be fairly easy to create a plot over line class that creates a user-defined number of points
along a line and evaluates the solution. (Using the bboxtree and its point search capabilities)<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Plot-over-line class
**What does this feature / why does DuMux need it**:
For post-processing it should be fairly easy to create a plot over line class that creates a user-defined number of points
along a line and evaluates the solution. (Using the bboxtree and its point search capabilities)3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/733Make MPFA handle zero coefficients (like effective diffusion coefficient)2019-09-10T14:26:41ZTimo Kochtimo.koch@iws.uni-stuttgart.deMake MPFA handle zero coefficients (like effective diffusion coefficient)The following discussion from !1648 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1648#note_27837):
> before we merge this I think we have to fix first that MPFA can handle zero coefficients.The following discussion from !1648 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1648#note_27837):
> before we merge this I think we have to fix first that MPFA can handle zero coefficients.3.2Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/730Partial numerical differentiation2019-06-27T09:35:53ZMartin SchneiderPartial numerical differentiationIt would be nice to have the possibility in Dumux to choose which equation
is differentiated with respect to which variable.
For example if we solve a richardsni problem where we assume that the solution of richards equation
is independent of the temperature (e.g. if densities and viscosities are constant)
we do not need to calculate the derivatives of richards equation with respect to temperature.
This could be realized by introducing some table that lists if `eqIdx` should be differentiated
with respect to `pvIdx`. Furthermore, this could also help to decouple problems or to implement other solvers than Newton's method.It would be nice to have the possibility in Dumux to choose which equation
is differentiated with respect to which variable.
For example if we solve a richardsni problem where we assume that the solution of richards equation
is independent of the temperature (e.g. if densities and viscosities are constant)
we do not need to calculate the derivatives of richards equation with respect to temperature.
This could be realized by introducing some table that lists if `eqIdx` should be differentiated
with respect to `pvIdx`. Furthermore, this could also help to decouple problems or to implement other solvers than Newton's method.Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/710Follow-up from "Feature/simplify effective laws"2019-08-28T08:48:16ZTimo Kochtimo.koch@iws.uni-stuttgart.deFollow-up from "Feature/simplify effective laws"The following discussion from !1605 should be addressed:
- [ ] @DennisGlaeser started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1605#note_26777): (+3 comments)
> I thought we removed wPhaseIdx from the Indices and made this a runtime-thing? How does this actually compile?
* [ ] Make wetting phase index retrievable from 2p volvars
* [ ] Use them in Johansen effective thermal conductivity lawThe following discussion from !1605 should be addressed:
- [ ] @DennisGlaeser started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1605#note_26777): (+3 comments)
> I thought we removed wPhaseIdx from the Indices and made this a runtime-thing? How does this actually compile?
* [ ] Make wetting phase index retrievable from 2p volvars
* [ ] Use them in Johansen effective thermal conductivity law3.2Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/707Generic implementation of L2-norm calculation using generic L2-projection2019-05-31T21:20:12ZTimo Kochtimo.koch@iws.uni-stuttgart.deGeneric implementation of L2-norm calculation using generic L2-projectionWith !1609 we get a generic l2-projection. In order to use it for interpolation between two arbitrary grids (arbitrary function spaces already works), we need to implement
* [x] 2d-2d intersections (!1625)
* [ ] 3d-3d intersections
That would be a great tool for convergence tests.With !1609 we get a generic l2-projection. In order to use it for interpolation between two arbitrary grids (arbitrary function spaces already works), we need to implement
* [x] 2d-2d intersections (!1625)
* [ ] 3d-3d intersections
That would be a great tool for convergence tests.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/706Add turbulent diffusion to shallow water model2019-05-21T12:20:07ZFrank PlatzekAdd turbulent diffusion to shallow water modelThe preliminary turbulent diffusion implementation in the shallow water model from Issue #657
(Turbulent diffusion in shallow water equations), is to be merged in the new structure for the shallow water model as part of the Freeflow model.The preliminary turbulent diffusion implementation in the shallow water model from Issue #657
(Turbulent diffusion in shallow water equations), is to be merged in the new structure for the shallow water model as part of the Freeflow model.Frank PlatzekFrank Platzekhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/686Improve usage of container types in staggered2019-08-28T08:50:44ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deImprove usage of container types in staggered* Replace `std::vector` by `Dune::ReservedVector` or even `std::array`, where possible
* most sizes are known at compile time* Replace `std::vector` by `Dune::ReservedVector` or even `std::array`, where possible
* most sizes are known at compile time3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/682Test tabulation doesn't actually test anything2019-11-29T12:49:21ZTimo Kochtimo.koch@iws.uni-stuttgart.deTest tabulation doesn't actually test anythingNo matter if success is false or true the test always returns 0 exit code.No matter if success is false or true the test always returns 0 exit code.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/676[components] TabulatedComponent cannot be used for all components (e.g., air)2019-11-29T15:18:20ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[components] TabulatedComponent cannot be used for all components (e.g., air)Some components are lacking `vaporPressure()`, thus they cannot be compiled with a tabulation.
We could rethink this and only do the tabulation if the raw component acutally implements `vaporPressure()`, otherwise a runtime error could be thrown.Some components are lacking `vaporPressure()`, thus they cannot be compiled with a tabulation.
We could rethink this and only do the tabulation if the raw component acutally implements `vaporPressure()`, otherwise a runtime error could be thrown.3.2Timo Kochtimo.koch@iws.uni-stuttgart.deTimo Kochtimo.koch@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/675[freeflow] Remove property NormalizePressure2019-08-28T08:59:00ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[freeflow] Remove property NormalizePressureWhen enabled, all pressure related calculations for the momentum equations are done with `p - p_const`. The idea was to lower the numerical values of the pressure in the hope of decreasing numerical errors when further processing the values in for the Jacobian. However, `p - p_const` probably already introduces the same error we wanted to avoid in the first place.
The property and the pressure normalization should therefore be removed after a check of the Matrix' condition number.When enabled, all pressure related calculations for the momentum equations are done with `p - p_const`. The idea was to lower the numerical values of the pressure in the hope of decreasing numerical errors when further processing the values in for the Jacobian. However, `p - p_const` probably already introduces the same error we wanted to avoid in the first place.
The property and the pressure normalization should therefore be removed after a check of the Matrix' condition number.3.2Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/661Possibly include update of Box flux variables cache2019-08-28T09:07:23ZDennis GläserPossibly include update of Box flux variables cacheThe flux variable caches for the box scheme are always assumed to be solution-independent. We should think of a way to support user-defined, solution-dependent caches.The flux variable caches for the box scheme are always assumed to be solution-independent. We should think of a way to support user-defined, solution-dependent caches.3.2