dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2020-05-27T06:47:32Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/736Plot over line class2020-05-27T06:47:32ZTimo Kochtimokoch@math.uio.noPlot 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 ...<!--
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.3https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/737Creating a bounding box tree for a vector of geometries2019-12-20T13:05:49ZTimo Kochtimokoch@math.uio.noCreating 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...<!--
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/738ParamterFile is shown as unused parameter2019-07-25T07:57:37ZTimo Kochtimokoch@math.uio.noParamterFile 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/739Unit test for compositional flash2019-10-04T09:42:27ZBeatrix BeckerUnit test for compositional flashThere is none currentlyThere is none currently3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/740Enforce constraints in fluid state or algorithm?2023-12-13T11:13:07ZBeatrix BeckerEnforce constraints in fluid state or algorithm?Currently only one mass fraction has to be set for the compositional fluid state, the other one is internally deduced from that. This only works for two component models. In general: is it a good idea that the fluid state enforces such c...Currently only one mass fraction has to be set for the compositional fluid state, the other one is internally deduced from that. This only works for two component models. In general: is it a good idea that the fluid state enforces such constraints or wouldn't it be better if the algorithm took care of that? @timok suggests that the fluid state could have a function like checkSumMoleFractions(Scalar value=1.0) to be able to assert the constraint before an algorithm that has that assumption about a fluid state.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/741BoundaryFlag for ALUGrid with Gmsh mesh file2019-07-25T13:13:17ZSamuel 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 w...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/742Unused reference solutions2019-09-03T05:39:05ZBernd FlemischUnused reference solutionsThese reference solutions are currently not used:
```text
1p2ctestccmpfa-reference.vtu
1pnctestbox-00009.vtu
1pnctestcc-00009.vtu
1ptestccmpfa-reference.vtu
2cnistokes2p2cniboundarylayer-ff-reference.vtu
2cnistokes2p2cni-ff-reference.vtu...These reference solutions are currently not used:
```text
1p2ctestccmpfa-reference.vtu
1pnctestbox-00009.vtu
1pnctestcc-00009.vtu
1ptestccmpfa-reference.vtu
2cnistokes2p2cniboundarylayer-ff-reference.vtu
2cnistokes2p2cni-ff-reference.vtu
2cnistokes2p2cni-pm-reference.vtu
2cnizeroeq2p2cni-ff-reference.vtu
2cstokes2p2c-ff-reference.vtu
2czeroeq2p2c-ff-reference.vtu
2pdfm-reference.vtu
box1pncmin-00042.vtu
box2pmincdist-reference.vtu
box2pmincvol-reference.vtu
cc1pncmin-00042.vtu
ccmpfatracer-reference.vtu
el1p2c-reference.vtu
el2p-parallel-reference.vtu
el2p-reference.vtu
elasticmatrix-reference.vtu
forchheimer1p-reference.vtp
forchheimer2p-reference.vtu
generalizeddirichlet-reference.vtp
generallens_box-reference.vtu
generallens_cc-reference.vtu
generallens_sequential-reference.vtu
rosi2c-root-reference.vtp
rosi2c-soil-reference.vtu
test_adaptive2p2c2d-reference.vtu
test_adaptive2p2c3d-reference.vtu
test_ff_navierstokes_sincos_stationary-reference.vtu
test_md_boundary_darcy2p2cni_stokes1p2cni_vertical_darcy-reference.vtu
test_md_boundary_darcy2p2cni_stokes1p2cni_vertical_stokes-reference.vtu
test_md_boundary_darcy2p2c_stokes1p2c_vertical_darcy-reference.vtu
test_md_boundary_darcy2p2c_stokes1p2c_vertical_stokes-reference.vtu
```
If nobody objects in general or against individual files before July 21, I will file a merge request that deletes the (remaining) files.3.1Bernd FlemischBernd Flemisch2019-07-21https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/743Strongly enforced Dirichlet constraints for cell-centered (internal, core+mul...2019-10-04T14:15:45ZTimo Kochtimokoch@math.uio.noStrongly enforced Dirichlet constraints for cell-centered (internal, core+multidomain) not correct<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
* ~~For box multidomain:~~
~~If Dirichlet is set for a dof that also has a coupling derivative the entire matrix ...<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
* ~~For box multidomain:~~
~~If Dirichlet is set for a dof that also has a coupling derivative the entire matrix line has to be set to zero. Currently this is only done for the diagonal block. This bug might be actually in use for the boundary coupling code where this kind of incorporation is wanted, but also this is not a Dirichlet constraint (equation is not replaced by the Dirichlet constraint but by the coupling condition).~~ Edit: I was mistakes and this is already implemented.
* For cell-centered (internal Dirichlet):
The Dirichlet conditions are currently enforced in the local assembler. However due to the assembly procedure the matrix rows are overwritten again later in the assembly of other elements. In order to fix this the constraints need to be either implemented after the whole matrix has been assembled (local caches cannot be reused), or (more complicated to read but maybe more efficient) they have to be incorporated during the assembly (don't write anything in rows of Dirichlet dofs)
**What happened / Problem description**:
Jacobian is corrupted.
**What you expected to happen**:
Dirichlet constraints are strongly enforced in the matrix.
**How to reproduce it (as minimally and precisely as possible)**:
The internal Dirichlet test for cell-centered.
**Anything else we need to know?**:
We should think about a better solution how and when to incorporate Dirichlet constraints.
**Environment**:
- DuMux version: master (the cell-centered part was only instroduced recently !1664)3.1Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/744Unused headers2019-09-03T08:49:06ZBernd FlemischUnused headersThe following headers are currently not used in Dumux itself. Please change the table to mark the headers for something else than "delete", if you think that they should be kept. Please do so before July 26.
| header ...The following headers are currently not used in Dumux itself. Please change the table to mark the headers for something else than "delete", if you think that they should be kept. Please do so before July 26.
| header | delete | test | keep w/o test |
| -------------------------------------- |:------:|:----:|:-------------:|
| common/intrange.hh | X | | |
| discretization/basefvgridgeometry.hh | X | | |
| io/grid/cakegridcreator.hh | X | | |
| io/grid/subgridgridcreator.hh | X | | |
| material/binarycoefficients/h2o_ch4.hh | | x | |3.1Bernd FlemischBernd Flemisch2019-07-26https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/745Implement HasResize2020-04-06T18:32:08ZTimo Kochtimokoch@math.uio.noImplement 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 p...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.2Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/746Error in flux calculation in Dumux 2.12 compositional stokes model2019-08-25T19:55:24ZGeorg FutterError in flux calculation in Dumux 2.12 compositional stokes model<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
**What happened / Problem description**:
Fluxes of transported components are not calculated correctly if there ...<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
**What happened / Problem description**:
Fluxes of transported components are not calculated correctly if there are more than 2 components in the fluid system and useMoles == true
**What you expected to happen**:
Correct calculation
**How to reproduce it (as minimally and precisely as possible)**:
Run compositional stokes test with more than 2 components
**Anything else we need to know?**:
In freeflow/stokesnc/localresidual.hh, lines 165-181, useMoles== true:
After line 177 tmp is not reset to fluxVars.normalVelocity(). Therefore, for all components after the first transported component the flux calculations are wrong.
**Environment**:
- DuMux version: 2.12https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/747SubGridManager probably does not work in parallel2019-08-27T16:54:14ZKilian WeishauptSubGridManager probably does not work in parallelThe loop over the host grid's elements for selecting the subgrid elements goes over the whole `gridView`
Instead we should probably only loop over the respective partition of the `gridView`.The loop over the host grid's elements for selecting the subgrid elements goes over the whole `gridView`
Instead we should probably only loop over the respective partition of the `gridView`.3.1Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/748Pass previous solution pointer to instationary assembler constructor2019-09-12T10:03:14ZTimo Kochtimokoch@math.uio.noPass previous solution pointer to instationary assembler constructorA pointer (preferably a shared_ptr) to the previous solution could be already passed to the
constructor of the instationary assembler. In fact that should be obligatory so you can't forget.
We could still have setPreviousSolution (prefer...A pointer (preferably a shared_ptr) to the previous solution could be already passed to the
constructor of the instationary assembler. In fact that should be obligatory so you can't forget.
We could still have setPreviousSolution (preferably with a shared_ptr) to change it later.
This would also get rid of the error handler that checks if a previous solution has been set if a timeLoop is present.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/749Default usage message not up-to-date2019-10-04T06:36:11ZTimo Kochtimokoch@math.uio.noDefault usage message not up-to-dateIt still contains TimeManager and PrintProperties...
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/blob/master/dumux/common/defaultusagemessage.hh
It's also never tested that it actually gets triggered. Could be done in a t...It still contains TimeManager and PrintProperties...
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/blob/master/dumux/common/defaultusagemessage.hh
It's also never tested that it actually gets triggered. Could be done in a tiny unit test.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/750Tabularization out-of-range warning too aggressive2019-09-12T10:08:35ZTimo Kochtimokoch@math.uio.noTabularization out-of-range warning too aggressiveFor access out-of-range of the table we currently print something like
```
FORWARD METHOD CALL liquidDensity(573.15, 6.24561e+06) OF COMPONENT 'H2O'. TABULATION TOO SMALL?
Subcritical values: Be aware to use Tables with sufficient resol...For access out-of-range of the table we currently print something like
```
FORWARD METHOD CALL liquidDensity(573.15, 6.24561e+06) OF COMPONENT 'H2O'. TABULATION TOO SMALL?
Subcritical values: Be aware to use Tables with sufficient resolution!
```
I find caps rather aggressive here, also it is not immediately clear that the fall-back is just a call
to the respective function and nothing severely wrong. I think the message should clearly state
* how the value was out of range
* that a fall-back is called and how
* that we just warn because of a runtime overhead (resulting from possibly wrong values for the tabulation bounds)
and not from some physical error3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/751[test] Unit test intersectspointgeometry incomplete2020-04-04T18:09:54ZTimo Kochtimokoch@math.uio.no[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.2Tim JupeTim Jupehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/752[test] Mpfa not tested in parallel2019-10-31T07:24:25ZTimo Kochtimokoch@math.uio.no[test] Mpfa not tested in parallelWe could add the richards parallel test for mpfa too. Solution should be identical to tpfa.We could add the richards parallel test for mpfa too. Solution should be identical to tpfa.3.2Roman WinterRoman Winterhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/753[tests] Newon line search not tested in test suite2019-11-08T09:42:13ZTimo Kochtimokoch@math.uio.no[tests] Newon line search not tested in test suiteWe could just enable if for some test, ideally where it also improves convergence.We could just enable if for some test, ideally where it also improves convergence.3.2Roman WinterRoman Winterhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/754Automatic Differentiation2023-12-13T11:13:06ZNed ColtmanAutomatic Differentiation<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Automatic Differentiation (AD)
**What does this feature / why does DuMux need it**:
Often used in othe...<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Automatic Differentiation (AD)
**What does this feature / why does DuMux need it**:
Often used in other software packages, should be more accurate than numerical differentiation
**Which issue does this feature fix (if any)**
Removes numerical differentiation imprecision, more similar to a hand built jacobian.
**Anything else we need to know?**:
OPM has implemented this already, and their method seems compatible with Dumux. Dumux AD could likely be copied from OPM for the most part.
OPM does Forward AD, set up with operator overloading.
See MR (...)Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/755[tabularization] Tabularization doesn't use the same spacing everywhere when ...2019-11-29T15:10:56ZTimo Kochtimokoch@math.uio.no[tabularization] Tabularization doesn't use the same spacing everywhere when useVaporPressure=trueFor use vaporPressure the liquid and gaseous states are tabularized separately both using the specified number of sample points. That leads to very different spacing throughout the parameter space. It would be more consistent to compute ...For use vaporPressure the liquid and gaseous states are tabularized separately both using the specified number of sample points. That leads to very different spacing throughout the parameter space. It would be more consistent to compute a spacing from the entire specified range and the specified number of sampling points and then use the same spacing to tabularize sub-spaces. That should also lead (with some tolerance) the total number of sampling point that the user specified.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/756Periodic Boundary Conditions for FreeFlow2021-09-16T14:38:43ZLars 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**:
Periodi...<!--
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#487Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/757Reformulate diffusion laws to match with mass reference velocities2019-10-02T12:13:52ZKatharina HeckReformulate diffusion laws to match with mass reference velocitiesAs discussed previously: if Darcys law and Navier Stokes law give mass averaged velocities we need to adapt the diffusion laws to calculate the gradient based on mass fractions not mole fractions.As discussed previously: if Darcys law and Navier Stokes law give mass averaged velocities we need to adapt the diffusion laws to calculate the gradient based on mass fractions not mole fractions.3.1Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/758compositionalflash.hh: porosity is not used2020-10-02T07:00:09ZBeatrix 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.3https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/759compositionalflash.hh: iterate saturation and pressure within flash2023-12-13T11:13:07ZBeatrix Beckercompositionalflash.hh: iterate saturation and pressure within flashThe function `concentrationFlash2p2c` gets both phase pressures as input. Since the saturation is unknown, one of these pressures (more precisely, the capillary pressure) is unknown, too. In the code the pressure is iterated outside of t...The function `concentrationFlash2p2c` gets both phase pressures as input. Since the saturation is unknown, one of these pressures (more precisely, the capillary pressure) is unknown, too. In the code the pressure is iterated outside of the flash, e.g., in the routine that updates the secondary variables, and the flash is called several times during that iteration. This is not consistent with the implicit code, in my opinion, and also not very convenient. The flash should take care of iterating saturation and pressure, in my opinion.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/760Tests for flashs don't test anything2019-10-04T11:07:26ZBeatrix BeckerTests for flashs don't test anythingThey never fail, just print an error.They never fail, just print an error.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/761Cleanup explicit flash of implicit 2p2c model2023-02-22T08:57:13ZBeatrix BeckerCleanup explicit flash of implicit 2p2c modelThe volumevariables of the 2p2c model have an explicit flash directly implemented in the volumevariables itself.
* In general I like the idea of a specialized 2p2c flash that is easy to understand and fast, but it shouldn't be included...The volumevariables of the 2p2c model have an explicit flash directly implemented in the volumevariables itself.
* In general I like the idea of a specialized 2p2c flash that is easy to understand and fast, but it shouldn't be included in the volumevariables. I would propose implementing it as a separate class in a separate header, like the other constraintsolvers.
* The flash is only used if `useConstraintSolver` is false and the default is true. For the 2p2c model I would make the flash the default, since it is a faster calculation than using the more general `MiscibleMultiPhaseComposition` constraintsolver which solves a linear system of equations. Maybe we should even completely delete `useConstraintSolver` because in my opinion the solver has no benefit here, it solves the same equations, just less efficiently.
* For the case of one phase we may use the `ComputeFromReferencePhase` constraintsolver since it does exactly what the flash does.
* I don't think the flash is currently tested, so this should be added. It should have the same result as the other constraintsolvers.
What do you think? Another solution could be to delete the flash code and always use the solvers that we already have, but as mentioned above, I prefer having a 2p2c-specific flash.
There are a few points that I'm not sure of, maybe @holle can comment on this:
* In my opinion this flash is not as correct as it could be because it uses the assumption that vapor pressure of the liquid component and partial pressure of the liquid component in the gas phase are the same. This is only the case if we neglect the presence of other components in the gas phase. There is an equally quick method to calculate the mass fractions without using this assumption, see the 2p2c flash of the sequential models (note: pre release 3.4)
* 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.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/762Dumux release 3.12019-10-14T08:10:54ZKatharina HeckDumux release 3.1All major changes that should be included and are not yet committed should be announced.
Add a comment here describing the feature and areas affected by the change.All major changes that should be included and are not yet committed should be announced.
Add a comment here describing the feature and areas affected by the change.3.1Katharina HeckKatharina Heck2019-10-11https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/763[FreeFlow] No Newton convergence for pressure Dirichlet BCs at high Re2023-02-22T08:58:22ZKilian Weishaupt[FreeFlow] No Newton convergence for pressure Dirichlet BCs at high ReFor simple pipe flow, setting Dirichlet BCs for the pressure both at the inlet and outlet
works well for low Re. For higher Re, the Newton scheme does not converge anymore.
Setting the inlet BCs to Dirichlet for velocity works.
This sh...For simple pipe flow, setting Dirichlet BCs for the pressure both at the inlet and outlet
works well for low Re. For higher Re, the Newton scheme does not converge anymore.
Setting the inlet BCs to Dirichlet for velocity works.
This should be investigated. Maybe the assumption of
$`\nabla \mathbf{v} \cdot \mathbf{n} = 0 `$
and
$`\nabla p \cdot \mathbf{n} = 0 `$
used for the pressure BC causes this problem?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/764[multidomain][boundary][stokesdarcy] couplingmapper does not need couplingman...2019-12-18T07:31:31ZKatharina Heck[multidomain][boundary][stokesdarcy] couplingmapper does not need couplingmanager<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
The stokesdarcy couplingmapper could be simplified and not depend on the stokesdarcy couplingmanager. Th...<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
The stokesdarcy couplingmapper could be simplified and not depend on the stokesdarcy couplingmanager. The couplingmanager is only needed to get the FVGridgeometries in one function, which seems unnecessary.
**What does this feature / why does DuMux need it**:
The dependency of the mapper on the couplingmanager create issues when trying to combine several couplingmangers. Removing that also means that the constructor of the couplingmanager can be removed, which is also nice and easier for inheritance.3.2Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/765Add pre-commit hook for generating README.md in the examples folder2020-03-16T20:45:27ZBernd 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/766Dumux handbook should contain a building date and a git-version-hashmark on t...2020-06-30T23:24:01ZDavid 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 i...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).3.3David WernerDavid Wernerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/767Nonlinear solver throws exception instead of reducing time step2019-09-24T12:47:38ZDanielNonlinear solver throws exception instead of reducing time step<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
Newtonsolver throws exception instead of taking smaller time step.
**What happened / Problem description**:
Lin...<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
Newtonsolver throws exception instead of taking smaller time step.
**What happened / Problem description**:
Linaer sovler throws exception (in line 882, nonlinear/newtonsolver.hh)
**What you expected to happen**:
Reduction of time step
**How to reproduce it (as minimally and precisely as possible)**:
**Anything else we need to know?**:
The call is in nonlinear/newtonsolver.hh, solve_ in line 882
possible fix would to replace solveLinearSystem(deltaU);
try{
solveLinearSystem(deltaU);
} catch(...) {
continue;
}
solveTimer.stop();
**Environment**:
- Dune version:
- DuMux version:
- Others:https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/768[md][cc] Dirichlet-Dirichlet coupling does not work with setCouplingDirichlet2020-03-21T21:11:49ZKilian Weishaupt[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 `setCouplin...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/769[doxygen] warnings2019-10-02T13:17:05ZBeatrix Becker[doxygen] warningsI encountered a few warnings running doxygen that I couldn't make disappear. This is the doxyerr.log file as it is produced on the branch feature/doxygen-warnings-part-1: [doxyerr.log](/uploads/b0c3ca48b8fef6a41355e9981f88a8d7/doxyerr.lo...I encountered a few warnings running doxygen that I couldn't make disappear. This is the doxyerr.log file as it is produced on the branch feature/doxygen-warnings-part-1: [doxyerr.log](/uploads/b0c3ca48b8fef6a41355e9981f88a8d7/doxyerr.log)
**Lines 1-15** were already there last time and according to @emmert they had something to do with forward declarations, but that he couldn't solve the problem either. Does anyone have an idea now? If not, we can probably live with this.
**Lines 17-30** are problems associated with staggeredcouplingmanager and **lines 32-end** problems associated with the base fluidsystem. In either cases, doxygen complains that a parameter is not in the argument list of the function, although it is. Doxygen just looks in the wrong place. For the staggeredcouplingmanager, doxygen looks at Dumux::StokesDarcyCouplingManager and for the base fluidsystem, it looks at functions in Dumux::FluidSystems::Brine, which is obviously wrong. But I don't know how to make doxygen look in the right place. This is probably an easy one... @bernd @timok any hints?3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/770[doxygen on website] Latex is not rendered correctly2020-03-16T20:47:20ZBeatrix Becker[doxygen on website] Latex is not rendered correctlyAlso there is nothing under "Description" (jump to that is possible with the "More..."-link, see [example](https://dumux.org/doxygen/master/a01972.html) and [another example](https://dumux.org/doxygen/master/a18158.html)). The locally bu...Also there is nothing under "Description" (jump to that is possible with the "More..."-link, see [example](https://dumux.org/doxygen/master/a01972.html) and [another example](https://dumux.org/doxygen/master/a18158.html)). The locally build version works however!3.2David WernerDavid Wernerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/771[grahamConvexHull] Using dim==3 causes stack overflow due to infinite recursion2019-10-02T14:58:43ZKilian Weishaupt[grahamConvexHull] Using dim==3 causes stack overflow due to infinite recursionCalling
```cpp
grahamConvexHull<3>(points);
```
Causes a stack over flow because
```cpp
template<int dim, class Points>
Points grahamConvexHull(const Points& points)
{
auto copyPoints = points;
return grahamConvexHull<dim>(c...Calling
```cpp
grahamConvexHull<3>(points);
```
Causes a stack over flow because
```cpp
template<int dim, class Points>
Points grahamConvexHull(const Points& points)
{
auto copyPoints = points;
return grahamConvexHull<dim>(copyPoints);
}
```
will call itself infinitely since there is no template specialization for dim != 2.
This should be prevented by a static_assert.3.1Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/772Implement strongly enforced (internal) Dirichlet constraints for cell-centere...2020-06-30T19:27:15ZTimo Kochtimokoch@math.uio.noImplement 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 throwing exception in the case the feature...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 throwing exception in the case the feature is enabled. 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.3.3https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/773[multidomain][stokesdarcy] convenience function for decision on molar or mass...2019-10-03T07:48:48ZKatharina Heck[multidomain][stokesdarcy] convenience function for decision on molar or mass density does not work for gcc 5.5With gcc 5.5 on my laptop the introdued convenience function (commit a49c08d48fb063d16f079bc956a0c1ff2ec3be25) in the stokesdarcy couplingdata does not seem to work.
The error I get is:
/dumux/dumux/multidomain/boundary/stokesdarcy/co...With gcc 5.5 on my laptop the introdued convenience function (commit a49c08d48fb063d16f079bc956a0c1ff2ec3be25) in the stokesdarcy couplingdata does not seem to work.
The error I get is:
/dumux/dumux/multidomain/boundary/stokesdarcy/couplingdata.hh:1098:52: error: use of ‘template<class VolumeVariables> auto Dumux::massOrMolarDensity(const VolumeVariables&, Dumux::ReferenceSystemFormulation, int)’ before deduction of ‘auto’
const Scalar rhoInside = massOrMolarDensity(volVarsI, MolecularDiffusionType::referenceSystemFormulation(), couplingPhaseIdx(domainI));
With a newer compiler version that works. @kweis: I will try to have a look at that on Friday and see if I can fix that. I think we want to support also gcc 5.5?3.1Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/774[material][3pimmiscible] Clang does not compile with DUNE_THROW in constexpr ...2019-10-04T15:22:36ZKilian Weishaupt[material][3pimmiscible] Clang does not compile with DUNE_THROW in constexpr function!1726 introduced a DUNE_THROW as default case for a switch in, e.g.,
``` cpp
static constexpr bool isGas(int phaseIdx)
```
because the compiler would rise a warning otherwise. However, clang does not allow Dune exceptions in constexpr ...!1726 introduced a DUNE_THROW as default case for a switch in, e.g.,
``` cpp
static constexpr bool isGas(int phaseIdx)
```
because the compiler would rise a warning otherwise. However, clang does not allow Dune exceptions in constexpr functions.
How should we handle this? Just return `false` per default, omitting the DUNE_THROW?3.1Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/775Example main page should contain title and abstracts2019-10-09T08:12:50ZTimo Kochtimokoch@math.uio.noExample main page should contain title and abstractsThe example main readme page does not look very inviting. I would be nice to describe the model/application with a brief title and add a brief description of the example below. Would be also good to number them in the intro page so peopl...The example main readme page does not look very inviting. I would be nice to describe the model/application with a brief title and add a brief description of the example below. Would be also good to number them in the intro page so people can refer to them as Example 1, etc.3.1Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/776Local occurrences of FV(fv)GridGeometry2019-10-11T09:39:54ZBernd FlemischLocal occurrences of FV(fv)GridGeometryAfter merging !1647, there will still be a lot of usages of the old name in private aliases and variables such as
```cpp
using FVGridGeometry = GetPropType<TypeTag, Properties::GridGeometry>;
```
We should get rid of these occurrences (u...After merging !1647, there will still be a lot of usages of the old name in private aliases and variables such as
```cpp
using FVGridGeometry = GetPropType<TypeTag, Properties::GridGeometry>;
```
We should get rid of these occurrences (unless they are appropriate).3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/777get rid of remaining `FV`s in names with `FVGridGeometry`2020-01-29T09:51:02ZBernd Flemischget rid of remaining `FV`s in names with `FVGridGeometry`There's several occurrences of names containing `FVGridGeometry`, for example:
* [x] the property `EnableFVGridGeometryCache`
* [x] ~~several implementing classes `CCMpfaFVGridGeometry`, `CellCenterFVGridGeometry`...~~
* [ ] lots of loca...There's several occurrences of names containing `FVGridGeometry`, for example:
* [x] the property `EnableFVGridGeometryCache`
* [x] ~~several implementing classes `CCMpfaFVGridGeometry`, `CellCenterFVGridGeometry`...~~
* [ ] lots of local variables `bulkFvGridGeometry`, `stokesFvGridGeometry`...Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/778[gridmanager] ALUGrid with dim != dimWorld does not compile2019-10-25T08:33:33ZKilian Weishaupt[gridmanager] ALUGrid with dim != dimWorld does not compileALUGrid's structured grid factory internally uses YASPGrid which cannot handle dim != dimWorld.
Code does therefore not compile.
We could provide an overload of `makeStructuredGrid` which DUNE_THROWS at runtime for dim != dimWorld.
Sho...ALUGrid's structured grid factory internally uses YASPGrid which cannot handle dim != dimWorld.
Code does therefore not compile.
We could provide an overload of `makeStructuredGrid` which DUNE_THROWS at runtime for dim != dimWorld.
Should this be put in the base grid manager?
Do all grids (w.r.t. the structured grid factory) suffer from this?3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/779[staggered] Rename fvGridGeometry to gridGeometry2019-10-30T09:08:14ZKilian Weishaupt[staggered] Rename fvGridGeometry to gridGeometry- [ ] rename and deprecate header
- [ ] rename and deprecate member functions- [ ] rename and deprecate header
- [ ] rename and deprecate member functions3.2Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/780Release 3.1 requires DUNE > 2.6.02019-12-02T17:55:28ZMarkus BlattRelease 3.1 requires DUNE > 2.6.0Congratulations to the 3.1 release.
As a release manager of OPM I wanted to test how OPM works together with DUMUX. Somehow I interpreted the website that DUMUX 3.1 should work with DUNE 2.6 also. Unfortunately, that is not the case sinc...Congratulations to the 3.1 release.
As a release manager of OPM I wanted to test how OPM works together with DUMUX. Somehow I interpreted the website that DUMUX 3.1 should work with DUNE 2.6 also. Unfortunately, that is not the case since (some) of your Cmake code for tests relies on functionality not yet available in stable DUNE releases. With 2.6 on Debian 10 I get the error:
```
CMake Error at /usr/share/dune/cmake/modules/DuneTestMacros.cmake:201 (message):
Cannot deduce test name from multiple sources!
Call Stack (most recent call first):
test/common/geometry/CMakeLists.txt:1 (dune_add_test)
-- Configuring incomplete, errors occurred!
```
(LABELS for dune_add_test seem to have been introduced after DUNE 2.6.0)
Not sure whether this is a bug feature. If it is the latter, it would be nice to indicate the requirement on DUNE master more clearly, e.g. in https://dumux.org/installation.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/781Release 3.1/Dune 2.6 compile errors.2019-12-02T17:55:41ZMarkus BlattRelease 3.1/Dune 2.6 compile errors.Using g++ 8.3.0 on Debian 10 I get:
```
[ 0%] Building CXX object test/common/CMakeFiles/test_partial.dir/test_partial.cc.o
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc: In function ‘int main(int, char**)’:
/home/mbla...Using g++ 8.3.0 on Debian 10 I get:
```
[ 0%] Building CXX object test/common/CMakeFiles/test_partial.dir/test_partial.cc.o
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc: In function ‘int main(int, char**)’:
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:55:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
int main(int argc, char* argv[]) try
~~~~^~~~
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:55:26: warning: unused parameter ‘argv’ [-Wunused-parameter]
int main(int argc, char* argv[]) try
~~~~~~^~~~~~
In file included from /home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:14:
/home/mblatt/src/dune/opm-2.6/dumux/dumux/common/partial.hh: In instantiation of ‘auto Dumux::partial(Dune::MultiTypeBlockVector<Args ...>&, Dune::index_constant<i>...) [with Ar
gs = {Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::Field
Vector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 3>, std::allocator<Dune::FieldVector<double, 3> > >}; long unsigned int ...i = {0, 2}]’:
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:41:21: required from ‘void Dumux::runTest() [with T = Dune::MultiTypeBlockVector]’
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:59:41: required from here
/home/mblatt/src/dune/opm-2.6/dumux/dumux/common/partial.hh:42:18: error: no matching function for call to ‘Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >&, Dune::BlockVector<Dune::FieldVector<double, 3>, std::allocator<Dune::FieldVector<double, 3> > >&>::MultiTypeBlockVector(std::tuple_element<0, std::tuple<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 3>, std::allocator<Dune::FieldVector<double, 3> > > > >::type&, std::tuple_element<0, std::tuple<Dune::BlockVector<Dune::FieldVector<double, 3>, std::allocator<Dune::FieldVector<double, 3> > > > >::type&)’
return Dune::MultiTypeBlockVector<std::add_lvalue_reference_t<std::decay_t<std::tuple_element_t<indices, std::tuple<Args...>>>>...>(v[indices]...);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:12:
/usr/include/dune/istl/multitypeblockvector.hh:53:9: note: candidate: ‘constexpr Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >&, Dune::BlockVector<Dune::FieldVector<double, 3>, std::allocator<Dune::FieldVector<double, 3> > >&>::MultiTypeBlockVector(const Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >&, Dune::BlockVector<Dune::FieldVector<double, 3>, std::allocator<Dune::FieldVector<double, 3> > >&>&)’
class MultiTypeBlockVector
^~~~~~~~~~~~~~~~~~~~
/usr/include/dune/istl/multitypeblockvector.hh:53:9: note: candidate expects 1 argument, 2 provided
/usr/include/dune/istl/multitypeblockvector.hh:53:9: note: candidate: ‘constexpr Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >&, Dune::BlockVector<Dune::FieldVector<double, 3>, std::allocator<Dune::FieldVector<double, 3> > >&>::MultiTypeBlockVector(Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >&, Dune::BlockVector<Dune::FieldVector<double, 3>, std::allocator<Dune::FieldVector<double, 3> > >&>&&)’
/usr/include/dune/istl/multitypeblockvector.hh:53:9: note: candidate expects 1 argument, 2 provided
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc: In instantiation of ‘void Dumux::runTest() [with T = Dune::MultiTypeBlockVector]’:
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:59:41: required from here
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:41:10: error: ‘void p’ has incomplete type
auto p = partial(m, _0, _2);
^
In file included from /home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:14:
/home/mblatt/src/dune/opm-2.6/dumux/dumux/common/partial.hh: In instantiation of ‘auto Dumux::partial(T&, std::tuple<Dune::index_constant<i>...>) [with T = Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 3>, std::allocator<Dune::FieldVector<double, 3> > > >; long unsigned int ...i = {0, 2}]’:
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:42:16: required from ‘void Dumux::runTest() [with T = Dune::MultiTypeBlockVector]’
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:59:41: required from here
/home/mblatt/src/dune/opm-2.6/dumux/dumux/common/partial.hh:62:59: warning: unused parameter ‘indices’ [-Wunused-parameter]
auto partial(T& t, std::tuple<Dune::index_constant<i>...> indices)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
/home/mblatt/src/dune/opm-2.6/dumux/dumux/common/partial.hh: In instantiation of ‘auto Dumux::partial(T&, std::tuple<Dune::index_constant<i>...>) [with T = std::tuple<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 3>, std::allocator<Dune::FieldVector<double, 3> > > >; long unsigned int ...i = {0, 2}]’:
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:42:16: required from ‘void Dumux::runTest() [with T = std::tuple]’
/home/mblatt/src/dune/opm-2.6/dumux/test/common/test_partial.cc:60:25: required from here
/home/mblatt/src/dune/opm-2.6/dumux/dumux/common/partial.hh:62:59: warning: unused parameter ‘indices’ [-Wunused-parameter]
make[3]: *** [test/common/CMakeFiles/test_partial.dir/build.make:63: test/common/CMakeFiles/test_partial.dir/test_partial.cc.o] Fehler 1
make[2]: *** [CMakeFiles/Makefile2:4727: test/common/CMakeFiles/test_partial.dir/all] Fehler 2
make[1]: *** [CMakeFiles/Makefile2:1546: CMakeFiles/build_tests.dir/rule] Fehler 2
make: *** [Makefile:652: build_tests] Fehler 2
```Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/782The velocity output from the 1p tracer example is halved on the top and botto...2019-11-20T10:05:40ZPowei HuangThe velocity output from the 1p tracer example is halved on the top and bottom boundaries.<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
The velocity output from the 1p tracer example is halved on the top and bottom boundaries.
**What happened / Pro...<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
The velocity output from the 1p tracer example is halved on the top and bottom boundaries.
**What happened / Problem description**:
This problem occurred when I ran the tracer problems. They are located in
dumux/examples/1ptracer
dumux/test/porousmediumflow/tracer/1ptracer
The velocity output using the vtk output module will result in a halved velocity on the top and bottom boundaries. The file name is tracer.pvd. This issue can be seen easily when setting a constant permeability throughout the domain.
**What you expected to happen**:
When the problem has top and bottom Dirichlet boundary conditions for pressure and constant permeability, the velocity field should be constant in space.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/783[test] test_ff_stokes_channel_neumann_x_dirichlet_y sometimes fails2019-11-12T13:42:57ZTimo Kochtimokoch@math.uio.no[test] test_ff_stokes_channel_neumann_x_dirichlet_y sometimes failswith the following error:
```
Fuzzy comparison...
Traceback (most recent call last):
File "/data/src/dumux/bin/testing/runtest.py", line 63, in
result = compare_vtk(args['files'][i*2], args['files'][(i*2)+1], relative=args['re...with the following error:
```
Fuzzy comparison...
Traceback (most recent call last):
File "/data/src/dumux/bin/testing/runtest.py", line 63, in
result = compare_vtk(args['files'][i*2], args['files'][(i*2)+1], relative=args['relative'], absolute=args['absolute'], zeroValueThreshold=args['zeroThreshold'])
File "/data/src/dumux/bin/testing/fuzzycomparevtu.py", line 52, in compare_vtk
root2 = ET.fromstring(open(vtk2).read())
File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1312, in XML
return parser.close()
File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1671, in close
self._raiseerror(v)
File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1523, in _raiseerror
raise err
xml.etree.ElementTree.ParseError: no element found: line 466, column 16
Test #11: test_ff_stokes_channel_neumann_x_dirichlet_y ............***Failed 5.80 sec
```
there seems to be something wrong with the vtu.3.1Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/784[test] Implement outflow BC for 1p tracer test2019-12-20T12:29:26ZSimon 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 f...<!--
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.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/785[handbook][parallel] Mention that the AMG only works properly with direct coa...2019-12-17T14:30:40ZTimo Kochtimokoch@math.uio.no[handbook][parallel] Mention that the AMG only works properly with direct coarse grid solver3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/7862p incompressible box test doesn't work in parallel2019-11-13T16:47:45ZBernd Flemisch2p incompressible box test doesn't work in parallelThe Newton solver doesn't converge when running on two processes.The Newton solver doesn't converge when running on two processes.3.2Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/787New example for rotation symmetric problem2020-04-23T10:49:03ZTimo Kochtimokoch@math.uio.noNew 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 w...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/788Variable Permeability and coupling free-flow-porous-media problems2020-09-30T08:26:55ZJohannes 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 dependi...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.3.3Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/789[shallowwater] Add new friction law `noFriciton`2019-12-16T14:56:59ZMartin Utz[shallowwater] Add new friction law `noFriciton`The friciton laws are not defined for `frictionValue` == 0.
Therefore it is needed to implement an own friciton law covering this case.The friciton laws are not defined for `frictionValue` == 0.
Therefore it is needed to implement an own friciton law covering this case.Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/790[shallowwater] Make the borders of the LET limiting changeable2019-12-20T12:23:45ZMartin Utz[shallowwater] Make the borders of the LET limiting changeableThe LET limiting is used to limit the flux for small water depth. The limiting starts if the `waterDepth` is lower than `upperH`. The second border is `lowerH`. For all `waterDepth` lower than `lowerH` the flux is set to zero.
Currently...The LET limiting is used to limit the flux for small water depth. The limiting starts if the `waterDepth` is lower than `upperH`. The second border is `lowerH`. For all `waterDepth` lower than `lowerH` the flux is set to zero.
Currently the borders are hard coded. This should be changed. Instead they should be changeable via the `params.input` file.
Also the names of the borders should be changed to be better understandable.Martin UtzMartin Utzhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/791[shallowwater] fix bug in roughchannel test2019-12-20T13:16:32ZLeopold Stadler[shallowwater] fix bug in roughchannel testThe outflow boundary is set to 100 meters instead to 500 meters. There might be further problems.The outflow boundary is set to 100 meters instead to 500 meters. There might be further problems.Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/792MultiDomain does not work for solution-dependent spatial params in instationa...2024-03-25T10:26:16ZDennis GläserMultiDomain does not work for solution-dependent spatial params in instationary problemsThis issue is related to #619, #703 and #788.
**What happened / Problem description**:
If a spatial param, e.g. porosity, depends on the solution of another domain (for example deformation-dependent porosities in poroelastic models), ...This issue is related to #619, #703 and #788.
**What happened / Problem description**:
If a spatial param, e.g. porosity, depends on the solution of another domain (for example deformation-dependent porosities in poroelastic models), there is currently no way to evaluate it on the correct time level during the creation of the previous volume variables. This causes the Newton solver to fail even for simple problems. A local (hacky) bugfix showed that good convergence is obtained when this is fixed.
This means that currently the Geomechanics module cannot be used for time-dependent problems in which deformation-dependent porosities are used, which is a standard capability.
A similar problem is reported in #703, where time-dependent spatial saturation distributions are needed.
Since several issues are related to this, an idea was to think about a more general way of handling time discretization schemes and hopefully fix all three issues at once.
One idea was to have a local view on the spatial parameters as well, and change all __bind__ functions such that they not only bind to an element but also to a time level somehow.X.Xhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/793[examples] Allow to exclude/fold code in the example README.md2020-01-29T16:08:01ZTimo Kochtimokoch@math.uio.no[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]...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]
```
Related MRs: !1682 3.2Melanie LippMelanie Lipphttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/794[homepage] Update Dumux homepage2020-02-04T15:33:06ZAlexander Jaust[homepage] Update Dumux homepageHi guys,
I did not find any repository that explicitly points to the homepage so I will add this here.
- When checking on "How to cite DuMuX" I realized that the information still points to an old version of DuMuX (3.0.0 on Zenodo). Mo...Hi guys,
I did not find any repository that explicitly points to the homepage so I will add this here.
- When checking on "How to cite DuMuX" I realized that the information still points to an old version of DuMuX (3.0.0 on Zenodo). Moreover, I saw a preprint sometimes for a new (?) DuMuX paper? Will this be added once it is published or why is it not there? Therefore I would propose to add "Update `How to cite` section on homepage" to your checklist when releasing a new DuMuX version.
- The link (https://dumux.org/install) to the tarball of DuMux on https://dumux.org/modules#dumux is broken.
Optional changes I would like:
- Give me a BibTex file with the reference that I can download from your homepage or link to somwhere where I can get it easily. I want to cite you properly, but I am lazy. From the Zenodo homepage I can download the reference in BibTex format, but for the paper I had to use google since the link does not point to the published version of the paper.
Thanks!
Best,
Alexhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/795[tabulation] Generalize tabulation and interpolation2023-12-13T11:13:09ZBeatrix 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 toohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/796[tabulation] adaptive linear tables2023-12-13T11:13:09ZBeatrix 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.
See also #795Tabulation 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.
See also #795https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/800[shallowwater] upwind mobility for shallow water flux.2020-03-18T20:57:46ZLeopold 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 an...<!--
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.3.2Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/801[Box] variable switch at boundary2020-03-04T14:33:51ZMartin 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 initi...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 Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/802Lookup of parameters in LoggingParameterTree seems inconsistent.2020-01-27T16:51:56ZMarkus BlattLookup of parameters in LoggingParameterTree seems inconsistent.There might be reason for it, but that is not obvious to me.
- `hasKeyInGroup` with an empty groupPrefix will neglect `defaultParameters_` as it returns `hasKey(key)` (which only searches in `params_`
- `hasKeyInGroup` with a nonempty g...There might be reason for it, but that is not obvious to me.
- `hasKeyInGroup` with an empty groupPrefix will neglect `defaultParameters_` as it returns `hasKey(key)` (which only searches in `params_`
- `hasKeyInGroup` with a nonempty groupPrefix will search also `defaultParameters_` but only in group groupPrefix. When searching
the parent groups it will not.
What behavior is intended here exactly?3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/803AMG/parallel solver modifies matrix2020-02-01T13:48:31ZTimo Kochtimokoch@math.uio.noAMG/parallel solver modifies matrixWe currently pass an assembled matrix into the linear solver. However, the interface requires passing a non-const matrix. This is because the linear solver actually modifies the matrix pattern depending on the parallel communication stra...We currently pass an assembled matrix into the linear solver. However, the interface requires passing a non-const matrix. This is because the linear solver actually modifies the matrix pattern depending on the parallel communication strategy.
In my opinion that's not a good implementation. The matrix should be already assembled with the right pattern. And, the preparation of the matrix for the linear solver should be part of the assembler not the solver.
The question is if these modification depend on the specific solver/preconditioner combination or just on the chosen communication strategy and discretization scheme (independent of the solver)? If the latter is the case, we should definitely consider moving the pattern modification to the assembler.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/804[staggered] Matrix block arrangement does not comply with literature standard2020-03-31T11:18:09ZKilian Weishaupt[staggered] Matrix block arrangement does not comply with literature standardPapers dealing with solvers for saddlepoint problems (like the incompressible Navier-Stokes equations, [example](https://epubs.siam.org/doi/abs/10.1137/16M1076770)) usually define the block matrix as
```math
M = \begin{pmatrix}
A & B...Papers dealing with solvers for saddlepoint problems (like the incompressible Navier-Stokes equations, [example](https://epubs.siam.org/doi/abs/10.1137/16M1076770)) usually define the block matrix as
```math
M = \begin{pmatrix}
A & B^T\\
B & C
\end{pmatrix}
```
where $`A`$ is the block for the derivatives of the momentum balance equation residuals w.r.t velocity ("velocity block")
and $`C`$ is is the block for the derivatives of the mass balance equation residuals w.r.t pressure ("pressure block").
For incompressible fluids, $`C`$ is zero.
However, the multitype blockmatrix in Dumux for staggered problems looks like this:
```math
M = \begin{pmatrix}
C & B^T\\
B & A
\end{pmatrix}
```
which causes confusion and requires special care, e.g, for the implementation of the Uzawa solver !1827
I suggest we adapt the matrix structure such that the velocity block is on the upper left. Are there any concerns / objections?3.2Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/805Cleanup and restructure parallel solver helpers2020-02-14T12:55:05ZTimo Kochtimokoch@math.uio.noCleanup and restructure parallel solver helpersThe following discussion from !1839 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1839#note_32398): (+2 comments)
> @blattms Do I see it right tha...The following discussion from !1839 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1839#note_32398): (+2 comments)
> @blattms Do I see it right that all solver use the same parallel setup as the AMG? So amgtraits.hh and amgparallelhelpers.hh are not specific to AMG? Then we could just rename the headers and AMGTraits->ParallelSolverTraits so it's less confusing.
* [x] Move amgparallelhelpers.hh to paralellhelpers.hh or similar -> fixed in !1848
* [x] AmgTraits -> LinearSolverTraits? -> fixed in !1848
* [ ] LinearAlgebraTraits?
* [x] Merge linear/vectorexchange.hh and parallel/vertexhandles.hh -> fixed in !18483.2Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/806Follow-up from "Added first version of generic factory using istl solver fact...2020-01-29T18:47:53ZTimo Kochtimokoch@math.uio.noFollow-up from "Added first version of generic factory using istl solver factory."The following discussion from !1839 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1839#note_32258): (+1 comment)
> New classes in Dumux can't have...The following discussion from !1839 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1839#note_32258): (+1 comment)
> New classes in Dumux can't have TypeTag anymore. Exceptions are some convenience aliases or structs to bridge the time until a TypeTag dependency is fully resolved. We maybe could have
>
> ```c++
>
> template <class Matrix, class Vector, class GridGeometry>
> struct SolverTraits
> {
> using AmgTraits = Dumux::AmgTraits<Matrix, Vector, GridGeometry>;
> };
>
> template <class GridView, class SolverTraits>
> class GenericIstlSolverFactoryBackend : public LinearSolver
> {...};
>
>
> template<class TypeTag>
> using IstlSolverFactoryBackend = GenericIstlSolverFactoryBackend<Property stuff like for AMGBackend>
>
>
> ```3.2Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/807[RANS] Evaluate possibility to chose turbulence model at runtime2023-09-27T08:51:41ZKilian Weishaupt[RANS] Evaluate possibility to chose turbulence model at runtimeCurrently, we have a myriad of different RANS models (zeroeq, oneeq, twoeq-kepsilon, twoeq-komega, twoeq-lowrekepsilon).
Maybe we could choose the turbulence model (at least for the two-eq models) at runtime.
This would decrease the nu...Currently, we have a myriad of different RANS models (zeroeq, oneeq, twoeq-kepsilon, twoeq-komega, twoeq-lowrekepsilon).
Maybe we could choose the turbulence model (at least for the two-eq models) at runtime.
This would decrease the number of executables for the tests and maybe also decrease the effort to add new turbulence models.3.9Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/808Free function scaleLinearSystem unused2020-03-20T11:17:59ZTimo Kochtimokoch@math.uio.noFree function scaleLinearSystem unusedWe have a free function in the amgbackend: `scaleLinearSystem` that is currently not used anywhere.
We should maybe use it somewhere and put it in its own header.
Find a case where it's useful. If not deprecate and delete.We have a free function in the amgbackend: `scaleLinearSystem` that is currently not used anywhere.
We should maybe use it somewhere and put it in its own header.
Find a case where it's useful. If not deprecate and delete.3.2Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/809Upwind weight cannot selectively chosen for different models2020-01-29T12:43:10ZTimo Kochtimokoch@math.uio.noUpwind weight cannot selectively chosen for different modelshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/810Get rid of global defaults for Linear solver2020-03-13T15:11:18ZTimo Kochtimokoch@math.uio.noGet rid of global defaults for Linear solverDefault should be set in the solver itself.Default should be set in the solver itself.3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/811Examples: Try to achieve more coherent text and code blocks2020-04-03T10:00:57ZTimo Kochtimokoch@math.uio.noExamples: Try to achieve more coherent text and code blocksI find the examples difficult to read because there is often a constant change of formatting between text and code.
Wouldn't it be easier to read if, for example, member functions are always one code block and the text above describes t...I find the examples difficult to read because there is often a constant change of formatting between text and code.
Wouldn't it be easier to read if, for example, member functions are always one code block and the text above describes the whole function at once? I think it is easy to get which step does what part of the description. Probably even easier to get than now.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/812[parallel] Load balancing for UG with PTScotch2022-04-18T11:53:27ZTimo Kochtimokoch@math.uio.no[parallel] Load balancing for UG with PTScotchThere is a helper in Dune that shows how to load balance a UGGrid with ParMETIS at https://gitlab.dune-project.org/core/dune-grid/blob/master/dune/grid/utility/parmetisgridpartitioner.hh
Background is that the native load balancer in UG...There is a helper in Dune that shows how to load balance a UGGrid with ParMETIS at https://gitlab.dune-project.org/core/dune-grid/blob/master/dune/grid/utility/parmetisgridpartitioner.hh
Background is that the native load balancer in UGGrid seems to produce quite bad partitions. AluGrid's partitions are based on ZOLTAN/ParMETIS/Scotch and seem to be much better.
Since ParMETIS has a weird license (education-only), it would be be nice to have the same feature using (PT)Scotch which is (licensed under CeCILL - compatible with GNU GPL). Scotch offers similar capabilities and we already have a scotch backend for matrix reordering.3.5Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/813[test] Unit test for VanGenuchten / Brooks-Corey material laws missing2020-03-31T09:31:36ZTimo Kochtimokoch@math.uio.no[test] Unit test for VanGenuchten / Brooks-Corey material laws missingWe should test (for raw and regularized version):
* if derivatives match numerical derivatives
* unregularized same as regularized in the non-regularized range
* endPointPc() is the same as evaluation at Sw=1
* entryPressure is the same...We should test (for raw and regularized version):
* if derivatives match numerical derivatives
* unregularized same as regularized in the non-regularized range
* endPointPc() is the same as evaluation at Sw=1
* entryPressure is the same as evaluation at Sw=1
* test against some precomputed reference values (a good regression test)
* test eff to abs law
add more invariants that could be unit tested if you have an idea.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/814Extract "constraint solvers" from volume variables2023-02-22T09:00:40ZTimo Kochtimokoch@math.uio.noExtract "constraint solvers" from volume variablesThe computation of the secondary variables from the primary variables is currently often coded inside the volume variables' `update` function. For the purpose of potential code reusage, readability, and testability it is IMO better to mo...The computation of the secondary variables from the primary variables is currently often coded inside the volume variables' `update` function. For the purpose of potential code reusage, readability, and testability it is IMO better to move this functionality to constraint solver classes. Even if the computation is quite simple. This is sometimes done in the form of the `computeFluidState` function. However, there is no general interface for all models.
If the constraint solver is in a separate class it is much easier to write unit tests. Volume variables have a lot of dependencies but the constraint solver can easily be tested and mock object are simple to construct for values obtained from e.g. the spatial params or some physical law.Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/815New folder "properties"2020-03-03T16:34:17ZTimo Kochtimokoch@math.uio.noNew folder "properties"For the sake if isolating the property system and making it easier to find stuff in Dumux, I believe it might be helpful to create a new top level folder `properties` that contains
```
properties
|- properties.hh
|- propertysystem.hh
|-...For the sake if isolating the property system and making it easier to find stuff in Dumux, I believe it might be helpful to create a new top level folder `properties` that contains
```
properties
|- properties.hh
|- propertysystem.hh
|- base.hh
|- grid.hh
|- discretization
|- box.hh
|- cctpfa.hh
...
```
i.e. all files that are concerned with setting basic properties. The question is what to do with the `model.hh` headers but I suggest that they remain part of the respective model folder, and only the "base"-property headers are separately structured.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/816Do not use term "handle" in mpfa2023-02-22T08:54:35ZDennis GläserDo not use term "handle" in mpfaThe term `DataHandle` used in mpfa should be replaced as it actually stores the data.The term `DataHandle` used in mpfa should be replaced as it actually stores the data.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/817[parallel] Convergence problems for parallel linear solvers2020-02-13T14:01:45ZLeopold Stadler[parallel] Convergence problems for parallel linear solvers<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
The linear solver (e.g. BiCGSTAB with SSOR) has problems when cell-centered methods are applied for non-linear s...<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
The linear solver (e.g. BiCGSTAB with SSOR) has problems when cell-centered methods are applied for non-linear systems on complex domains.
**What happened / Problem description**
The linear solver has problems when solving the shallow water equations on grids with a complex geometry (non-rectangular domains). The problem often only converges if one iteration for the preconditioner is applied.
**What you expected to happen**:
The linear solver should also converge if no/more than one iteration is applied.
**How to reproduce it (as minimally and precisely as possible)**:
I will create an example for the shallow water equations to discuss the problem.
**Anything else we need to know?**:
I couldn't locate the problem, maybe it would be also good idea test the linear solver for a simple linear equation.
**Environment**:
- Dune version: master and dune-istl feature/parallel-solver-factory
- DuMux version: feature/richards-istl-factory
- Others:Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/818Backwards compatibility2020-03-26T13:56:40ZTimo Kochtimokoch@math.uio.noBackwards compatibilityThis is an issue to discuss backwards-compatibility models. Suggestions could be for example (maybe someone knows about a cool model from somewhere)
* No backwards-compatibilty, only deprecate if feasible/simple -> required good changel...This is an issue to discuss backwards-compatibility models. Suggestions could be for example (maybe someone knows about a cool model from somewhere)
* No backwards-compatibilty, only deprecate if feasible/simple -> required good changelog+descriptions+commit history+error messages
* Partial backwards-compatibilty: declare some classes as essential and others as implementation detail
* Full backwards-compatibility until next minor release
The background is that
1. keeping the code backwards compatible is a huge effort for the core developers, work time (and thus also money) they cannot spend on research and other important stuff.
2. It makes more radical design decisions difficult which results in the opposite of agile development. I consider this essential for a research tool to quickly adapt to new situation that have not been foreseen (of course it's always better to do some design decisions right in the first place but that's not always possible).
3. We have the problem in DuMux as a research code that basically all classes and functions are in the public interface. Almost every component can be swapped out for a custom implementations (which is one of the strengths of Dumux as a research framework). If you wanted to define the DuMux API it would be just everything we have. However, this means that all classes and functions always have to be altered in a backwards-compatible manner.
Maybe there are some awesome tricks that I don't know, but I find it sometimes extremely hard to find a backwards-compatible solution and find it difficult to find good experience on the topic online. (Maybe noone does it!?)
Of course on the other hand, backwards-compatibility is an extremely useful thing for all users. You can usually update to a new version and get clear instructions how to change your code but your code doesn't break. In an ideal world, we would always want to keep everything backwards-compatible as long as possible.
Opinions & arguments?
I didn't find any good resources online on backwards-compatibility that seems to apply to the situation of research code. Any pointer is greatly appreciated. AFAIK FEniCS relies on a mixture of good changelog and backwards-compatibility where feasible without being mandatory.3.2Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/819Add parallel test with unstructured grid2020-03-17T21:13:31ZTimo Kochtimokoch@math.uio.noAdd parallel test with unstructured grid* We need a parallel test with an unstructured grid.
* Moreover, we adjust the Richards test or add a new test in a way the there is actually significant fluxes over the process boundary.
See also #817 and fix !1862 which wasn't caught ...* We need a parallel test with an unstructured grid.
* Moreover, we adjust the Richards test or add a new test in a way the there is actually significant fluxes over the process boundary.
See also #817 and fix !1862 which wasn't caught by the current test suite.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/820Failing tests after change of VanGenuchten Law2020-03-24T09:36:27ZKilian WeishauptFailing tests after change of VanGenuchten Law3fff0a215373e66b081ea544b7e37ef277ee082a introduces some changes to the VanGenuchten Law.
Several reference solutions were updated afterwards but on my system,
* test_md_boundary_darcy2p2cni_stokes1p2cni_horizontal
and
* test_2p_in...3fff0a215373e66b081ea544b7e37ef277ee082a introduces some changes to the VanGenuchten Law.
Several reference solutions were updated afterwards but on my system,
* test_md_boundary_darcy2p2cni_stokes1p2cni_horizontal
and
* test_2p_incompressible_box_ifsolver
still fail (while passing on buildbot). Could somebody else try those tests?3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/821GCC 7.2 fails to compile test (master)2020-02-26T13:36:56ZLeopold StadlerGCC 7.2 fails to compile test (master)GCC 7.2 fails to compile on the master branch.
It looks like it is a **GCC internal error bug** and not a bug/error in DuMux. On our system, gcc (GCC) 7.2.0 works for f7efc3ee and fails fails when compiling `test_shallowwater_dambreak`...GCC 7.2 fails to compile on the master branch.
It looks like it is a **GCC internal error bug** and not a bug/error in DuMux. On our system, gcc (GCC) 7.2.0 works for f7efc3ee and fails fails when compiling `test_shallowwater_dambreak` for 6f24254d with the following message:
```
../dumux/dumux/linear/parallelhelpers.hh:735:31: interner Compiler-Fehler: in unify, bei cp/pt.c:20522
MatrixPatternExchange datahandle(mapper_, idToIndex_, indexToID_, A, sparsity, isGhost);
```
Not sure if other versions of GCC are also affected.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/822C++17 compiler difficulties2021-06-07T12:48:48ZTimo Kochtimokoch@math.uio.noC++17 compiler difficultiesThis issue is to collect some difficulties with C++17 compiler support. We currently state that we support GCC 7 and Clang 5 or newer. In case many bugs are found in earlier compiler releases, we might need to request a specific bug fix ...This issue is to collect some difficulties with C++17 compiler support. We currently state that we support GCC 7 and Clang 5 or newer. In case many bugs are found in earlier compiler releases, we might need to request a specific bug fix release, e.g. GCC 7.4 instead of 7 in general, in the future.
Please only list confirmed cases here and add a comment with a short description.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/823Extractmoduleparts does not work properly2020-03-04T12:45:55ZBeatrix BeckerExtractmoduleparts does not work properlyWhen I tried it today, the script specified "dune" and "src" as folders in the topmost CMakeLists file, but it did not create these folders. On the other hand, in the topmost CMakeLists file, the folders that contained my executables wer...When I tried it today, the script specified "dune" and "src" as folders in the topmost CMakeLists file, but it did not create these folders. On the other hand, in the topmost CMakeLists file, the folders that contained my executables were missing (e.g., "test", "appl"). Everything else was there.
Also, it would be cool if the reference files were copied as well. Should be possible, shouldn't it?Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/824[doc] Automate examples doc creation2020-03-17T08:08:07ZTimo Kochtimokoch@math.uio.no[doc] Automate examples doc creationThe example READMEs currently have to be created with the `bin/merge_cpp_and_md.sh` script AFAIK.
To execute the script you need to correct files and the correct file order. However I couldn't find the specific command for each example b...The example READMEs currently have to be created with the `bin/merge_cpp_and_md.sh` script AFAIK.
To execute the script you need to correct files and the correct file order. However I couldn't find the specific command for each example being documented anywhere.
Maybe we could create something like a `.doc_config` that lists this information for each example?
Then it would be also easy to create a script that builds all examples docs3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/825Linear Solver parameter names2020-03-17T11:06:13ZTimo Kochtimokoch@math.uio.noLinear Solver parameter namesWith !1845, we introduce many new parameter option for linear solvers if the istl solver factory is used. The preconditioner parameters are specified in the subgroup `LinearSolver.Preconditioner`. For compatibility, the "old" preconditio...With !1845, we introduce many new parameter option for linear solvers if the istl solver factory is used. The preconditioner parameters are specified in the subgroup `LinearSolver.Preconditioner`. For compatibility, the "old" preconditioner parameters are also accepted. I would be in favour of using the subgroup style also in the specialized solver backends.
We would need a deprecation strategy.3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/826Diffusion confusion (implementation)2024-03-25T10:24:47ZTimo Kochtimokoch@math.uio.noDiffusion confusion (implementation)We decided at some point that diffusion laws, e.g. `FicksLaw`, should compute all component fluxes in one go. This means two things
* we can now more efficiently compute the diffusive fluxes depending on the law (Fick / Maxwell-Stefan)
...We decided at some point that diffusion laws, e.g. `FicksLaw`, should compute all component fluxes in one go. This means two things
* we can now more efficiently compute the diffusive fluxes depending on the law (Fick / Maxwell-Stefan)
* `FicksLaw` now depends on the equation system
__Example:__
1. If I want to neglect diffusion in one phase, i can set the diffusion coefficient to zero. However, then the diffusive fluxes are still computed and I can throw them away in the custom local residual.
2. The Richards model is an immiscible two-phase two-component model but the air phase is never balanced. To integrate this in the current framework, we introduced `BalanceEqOpts::mainComponentIsBalanced(phaseIdx)` which is overloaded for the Richards model and used in Fick's law. In this case the dependency is actually there in the code in form of the additional dependency on `BalanceEqOpts`.
__One thought for a possible solution:__
If we would have a class `DiffusionFlux` replacing the current `FicksLaw`, then we could have a custom implementation `RichardsDiffusionFlux` which takes care of special requirements. `DiffusionFlux` would be a class on the level of `LocalResidual` only containing physics/equations. Internally it could use something like `FicksLaw` (new implementation that only contains the transmissibility part and discretization specifics) to compute the actual individual fluxes. `DiffusionFlux` may need to be specialized on the Law type (Fick / Maxwell-Stefan) but not the discretization.
Maybe, this would essentially be a code renaming / reordering. But that needs to be further investigated.X.Xhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/827Dune 2.6 and Dune 2.7 compatible with dumux 3.2?2020-05-04T15:56:23ZNed ColtmanDune 2.6 and Dune 2.7 compatible with dumux 3.2?For the 3.2 release, we want to be dependent on dune 2.7, correct?
This should be mentioned in:
* change log with reasons why.
* all install scripts
* website under installation instructions
TODOs
* [x] After release 3.2 add note...For the 3.2 release, we want to be dependent on dune 2.7, correct?
This should be mentioned in:
* change log with reasons why.
* all install scripts
* website under installation instructions
TODOs
* [x] After release 3.2 add note to the change log that 2.12 is no longer supported and
* [x] Write email to users about above.
* [x] After release 3.2 increase dependency to Dune 2.7
Current proposal for the testing plan during and after release 3.2 (as soon as a release branch is created)
| Dune version --> | 2.5 | 2.6 | 2.7 | master |
| ------ | ------ | ------ | ------ |------ |
| Dumux master | | | x | x |
| Dumux 3 (latest release 3.2) | | x | x | |
| ~~Dumux 2 (latest release 2.12)~~ | | | | |3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/828Diffusion coefficient storage memory requirements2020-04-09T09:19:23ZTimo Kochtimokoch@math.uio.noDiffusion coefficient storage memory requirementsAfter !1684 is merged, we will have unified diffusion container storage which is communicated between the diffusion laws and the volume variables. However I believe that the memory requirements are significantly with !1684 increased beca...After !1684 is merged, we will have unified diffusion container storage which is communicated between the diffusion laws and the volume variables. However I believe that the memory requirements are significantly with !1684 increased because both binary and effective diffusion coefficients are stored.
Evaluate if it's possible to get rid of the diffusion coefficient interface in the volume variables. They should be only called by the effective laws (but I might be wrong). If this is the case then passing the free diffusion coefficient to the effective laws would be a possible solution.
Note: although !1684 is not merged yet at the writing of this issue I believe it will be simpler to not add additional feature request to this branch at the moment because it's already very difficult to review due to it's large number of changes.3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/829Dumux Release 3.22020-05-04T15:24:30ZNed ColtmanDumux Release 3.2__Hard Feature Freeze__ : This means any further changes should be backported to the release branch. [(releases/3.2)](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/releases/3.2)
__To be addressed directly during relea...__Hard Feature Freeze__ : This means any further changes should be backported to the release branch. [(releases/3.2)](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/releases/3.2)
__To be addressed directly during release__
* #827 (announcement of dropping support for Dumux 2)
* Update website links
__Done__
* #855 !1976 !1995 (freeflow example)
* #854 !1979 !1994 (2p example)
* !1784 !2038 !2061 (biomin example)
* #853 !1937 !1980 (shallow water example)
* Fixed Size depr warning !2005. Depends on alugrid backport [dune-alugrid!86](https://gitlab.dune-project.org/extensions/dune-alugrid/-/merge_requests/86) -> backport is merged.
* Subgrid depr warning #865. Depends on [dune-subgrid!16](https://git.imp.fu-berlin.de/agnumpde/dune-subgrid/-/merge_requests/16) -> is merged.
* version checks !1983. Depends on !2008, depends on !2010.
* cmake guards !1974. Depends on !1983.
* #835 (!1964) (doxygen)
* !1901 !2011 (handbook)
* #852 (make headercheck)
* version checks !1983. Depends on !2008, depends on !2010, fixups on !2018. more fixups on !2025 and !2027
* !2022 (paramcheck)
* !2026 !2030 (license updates)
* #848 !1965 !2031 (update install script)
* !2040 (grid view depr warnings)
* #787 !1941 !2039 !2041 !2044 !2045 (rotation example)
* #874 !2053 !2052 (unused variable)
* #873 !2049 (staggered depr warning)
* !2047 !2048 parallel tests co2 comparison fix
* #876 UG segfault ion 2.7
* #863 !2042 !2043 !2065 (fracture box fails)
* #875 !2050 !2061 !2069 !2071 OPM build-bot
* #872 !2046 !2054 !2066 !2072 (Dune Hybrid size depr warning)* #871 !2051 (2poilwet and 1pnc incompressible fail on minimal)
* #879 !2081
* #872
* !2082
* #877
* !2109, !2111
* !2110
Thanks!
* Release Manager: @nedc
* Doxygen Dude: @melaniel
* Handbook Guy: @heck
* Website Guru: @david
* Lecture Zampano: @tkurz
* Course Cadet: @seitz
* Examples Elaborator: @DennisGlaeser3.2Ned ColtmanNed Coltman2020-05-04https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/830Deprecate property GridView2020-04-29T09:48:59ZTimo Kochtimokoch@math.uio.noDeprecate property GridViewGiven that we have the properties `GridGeometry` and `Grid` it seems unnecessary to have `GridView` as well.
Suggestion:
* replace all `GetPropType<TypeTag, Properties::GridView>` by `typename GetPropType<TypeTag, Properties::GridGeome...Given that we have the properties `GridGeometry` and `Grid` it seems unnecessary to have `GridView` as well.
Suggestion:
* replace all `GetPropType<TypeTag, Properties::GridView>` by `typename GetPropType<TypeTag, Properties::GridGeometry>::GridView`
* replace `GetPropType<TypeTag, Properties::GridView>` by `typename GetPropType<TypeTag, Properties::Grid>::LeafGridView` where the above is not possible
Only disadvantage I can see: We cannot change from LeafGridView to LevelGridView by changing the GridView property but you need to change the GridGeometry property. Given that this feature is hardly ever used, it seems acceptable.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/831[examples] Better structure and overview by subfolders2020-04-03T11:34:33ZTimo Kochtimokoch@math.uio.no[examples] Better structure and overview by subfoldersHere are some ideas for a better structure in the examples:
Especially if they are large (see !1784 for an extreme case).
We could
* add separate `.md` files in the `doc` folder that are linked from the main document rather than inclu...Here are some ideas for a better structure in the examples:
Especially if they are large (see !1784 for an extreme case).
We could
* add separate `.md` files in the `doc` folder that are linked from the main document rather than included into the main document
* we could have a separate starting page that explains the setup and the layout, folder and file structure in the example and provides links to the documentation of each file or a group of files
* automate the script to look for `.doc_config` in all subfolder recursively so that for every subfolder we could have an extra autogenerated `README.md` if wanted. That `README.md` can be linked from the main document.
* Remove header guards from the doc
* Improve figure formatting by using HTML
```html
<figure>
<img src="dumux_logo" alt="Dumux logo" style="width:50%">
<figcaption><b>Figure 1 -</b> This is the figure caption for the Dumux logo</figcaption>
</figure>
```
<figure>
<img src="https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/doc/logo/dumux_logo_small.png" alt="Dumux logo">
<figcaption><b>Figure 1 -</b> This is the figure caption for the Dumux logo</figcaption>
</figure>
* see #811 3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/832Reduce code duplication in nonequilibrium/volumevariables.hh2023-12-13T11:13:08ZTimo Kochtimokoch@math.uio.noReduce code duplication in nonequilibrium/volumevariables.hhhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/porousmediumflow/nonequilibrium/volumevariables.hh
For example, the dimensionless numbers could be put in a separate class.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/porousmediumflow/nonequilibrium/volumevariables.hh
For example, the dimensionless numbers could be put in a separate class.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/833Assignments Dumux Day 25.3.202020-04-03T16:02:37ZBernd FlemischAssignments Dumux Day 25.3.20* !1899: @DennisGlaeser
* #830: @emmert
* #827: @timok
* #818, !1906: @nedc
* !1874: @tkurz, @seitz
* #787: @martins
* #751: @timjupe
* #745: @DennisGlaeser, @kweis
* #686: @kweis
* #415: @kweis
* !1784: @hommel, @fel...* !1899: @DennisGlaeser
* #830: @emmert
* #827: @timok
* #818, !1906: @nedc
* !1874: @tkurz, @seitz
* #787: @martins
* #751: @timjupe
* #745: @DennisGlaeser, @kweis
* #686: @kweis
* #415: @kweis
* !1784: @hommel, @felixw
* !1684: @timok, @kweis, @nedc, @DennisGlaeser
* !1827, parameter passing to solvers: @kweis, @bernd
* !1720: @kweis
* !1876, other deprecations: @RoWin
* Lecture: @heck, @holle
* Course: @Maziar, @farid
* #835 : @melaniel
* Shallowwater example: @utz
3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/834unify wettingPhaseIndex() interface2020-03-30T16:05:04ZDennis Gläserunify wettingPhaseIndex() interfaceIn the `CompositionalFluidState`, there is the interface
```cpp
int wettingPhase() const { return wPhaseIdx_; }
```
With !1684 merged, all two-phase flow related `VolumeVariables` implementation introduce:
```cpp
int wettingPhaseIdx()...In the `CompositionalFluidState`, there is the interface
```cpp
int wettingPhase() const { return wPhaseIdx_; }
```
With !1684 merged, all two-phase flow related `VolumeVariables` implementation introduce:
```cpp
int wettingPhaseIdx() const { return wPhaseIdx; }
```
On the other hand, the `ImmiscibleFluidState` does not provide a function to wetting phase index. We should probably define a unified interface and define one place where this should be stored.
I personally would vote for `wettingPhase()`, and I would propose to store it in the fluid state, because I recall that for compositional models it was necessary to have it in there because the flash solvers need it.3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/835Doxgen for 3.22020-08-26T08:03:30ZMelanie LippDoxgen for 3.2Todos:
* [x] empty doxyerr.log
* [x] doxygen not aborting, for this see doxygen.log
* [x] correct display of the equations, dependency-plots/inheritance-plots (there is a plot called aXY+1 included in the file aXY.html) -> OK on https...Todos:
* [x] empty doxyerr.log
* [x] doxygen not aborting, for this see doxygen.log
* [x] correct display of the equations, dependency-plots/inheritance-plots (there is a plot called aXY+1 included in the file aXY.html) -> OK on https://dumux.org/doxygen/master/index.html
* [x] correct linking of the sites (see sanitizelinks.sh for previous fixes)
* [x] correct assignement to submenus
* [x] does the documentation/text of the submenus still make sense/can it be improved?
* [x] does work on the dumux website as well?
* [x] does the documentation make sense? spot mistakenly made copy& paste?
For possible reference of a future doxygen dude:
The documentation is built by running make doc in the dumux build folder.
One way to switch doxygen versions is to:
* download the doxygen git repository from https://github.com/doxygen/doxygen.git
* checkout the branch you want, e.g. Release_1_8_17
* the first time do: mkdir build, cd build, cmake -G "Unix Makefiles" ..
* always do in the doxygen build directory: make, sudo make install
* the first time do: export PATH=/usr/local/bin/doxygen:$PATH
* delete the dumux build folder and rerun dunecontrol for dumux3.2Melanie LippMelanie Lipphttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/836Add assert in chem. non-equilibrium that it only works for numPhases > 12020-03-26T19:06:52ZTimo Kochtimokoch@math.uio.noAdd assert in chem. non-equilibrium that it only works for numPhases > 13.2Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/837[freeflow][test] Transfer lid-driven cavity test to an example2020-11-05T15:36:53ZKilian Weishaupt[freeflow][test] Transfer lid-driven cavity test to an example[Ghia 1982](https://ac.els-cdn.com/0021999182900584/1-s2.0-0021999182900584-main.pdf?_tid=e9f7486c-d67c-11e7-96b6-00000aab0f26&acdnat=1512121945_6871c2de3e7d5699f53ef718416dc341) provide reference solutions (plot over line data) for the
...[Ghia 1982](https://ac.els-cdn.com/0021999182900584/1-s2.0-0021999182900584-main.pdf?_tid=e9f7486c-d67c-11e7-96b6-00000aab0f26&acdnat=1512121945_6871c2de3e7d5699f53ef718416dc341) provide reference solutions (plot over line data) for the
lid-driven cavity test.
I have used the data in my thesis and we could maybe also add them to the test.
* [ ] Turn the test into an example
* [ ] Add literature reference data
* [ ] Use `plotoverline` script from `bin` to extract line data
* [ ] Use scipy/gnuplot to plot and compare with the reference data3.3Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/838[freeflow][test] Add analytical solution to channel test2020-08-28T05:02:47ZKilian Weishaupt[freeflow][test] Add analytical solution to channel testAdd parabolic flow profile to low Re channel test.Add parabolic flow profile to low Re channel test.3.3Melanie LippMelanie Lipp