dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues2019-07-19T14:23:41Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/741BoundaryFlag for ALUGrid with Gmsh mesh file2019-07-19T14:23:41ZSamuel ScherrerBoundaryFlag for ALUGrid with Gmsh mesh fileA while ago I had problems with the `BoundaryFlag` specialization for `ALUGrid`, as described [on the mailing list](https://listserv.uni-stuttgart.de/pipermail/dumux/2019q2/002307.html)
Timo did propose a clean solution, however, this was beyond my C++ skills. Since it is also not easy to change the value of `DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS`, would it be possible to add an additional compile time flag to the check whether the BoundaryFlag specialization for ALUGrid should be used?
That is, changing line 198 of dumux/io/grid/gridmanager_alu.hh from
```
#if DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS
```
to
```
#if DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS && !defined(USE_GMSH_BOUNDARY_FLAGS_WITH_ALUGRID)
```
If so, are there any naming preferences?A while ago I had problems with the `BoundaryFlag` specialization for `ALUGrid`, as described [on the mailing list](https://listserv.uni-stuttgart.de/pipermail/dumux/2019q2/002307.html)
Timo did propose a clean solution, however, this was beyond my C++ skills. Since it is also not easy to change the value of `DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS`, would it be possible to add an additional compile time flag to the check whether the BoundaryFlag specialization for ALUGrid should be used?
That is, changing line 198 of dumux/io/grid/gridmanager_alu.hh from
```
#if DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS
```
to
```
#if DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS && !defined(USE_GMSH_BOUNDARY_FLAGS_WITH_ALUGRID)
```
If so, are there any naming preferences?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/738ParamterFile is shown as unused parameter2019-07-14T22:01:23ZTimo Kochtimo.koch@iws.uni-stuttgart.deParamterFile is shown as unused parameterIf a parameter file is passed it is shown under unused parameters. This is confusing.If a parameter file is passed it is shown under unused parameters. This is confusing.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/737Creating a bounding box tree for a vector of geometries2019-07-12T15:19:36ZTimo 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.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/736Plot over line class2019-07-12T15:15:55ZTimo 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)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/734Make cakegridcreator work for the case that the well is not excluded from the...2019-07-03T10:10:37ZMartin 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.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/733Make MPFA handle zero coefficients (like effective diffusion coefficient)2019-07-02T09:01:26ZTimo 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.1Dennis 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-06-27T09:36:36ZTimo 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.1Katharina 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-04-24T07:48:32ZSimon ScholzCreate 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-06-25T12:29:55ZKilian 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.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/682Test tabulation doesn't actually test anything2019-03-27T19:33:51ZTimo 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.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/676[components] TabulatedComponent cannot be used for all components (e.g., air)2019-05-18T11:53:38ZKilian 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.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/675[freeflow] Remove property NormalizePressure2019-04-02T06:11:33ZKilian 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.1Kilian 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-05-18T11:37:21ZDennis 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.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/660Pass FluxVarsCache to Neumann Function2019-06-25T12:31:26ZDennis GläserPass FluxVarsCache to Neumann FunctionWe build the flux variable caches for boundary faces, but do not hand them into the Neumann function, where it could be used. For box, we actually never use the object, so it's unnecessary overhead.We build the flux variable caches for boundary faces, but do not hand them into the Neumann function, where it could be used. For box, we actually never use the object, so it's unnecessary overhead.3.1https://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 Coupling2018-11-12T15:08:37ZDennis 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.1Dennis GläserDennis Gläser