dumux-repositories issueshttps://git.iws.uni-stuttgart.de/groups/dumux-repositories/-/issues2018-03-19T13:15:14Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/463Rethink isothermal/mineralization type tags2018-03-19T13:15:14ZDennis GläserRethink isothermal/mineralization type tagsIn order to realize non-isothermal models, type tags inherit from the non-isothermal type tag and one has to set the properties IsothermalIndices, IsothermalNumEq etc. The actual types/values are then determined by the non-isothermal typ...In order to realize non-isothermal models, type tags inherit from the non-isothermal type tag and one has to set the properties IsothermalIndices, IsothermalNumEq etc. The actual types/values are then determined by the non-isothermal type tag.
Alternatively, one could also directly set the non-isothermal types (e.g. EnergyIndices<OnePIndices>), because the current way neither saves code nor does it improve readability. Since mineralization models use a similar pattern, in non-isothermal mineralization models it is particularly difficult to see which type is set/used.
Also, we would get rid of all properties like IsothermalIndices, IsothermalVolumeVariables, ..., NonMineralizationVtkOutputFields, NonMineralizationVolumeVariables ...3.0https://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/1065Raise dependency to dune >= 2.82021-10-19T06:34:38ZTimo Kochtimokoch@math.uio.noRaise dependency to dune >= 2.8For release 3.5 I suggest to raise the Dune requirement to 2.8 (which will be released shortly). I suggest this now simply to decrease a bit of maintenance cost. For example we can drop testing against dune 2.7 for the master branch. Som...For release 3.5 I suggest to raise the Dune requirement to 2.8 (which will be released shortly). I suggest this now simply to decrease a bit of maintenance cost. For example we can drop testing against dune 2.7 for the master branch. Some version checks can be removed.
* __Agree?__ Click thumbs up :thumbsup:
* __Disagree?__ Write comment below3.5Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1030Two unreachable code sections2021-05-27T21:24:08ZChristoph GrüningerTwo unreachable code sectionsClang 12 warns about two code section, which are not reachable. Often, this is a sign that the code behaves different from what the programmer expected. In other words, it could be a bug or it could be some overcautious code.
Do you mi...Clang 12 warns about two code section, which are not reachable. Often, this is a sign that the code behaves different from what the programmer expected. In other words, it could be a bug or it could be some overcautious code.
Do you mind having a look?
```
[ 30%] Building CXX object test/material/fluidsystems/CMakeFiles/test_fluidsystems.dir/test_fluidsystems.cc.o
In file included from /usr/include/c++/11/cassert:44,
from /home/gruenich/dune/complete/dune-common/dune/common/parallel/mpihelper.hh:7,
from /home/gruenich/dune/complete/dumux/dumux/common/parameters.hh:36,
from /home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh:31,
from /home/gruenich/dune/complete/dumux/test/material/fluidsystems/checkfluidsystem.hh:40,
from /home/gruenich/dune/complete/dumux/test/material/fluidsystems/test_fluidsystems.cc:28:
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh: In static member function ‘static constexpr int Dumux::FluidSystems::BrineCO2<Scalar, CO2Table, H2OType, Policy>::BrineAdapterPolicy::compIdx(int) [with Scalar = double; CO2Table = Dumux::HeterogeneousCO2Tables::CO2Tables; H2OType = Dumux::Components::SimpleH2O<double>; Policy = Dumux::FluidSystems::BrineCO2DefaultPolicy<false>]’:
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh:181:70: warning: statement will never be executed [-Wswitch-unreachable]
181 | assert(brineCompIdx == VariableSalinityBrine::H2OIdx || brineCompIdx == VariableSalinityBrine::NaClIdx);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh: In static member function ‘static constexpr int Dumux::FluidSystems::BrineCO2<Scalar, CO2Table, H2OType, Policy>::BrineAdapterPolicy::compIdx(int) [with Scalar = double; CO2Table = Dumux::HeterogeneousCO2Tables::CO2Tables; H2OType = Dumux::Components::H2O<double>; Policy = Dumux::FluidSystems::BrineCO2DefaultPolicy<false>]’:
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh:181:70: warning: statement will never be executed [-Wswitch-unreachable]
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh: In static member function ‘static constexpr int Dumux::FluidSystems::BrineCO2<Scalar, CO2Table, H2OType, Policy>::BrineAdapterPolicy::compIdx(int) [with Scalar = double; CO2Table = Dumux::HeterogeneousCO2Tables::CO2Tables; H2OType = Dumux::Components::TabulatedComponent<Dumux::Components::H2O<double>, true>; Policy = Dumux::FluidSystems::BrineCO2DefaultPolicy<false>]’:
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh:181:70: warning: statement will never be executed [-Wswitch-unreachable]
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh: In static member function ‘static constexpr int Dumux::FluidSystems::BrineCO2<Scalar, CO2Table, H2OType, Policy>::BrineAdapterPolicy::compIdx(int) [with Scalar = double; CO2Table = Dumux::HeterogeneousCO2Tables::CO2Tables; H2OType = Dumux::Components::TabulatedComponent<Dumux::Components::H2O<double>, true>; Policy = Dumux::FluidSystems::BrineCO2DefaultPolicy<false, true>]’:
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh:181:70: warning: statement will never be executed [-Wswitch-unreachable]
```
```
[ 99%] Building CXX object examples/shallowwaterfriction/CMakeFiles/example_shallowwaterfriction.dir/main.cc.o
In file included from /home/gruenich/dune/complete/dumux/examples/biomineralization/material/fluidsystems/biominsimplechemistry.hh:62,
from /home/gruenich/dune/complete/dumux/examples/biomineralization/properties.hh:48,
from /home/gruenich/dune/complete/dumux/examples/biomineralization/main.cc:57:
/home/gruenich/dune/complete/dumux/examples/biomineralization/material/fluidsystems/biominsimplechemistry.hh: In static member function ‘static constexpr int Dumux::FluidSystems::BioMinSimpleChemistryFluid<Scalar, CO2Table, H2OType>::BrineAdapterPolicy::compIdx(int) [with Scalar = double; CO2Table = Dumux::ICP::CO2Tables; H2OType = Dumux::Components::TabulatedComponent<Dumux::Components::H2O<double>, true>]’:
/home/gruenich/dune/complete/dumux/examples/biomineralization/material/fluidsystems/biominsimplechemistry.hh:236:25: warning: statement will never be executed [-Wswitch-unreachable]
233 | assert(brineCompIdx == Brine::H2OIdx
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
234 | || brineCompIdx == Brine::NaIdx
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
235 | || brineCompIdx == Brine::ClIdx
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
236 | || brineCompIdx == Brine::CaIdx
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/968Use gitlab ci for automated testing2021-04-29T09:49:22ZDennis GläserUse gitlab ci for automated testingIt could be useful to integrate build and test jobs into our ci such that one can conveniently let the runner test everything in a merge request. That makes it less probable that stuff gets merged that breaks anything.
I would suggest t...It could be useful to integrate build and test jobs into our ci such that one can conveniently let the runner test everything in a merge request. That makes it less probable that stuff gets merged that breaks anything.
I would suggest to create pipelines for commits to master, tags and merge requests. Regarding automatic start of the pipelines, I would suggest the following strategy:
- add manual trigger for build & test pipeline for merge requests. Especially on Dumux days, when there is a lot of pushing to open MRs, we would trigger a lot of unneccesary pipeline runs, I guess. I would prefer a manual trigger here.
- automatic start of the pipeline for master and tags. The first is useful as you always see which commit destroyed the pipeline on master. This is of course a bit redundant as one maybe already triggered and verified a successful pipeline on the branch just before merging. In some cases, it could still break on master if someone didn't rebase before running the pipeline. For safety reasons, I think it could be nice to always test master.
I am thinking of some default setup (Dune2.7, release opts) to be used, but we could schedule one nightly build with different setups as on buildbot. However, that is basically currently done on buildbot, so this would only make sense if we want to stop using buildbot at one point. So, this is probably irrelevant for now.
Another point is that our build and test times are quite long, and it would be nice to build and run only those tests that are necessary, at least for MRs. Here's a first idea for merge requests:
- 1 use `git diff-tree -r --name-only $CI_COMMIT_SHA $CI_MERGE_REQUEST_TARGET_BRANCH_SHA` to list the modified files
- 2 use `ctest -N` to list all tests we currently have
- 3 do something like in `extractmodulepart.sh` to determine required headers of the tests
- 4 select those tests which use any of the files obtained in (1)
- 5 compile and run those tests only
point (2) and (3) might be expensive. We could also store that info in a json file or so, but on the other hand, that file would need to be up-to-date, and maybe someone adds a test in the MR thats not in the file. Or, maybe someone adds a dependency with the MR. For now, I'd opt for always doing that, should be much less expensive than building and running a lot of tests.
_Docker images_
Dune's Docker images for testing are built here: https://gitlab.dune-project.org/docker/ci
It would be nice to reuse some of the base images they use there. Also I propose a `dumux-docker-ci` project that
* automatically builds the dumux test images in GitLabCI (services images from Dune, e.g. `buildah` can be hopefully reused for that purpose)
* pushes the images to the `dumux-docker-ci` container registry (see gitlab-ci.yaml in the dune project)
* reuse base images from Dune if possible
_BuildBot_
Our current images are in https://git.iws.uni-stuttgart.de/timok/dumux-bb-ci
and our current buildbot setup is here: https://git.iws.uni-stuttgart.de/timok/buildbot-master
_Multi module setup_
After new commits in dumux we also want to trigger builds of dumux-lecture (maybe dumux-course). There is also (a bit outdated) dumux-testing with the first system test for dumux. See !2396.
_Coverage reports_
The coverage report is generated here in a weekly build. It already uses GitlabCI.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-coverage3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/914[cleanup][style] Remove comment for header guard #endif2020-10-02T07:16:33ZTimo Kochtimokoch@math.uio.no[cleanup][style] Remove comment for header guard #endifWe sometimes add a comment to the header guards `#endif` like
```cpp
#endif // DUMUX_COMMON_BLA
```
I think this is unnecessary clutter and should be removed.
* The last `#endif` in header files is always the header guard `#endif`
* W...We sometimes add a comment to the header guards `#endif` like
```cpp
#endif // DUMUX_COMMON_BLA
```
I think this is unnecessary clutter and should be removed.
* The last `#endif` in header files is always the header guard `#endif`
* When copying a header file to create a new header it is easy to forget to change this comment
* When changing the header guard it is easy to forget to change this comment3.3Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/887[doxygen] Exclude tests from doxygen?2020-05-27T11:13:44ZTimo Kochtimokoch@math.uio.no[doxygen] Exclude tests from doxygen?There is a number of arguments for simply removing the tests and all files in the test directory from doxygen
* The is a large amount of classes and files that distract from the actual classes and files in the Dumux core
* The code doc ...There is a number of arguments for simply removing the tests and all files in the test directory from doxygen
* The is a large amount of classes and files that distract from the actual classes and files in the Dumux core
* The code doc of the tests is poorly structured and doesn't help much
* Unclear which information gain we get from inclusion
* Our doxygen takes very long to compile and is quite large. This would help reducing it a bit (all dumux source files in the `dumux` folder are `231,172` lines total, all source files (`.hh`,`.cc`) in the `test` folder are `90,691` lines total; using `find . -name '*.hh' -o -name '*.cc' | xargs wc -l`)
* Much of the doc is not very good (while that is a problem in itself and the doc comments in the tests should actually be of high quality too, this is in the current stage really distracting). Even if it would be better the other points remain.
I navigated through the test docs in the online class documentation a bit. I didn't find anything useful in the `Test & Benchmarks` section. Any other opinions and arguments for keeping it?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/884Group arguments in assembly rountines2023-12-13T11:13:08ZTimo Kochtimokoch@math.uio.noGroup arguments in assembly rountinesI think fv element geometry, elem volvars and flux vars cache belong together in an element-wise assembly view point.
This could be expressed, e.g. by grouping these objects together. This might reduce the number of arguments for some fu...I think fv element geometry, elem volvars and flux vars cache belong together in an element-wise assembly view point.
This could be expressed, e.g. by grouping these objects together. This might reduce the number of arguments for some functions.
It's not completely trivial since there are several sensible combination possible.
I added a suggestion for an element view in !2125.
Suggestions for improvement? What that speaks for/against this?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/691Staggered Lingo Unification2019-04-26T07:09:20ZNed ColtmanStaggered Lingo UnificationWe waste a lot of time getting confused with terms like "lateral", "normal", "parallel", "staggered", "sub-", "frontal", "tangential", and there are of course a few remaining.
Many of these terms actually refer to the same thing. It wou...We waste a lot of time getting confused with terms like "lateral", "normal", "parallel", "staggered", "sub-", "frontal", "tangential", and there are of course a few remaining.
Many of these terms actually refer to the same thing. It would be nice to have rules for when each of these words is used, and to unify their use within the staggered discretization and the freeflow models.
Is this possible?3.1Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/654Allow C++172020-01-29T13:09:44ZTimo Kochtimokoch@math.uio.noAllow C++17I think quite some new features speak for allowing C++17. There are some compilers supporting all features, gcc 8 or gcc 7 (without std::filesystem), clang 8 or 5 (without std::filesystem). https://en.cppreference.com/w/cpp/compiler_supp...I think quite some new features speak for allowing C++17. There are some compilers supporting all features, gcc 8 or gcc 7 (without std::filesystem), clang 8 or 5 (without std::filesystem). https://en.cppreference.com/w/cpp/compiler_support. However, there seems to be no cray compiler.
Who is using the newest Dumux version on a platform without C++17 support?3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/595Add labels to tests2019-03-01T14:09:21ZTimo Kochtimokoch@math.uio.noAdd labels to testsEvery label creates a `build_<label>_tests` CMake target. Could be convenient to build e.g. all freeflow tests.
We should decide on labels. Tests can have multiple labels. !1235 introduces the "unit" test label for unit tests. !1289 adde...Every label creates a `build_<label>_tests` CMake target. Could be convenient to build e.g. all freeflow tests.
We should decide on labels. Tests can have multiple labels. !1235 introduces the "unit" test label for unit tests. !1289 added "multidomain" label for multidomain tests, !1291 introduces "freeflow" and "rans", while all "rans" test are also "freeflow".3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/470Extract GlobalPosition from Grid2018-05-03T14:38:00ZDennis GläserExtract GlobalPosition from GridThere are many places where the global position type is locally defined as:
```cpp
using GlobalPosition = Dune::FieldVector<Scalar, dimWorld>;
```
We maybe should think about extracting it from the Element (i.e. Element::Geometry::Glob...There are many places where the global position type is locally defined as:
```cpp
using GlobalPosition = Dune::FieldVector<Scalar, dimWorld>;
```
We maybe should think about extracting it from the Element (i.e. Element::Geometry::GlobalCoordinate) or from the sub-control
volumes and sub-control volume faces (which itself should have been given the type extracted from the grid).
This is especially important when Scalar and ctype are not the same.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/442Collection of not working tests / errors on buildbot2018-08-28T12:56:57ZSimon EmmertCollection of not working tests / errors on buildbotThis is a collection of problems we currently have on buildbot. It is collected here to help everyone in fixing the last tests.
The following fail:
**test flow
* [ ] test_2p_fracture_gravity_mpfa --> Data differs -> Dennis
* [ ] tes...This is a collection of problems we currently have on buildbot. It is collected here to help everyone in fixing the last tests.
The following fail:
**test flow
* [ ] test_2p_fracture_gravity_mpfa --> Data differs -> Dennis
* [ ] test_2p_fracture_gravity_tpfa --> Data differs in parameter: Sn, mobW, pc -> Dennis
* [ ] test_box3pwateroil -> was fixed but still fails on buildbot while passing on my notebook+desktop -> Bernd
* [ ] test_3d2pfvadaptive -> Error from solvers.hh "abs(h) < EPSILON" (see !1038)3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/378[doc] Differentiate between test, tutorial/documented, tutorial/undocumented2019-08-28T11:24:39ZTimo Kochtimokoch@math.uio.no[doc] Differentiate between test, tutorial/documented, tutorial/undocumentedCurrently we have two general "getting started tutorials", however many of our _tests_ are also thought of tutorials as they demonstrate a certain model.
I suggest to distinguish between _tests_ in the _test_ -folder that are specifical...Currently we have two general "getting started tutorials", however many of our _tests_ are also thought of tutorials as they demonstrate a certain model.
I suggest to distinguish between _tests_ in the _test_ -folder that are specifically designed to test certain features and are small/run rather fast, and _tutorials_ in the _tutorial_-folder that are designed to show a certain feature, e.g. how to use the tensor grid factory in a Richards model to refine towards the soil top. I further suggest to create two new subfolders _documented_ and _undocumented_ where all _documented tutorials_ have a detailed latex/markdown problem and feature description. In the future, a number of maybe 10 such documented tutorials would be nice. All tutorials in undocumented can potentially become documented in the future.
Of course tutorials should also tested by the automated build system.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1325[porousmediumflow][2pncmin][nonisothermal] Use current permeability for Neuma...2024-01-10T08:34:05ZSimon Grether[porousmediumflow][2pncmin][nonisothermal] Use current permeability for Neumann gas fluxIn the [non-isothermal 2pncmin test](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2pncmin/nonisothermal?ref_type=heads) the reference permeability is used in the [problem](https://git.iws....In the [non-isothermal 2pncmin test](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2pncmin/nonisothermal?ref_type=heads) the reference permeability is used in the [problem](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/problem.hh?ref_type=heads) for calculating the Neumann flux of the component air. However, the permeability changes during the simulation due to the precipitation of salt.
Therefore, I propose to use the current permeability here:
`...`
`*volVars.permeability()`
`...`
`*volVars.permeability()`
`...`Anna Mareike KosteleckyAnna Mareike Kosteleckyhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1324[porousmediumflow][2pncmin][nonisothermal] Use mass fractions for diffusive N...2023-12-13T14:15:55ZSimon Grether[porousmediumflow][2pncmin][nonisothermal] Use mass fractions for diffusive Neumann fluxIn the [non-isothermal 2pncmin test](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2pncmin/nonisothermal?ref_type=heads) the mole fraction is used in the [problem](https://git.iws.uni-stutt...In the [non-isothermal 2pncmin test](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2pncmin/nonisothermal?ref_type=heads) the mole fraction is used in the [problem](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/problem.hh?ref_type=heads) for calculating the diffusive Neumann flux of the evaporation rate. However, when using a mass-averaged reference system, the mass fraction should be used for the difference quotient of diffusive fluxes.
Therefore, I propose the following correction:
`static const Scalar massFracRefH2O = getParam("FreeFlow.RefMassFracH2O");`
`...`
`const Scalar massFracH2OInside = volVars.massFraction(gasPhaseIdx, H2OIdx);`
`...`
`if (massFracH2OInside - massFracRefH2O > 0)`
`...`
`* (massFracH2OInside - massFracRefH2O)`
`...`
`* (massFracH2OInside - massFracRefH2O)`
`...`
Moreover, the reference value for the free-flow in the [input-file](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/params.input?ref_type=heads) should be converted into the mass fraction.Anna Mareike KosteleckyAnna Mareike Kosteleckyhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1321Brinkman helper for CVFE2023-12-08T21:19:22ZTimo Kochtimokoch@math.uio.noBrinkman helper for CVFE!3715 adds a helper function for a Brinkman term in the Navier-Stokes model using staggered FV. It should be easy to also provide the CVFE implementation (simply condition on the discretization method in the helper function).
The test wo...!3715 adds a helper function for a Brinkman term in the Navier-Stokes model using staggered FV. It should be easy to also provide the CVFE implementation (simply condition on the discretization method in the helper function).
The test would need to be extended then.3.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1319Fix vapor enthalpy calculation in simpleh2o.hh2023-11-23T15:09:53Zzhixin chenFix vapor enthalpy calculation in simpleh2o.hh**What happened / Problem description:**
I encountered a discrepancy in the calculated gas enthalpy and liquid enthalpy of water between the `simpleh2o.hh` and `h2o.hh` files. Upon reviewing the code with Mathis, we identified a potenti...**What happened / Problem description:**
I encountered a discrepancy in the calculated gas enthalpy and liquid enthalpy of water between the `simpleh2o.hh` and `h2o.hh` files. Upon reviewing the code with Mathis, we identified a potential error in the vaporization enthalpy calculation within the `simpleh2o.hh` file. Specifically, the calculated vaporization enthalpy seems to have been overlooked for conversion from kJ/kg to J/kg, as it requires multiplication by 1000.
**What you expected to happen:**
The gas and liquid enthalpy values calculated using `simpleh2o.hh` should align with those obtained from `h2o.hh`, provided that the reference temperature is the same.**
**How to reproduce it (as minimally and precisely as possible):**
check /dumux/material/components/simpleh2o.hh at line 1453.9Lars KaiserLars Kaiserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1254Dualnetwork model - add 'poreInscribedRadius' and 'poreExtendedRadius' for dg...2023-10-24T06:49:43ZAnna Mareike KosteleckyDualnetwork model - add 'poreInscribedRadius' and 'poreExtendedRadius' for dgf-file**Current state and "problem"**
Currently, the dualnetwork model uses the `poreIncribedRadius` (see e.g. [grainfourierslaw.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/flux/porenetwork/grainfouriersl...**Current state and "problem"**
Currently, the dualnetwork model uses the `poreIncribedRadius` (see e.g. [grainfourierslaw.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/flux/porenetwork/grainfourierslaw.hh#L46)) as well as the `poreExtendedRadius` (see e.g. [couplingmanager.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/multidomain/dualnetwork/couplingmanager.hh#L610)). However, in the [openpnm2dgf.py](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/porenetwork/util/openpnm2dgf.py)-script, only the `poreExtendedRadius` (obtained e.g. by the snow-algorithm from porespy) is saved under the name `poreRadius` in the .dgf-file.
**Suggestion**
My suggestion would be to add the `poreIncribedRadius` as well as the `poreExtendedRadius` to the dgf-file for all networks as a porenetwork model also often needs a `poreInscribedRadius` in the current implementations.Anna Mareike KosteleckyAnna Mareike Kosteleckyhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1230Remove deprecation warnings related to "conversion of multitype matrices" bef...2023-03-20T21:05:54ZHamza OukiliRemove deprecation warnings related to "conversion of multitype matrices" before release 3.7There are multiple similar warnings : After 3.7 Newton will no longer support conversion of multitype matrices for solvers that don't support this feature
`In file included from /dumux/dumux/multidomain/newtonsolver.hh:29,
...There are multiple similar warnings : After 3.7 Newton will no longer support conversion of multitype matrices for solvers that don't support this feature
`In file included from /dumux/dumux/multidomain/newtonsolver.hh:29,
from /dumux/test/freeflow/navierstokes/angeli/main.cc:48:
/dumux/dumux/nonlinear/newtonsolver.hh: In instantiation of ‘bool Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::solveLinearSystem_(Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector&) [with Assembler = Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>; LinearSolver = Dumux::UMFPackBackend; Reassembler = Dumux::DefaultPartialReassembler; Comm = Dune::Communication<ompi_communicator_t*>; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector = 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> > > >]’:
/dumux/dumux/nonlinear/newtonsolver.hh:518:25: required from ‘void Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::solveLinearSystem(Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector&) [with Assembler = Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>; LinearSolver = Dumux::UMFPackBackend; Reassembler = Dumux::DefaultPartialReassembler; Comm = Dune::Communication<ompi_communicator_t*>; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector = 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> > > >]’
/dumux/dumux/nonlinear/newtonsolver.hh:982:17: required from ‘bool Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::solve_(typename Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ParentType::Variables&) [with Assembler = Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>; LinearSolver = Dumux::UMFPackBackend; Reassembler = Dumux::DefaultPartialReassembler; Comm = Dune::Communication<ompi_communicator_t*>; typename Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ParentType::Variables = 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> > > >; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ParentType = Dumux::PDESolver<Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>, Dumux::UMFPackBackend>]’
/dumux/dumux/nonlinear/newtonsolver.hh:351:36: required from ‘void Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::solve(typename Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ParentType::Variables&, Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::TimeLoop&) [with Assembler = Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>; LinearSolver = Dumux::UMFPackBackend; Reassembler = Dumux::DefaultPartialReassembler; Comm = Dune::Communication<ompi_communicator_t*>; typename Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ParentType::Variables = 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> > > >; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ParentType = Dumux::PDESolver<Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>, Dumux::UMFPackBackend>; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::TimeLoop = Dumux::TimeLoopBase<double>]’
/dumux/test/freeflow/navierstokes/angeli/main.cc:177:30: required from here
/dumux/dumux/nonlinear/newtonsolver.hh:1122:38: warning: ‘std::enable_if_t<((! Dumux::linearSolverAcceptsMultiTypeMatrix<LS>()) && Dumux::isMultiTypeBlockVector<V>()), bool> Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::solveLinearSystemImpl_(LinearSolver&, Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::JacobianMatrix&, Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector&, Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector&) [with LS = Dumux::UMFPackBackend; V = 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> > > >; Assembler = Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>; LinearSolver = Dumux::UMFPackBackend; Reassembler = Dumux::DefaultPartialReassembler; Comm = Dune::Communication<ompi_communicator_t*>; std::enable_if_t<((! Dumux::linearSolverAcceptsMultiTypeMatrix<LS>()) && Dumux::isMultiTypeBlockVector<V>()), bool> = bool; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::JacobianMatrix = Dune::MultiTypeBlockMatrix<Dune::MultiTypeBlockVector<Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > >, Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > > >, Dune::MultiTypeBlockVector<Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > >, Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > > > >; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector = 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> > > >]’ is deprecated: After 3.7 Newton will no longer support conversion of multitype matrices for solvers that don't support this feature! [-Wdeprecated-declarations]
1122 | return solveLinearSystemImpl_(this->linearSolver(),
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
1123 | this->assembler().jacobian(),
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1124 | deltaU,
| ~~~~~~~
1125 | this->assembler().residual());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/dumux/dumux/nonlinear/newtonsolver.hh:1183:5: note: declared here
1183 | solveLinearSystemImpl_(LinearSolver& ls,`3.7Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.no