dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues2019-09-19T09:10:29Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/761Cleanup explicit flash of implicit 2p2c model2019-09-19T09:10:29ZBeatrix BeckerCleanup explicit flash of implicit 2p2c modelThe volumevariables of the 2p2c model have an explicit flash directly implemented in the volumevariables itself.
* In general I like the idea of a specialized 2p2c flash that is easy to understand and fast, but it shouldn't be included in the volumevariables. I would propose implementing it as a separate class in a separate header, like the other constraintsolvers.
* The flash is only used if `useConstraintSolver` is false and the default is true. For the 2p2c model I would make the flash the default, since it is a faster calculation than using the more general `MiscibleMultiPhaseComposition` constraintsolver which solves a linear system of equations. Maybe we should even completely delete `useConstraintSolver` because in my opinion the solver has no benefit here, it solves the same equations, just less efficiently.
* For the case of one phase we may use the `ComputeFromReferencePhase` constraintsolver since it does exactly what the flash does.
* I don't think the flash is currently tested, so this should be added. It should have the same result as the other constraintsolvers.
What do you think? Another solution could be to delete the flash code and always use the solvers that we already have, but as mentioned above, I prefer having a 2p2c-specific flash.
There are a few points that I'm not sure of, maybe @holle can comment on this:
* In my opinion this flash is not as correct as it could be because it uses the assumption that vapor pressure of the liquid component and partial pressure of the liquid component in the gas phase are the same. This is only the case if we neglect the presence of other components in the gas phase. There is an equally quick method to calculate the mass fractions without using this assumption, see the 2p2c flash of the sequential models.
* It seems that the flash assumes that we deal with one liquid and one gas phase and that the liquid phase is the first phase. I think the 2p2c flash of the sequential models doesn't have this constraint.
* There seems to be a bug in the case that only the first phase is present, in the calculation of the mole fraction of the first component in the second phase. A multiplication with the mole fraction of the first component in the first phase is probably missing.The volumevariables of the 2p2c model have an explicit flash directly implemented in the volumevariables itself.
* In general I like the idea of a specialized 2p2c flash that is easy to understand and fast, but it shouldn't be included in the volumevariables. I would propose implementing it as a separate class in a separate header, like the other constraintsolvers.
* The flash is only used if `useConstraintSolver` is false and the default is true. For the 2p2c model I would make the flash the default, since it is a faster calculation than using the more general `MiscibleMultiPhaseComposition` constraintsolver which solves a linear system of equations. Maybe we should even completely delete `useConstraintSolver` because in my opinion the solver has no benefit here, it solves the same equations, just less efficiently.
* For the case of one phase we may use the `ComputeFromReferencePhase` constraintsolver since it does exactly what the flash does.
* I don't think the flash is currently tested, so this should be added. It should have the same result as the other constraintsolvers.
What do you think? Another solution could be to delete the flash code and always use the solvers that we already have, but as mentioned above, I prefer having a 2p2c-specific flash.
There are a few points that I'm not sure of, maybe @holle can comment on this:
* In my opinion this flash is not as correct as it could be because it uses the assumption that vapor pressure of the liquid component and partial pressure of the liquid component in the gas phase are the same. This is only the case if we neglect the presence of other components in the gas phase. There is an equally quick method to calculate the mass fractions without using this assumption, see the 2p2c flash of the sequential models.
* It seems that the flash assumes that we deal with one liquid and one gas phase and that the liquid phase is the first phase. I think the 2p2c flash of the sequential models doesn't have this constraint.
* There seems to be a bug in the case that only the first phase is present, in the calculation of the mole fraction of the first component in the second phase. A multiplication with the mole fraction of the first component in the first phase is probably missing.3.1Beatrix BeckerBeatrix Beckerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/754Automatic Differentiation2019-08-28T08:24:16ZNed 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-08-28T09:56:45ZTimo Kochtimo.koch@iws.uni-stuttgart.deCreating a bounding box tree for a vector of geometries<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Bounding box tree for a list of geometries without a grid
**What does this feature / why does DuMux need it**:
E.g. to intersect a polyline with a grid or some object where it would be
easier to just define the geometries instead of creating a Dune grid.
The bounding box tree is already general enough, it expects a EntitySet which only needs
to satisfy a certain subset of the interface of a Dune::GridView. So the task would be
to create a new EntitySet class which can be constructed from a vector of geometries instead
of from a grid view.<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Bounding box tree for a list of geometries without a grid
**What does this feature / why does DuMux need it**:
E.g. to intersect a polyline with a grid or some object where it would be
easier to just define the geometries instead of creating a Dune grid.
The bounding box tree is already general enough, it expects a EntitySet which only needs
to satisfy a certain subset of the interface of a Dune::GridView. So the task would be
to create a new EntitySet class which can be constructed from a vector of geometries instead
of from a grid view.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/736Plot over line class2019-08-28T09:56:58ZTimo Kochtimo.koch@iws.uni-stuttgart.dePlot over line class<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Plot-over-line class
**What does this feature / why does DuMux need it**:
For post-processing it should be fairly easy to create a plot over line class that creates a user-defined number of points
along a line and evaluates the solution. (Using the bboxtree and its point search capabilities)<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Plot-over-line class
**What does this feature / why does DuMux need it**:
For post-processing it should be fairly easy to create a plot over line class that creates a user-defined number of points
along a line and evaluates the solution. (Using the bboxtree and its point search capabilities)3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/734Make cakegridcreator work for the case that the well is not excluded from the...2019-08-28T09:57:32ZMartin SchneiderMake cakegridcreator work for the case that the well is not excluded from the gridAt the moment it seems that the cakegridcreator only works if the well is
excluded from the grid. This allows to use cubic cells.
However, if the well is for example modelled using a line source, the well
should not be excluded from the grid.
Thus, it would be nice if this gridcreator could generate a grid where the well is not excluded.
This could be done by using prism cells at the well location.At the moment it seems that the cakegridcreator only works if the well is
excluded from the grid. This allows to use cubic cells.
However, if the well is for example modelled using a line source, the well
should not be excluded from the grid.
Thus, it would be nice if this gridcreator could generate a grid where the well is not excluded.
This could be done by using prism cells at the well location.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/689Create meaningful new 2pncmin NI test2019-08-28T14:15:32ZSimon EmmertCreate meaningful new 2pncmin NI testWe forgot to add the thermal conductivity law for the 2pncmin **NI** cases because there is no test available. This is addressed in !1560
We should come up with a (in my opinion) **new** test that uses the NI. I think a new test would be beneficial, because the current 2pncmin test is already relatively unstable.We forgot to add the thermal conductivity law for the 2pncmin **NI** cases because there is no test available. This is addressed in !1560
We should come up with a (in my opinion) **new** test that uses the NI. I think a new test would be beneficial, because the current 2pncmin test is already relatively unstable.3.1Theresa KurzTheresa Kurzhttps://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-08-28T08:55:19ZTimo 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-08-28T08:55:33ZKilian 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.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/675[freeflow] Remove property NormalizePressure2019-08-28T08:59:00ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[freeflow] Remove property NormalizePressureWhen enabled, all pressure related calculations for the momentum equations are done with `p - p_const`. The idea was to lower the numerical values of the pressure in the hope of decreasing numerical errors when further processing the values in for the Jacobian. However, `p - p_const` probably already introduces the same error we wanted to avoid in the first place.
The property and the pressure normalization should therefore be removed after a check of the Matrix' condition number.When enabled, all pressure related calculations for the momentum equations are done with `p - p_const`. The idea was to lower the numerical values of the pressure in the hope of decreasing numerical errors when further processing the values in for the Jacobian. However, `p - p_const` probably already introduces the same error we wanted to avoid in the first place.
The property and the pressure normalization should therefore be removed after a check of the Matrix' condition number.3.2Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/661Possibly include update of Box flux variables cache2019-08-28T09:07:23ZDennis GläserPossibly include update of Box flux variables cacheThe flux variable caches for the box scheme are always assumed to be solution-independent. We should think of a way to support user-defined, solution-dependent caches.The flux variable caches for the box scheme are always assumed to be solution-independent. We should think of a way to support user-defined, solution-dependent caches.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/657Turbulent diffusion in shallow water equations2019-05-21T12:19:00ZFrank PlatzekTurbulent diffusion in shallow water equationsAdd diffusion terms to the shallow water equations. One or more turbulence models will follow later. For now a rudimentary implementation is chosen which is only accurate on orthogonal grids. Possible non-orthogonal corrections will be added later on.Add diffusion terms to the shallow water equations. One or more turbulence models will follow later. For now a rudimentary implementation is chosen which is only accurate on orthogonal grids. Possible non-orthogonal corrections will be added later on.Frank PlatzekFrank Platzekhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/652Provide interface for more parallel solvers/preconditioners of ISTL2019-02-01T07:13:01ZLeopold StadlerProvide interface for more parallel solvers/preconditioners of ISTLSo far we have only the AMG-backend (parallel linear solver based on the ISTL AMG preconditioner and the ISTL BiCGSTAB solver). It would be great to add support for more preconditioners and solvers of ISTL.
The following combinations should be available:
* SSOR with BiCGSTAB
* ILU with BiCGSTAB
* ILU with GMRES
Are there any further wishes ?So far we have only the AMG-backend (parallel linear solver based on the ISTL AMG preconditioner and the ISTL BiCGSTAB solver). It would be great to add support for more preconditioners and solvers of ISTL.
The following combinations should be available:
* SSOR with BiCGSTAB
* ILU with BiCGSTAB
* ILU with GMRES
Are there any further wishes ?Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/592FicksLaw/FouriersLaw for Facet Coupling2019-08-28T09:31:19ZDennis GläserFicksLaw/FouriersLaw for Facet CouplingIn the current status the user gets no error when using a compositional or non-isothermal model together with the facet coupling framework. However, it the respective laws are not implemented.
In !1245, these are introduced. But the issue with obtaining the effective laws used in the (dim-1)-dimanensional domain still needs to be resolved in a nice way.In the current status the user gets no error when using a compositional or non-isothermal model together with the facet coupling framework. However, it the respective laws are not implemented.
In !1245, these are introduced. But the issue with obtaining the effective laws used in the (dim-1)-dimanensional domain still needs to be resolved in a nice way.3.2Dennis GläserDennis Gläser