dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2021-04-07T17:57:18Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1011Update release manager tasks wiki2021-04-07T17:57:18ZTimo Kochtimokoch@math.uio.noUpdate release manager tasks wikiThe wiki is here https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Release-Manager-Tasks
There is still some points missing from the old Latex document: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-devel/-/bl...The wiki is here https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Release-Manager-Tasks
There is still some points missing from the old Latex document: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-devel/-/blob/master/doc/releaseManagerTasks/releaseManagerTasks.tex.
Some outdated lines might need updating too / some links might need to be fixed.3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1012Handbook for 3.42021-05-05T12:31:42ZFarid MohammadiHandbook for 3.4To-dos:
- [x] Replace versions "3.3" with "3.4"
- [x] Check the changelog to see if it affects the handbook
- [x] Go through handbook and see if anything seems worth to be changed
- [x] Add section about the python scripts in bin directo...To-dos:
- [x] Replace versions "3.3" with "3.4"
- [x] Check the changelog to see if it affects the handbook
- [x] Go through handbook and see if anything seems worth to be changed
- [x] Add section about the python scripts in bin directory #1019 !2587
- [x] Change package name `scrpage2` to newer version `scrlayer-scrpage` (!2556)3.4Farid MohammadiFarid Mohammadihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1013SimpleH20 does not consider enthalpy of vaporization2022-03-30T18:41:30ZKilian WeishauptSimpleH20 does not consider enthalpy of vaporizationI suggest to add $`h_\mathrm{vap}`$ here:
```c++
static const Scalar gasEnthalpy(Scalar temperature,
Scalar pressure)
{
static const Scalar tRef = getParam<Scalar>("SimpleH2O.Reference...I suggest to add $`h_\mathrm{vap}`$ here:
```c++
static const Scalar gasEnthalpy(Scalar temperature,
Scalar pressure)
{
static const Scalar tRef = getParam<Scalar>("SimpleH2O.ReferenceTemperature", 293.15);
return gasHeatCapacity(temperature, pressure)*(temperature - tRef) + 2453.5e3;
}
```
We could even make $`h_\mathrm{vap}`$ depending on $`T_\mathrm{ref}`$ as there as simple equations for that.
http://www.personal.psu.edu/users/m/r/mrh318/physical-consts/Popiel-Wojtkawiak-HTE-1998.pdf
https://www.scirp.org/pdf/AS20120200008_25514260.pdf (Bananas!)
It would still be a constant.3.5Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1014Variablesbackend does not support Dune::DynamicVector as Dof vector2021-04-09T16:32:06ZHanchuan WuVariablesbackend does not support Dune::DynamicVector as Dof vector<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
The current variablesbackend does not consider the situation that the residual type in assembler in newtonsolver ...<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
The current variablesbackend does not consider the situation that the residual type in assembler in newtonsolver can be DynamicVector.
**What happened / Problem description**:
```
/Applications/DUMUX/dumux/dumux/common/variablesbackend.hh:165:10: error: implicit instantiation of undefined template
'Dumux::DofBackend<Dune::DynamicVector<double, std::__1::allocator<double> >, false>'
: public DofBackend<Vars>
```
**Environment**:
- Dune version:master
- DuMux version:master
- Others:The compiler is `clang-1200.0.32.29`, operation system is MacOS.3.4Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1015Add enthalpy of vaporization to constant component2022-02-24T10:57:39ZTimo Kochtimokoch@math.uio.noAdd enthalpy of vaporization to constant componentRelated to #1013 !2563
We could just add a function vaporizationEnthalpy that is also read from the input file.
This also allows to estimate the vapor pressure: https://en.wikipedia.org/wiki/Clausius%E2%80%93Clapeyron_relation#Applica...Related to #1013 !2563
We could just add a function vaporizationEnthalpy that is also read from the input file.
This also allows to estimate the vapor pressure: https://en.wikipedia.org/wiki/Clausius%E2%80%93Clapeyron_relation#Applications (if e.g. triplePointPressure/Temperature is supplied)3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1016Deprecate NumEqVector property2021-05-05T11:56:21ZTimo Kochtimokoch@math.uio.noDeprecate NumEqVector propertyReplace by `Dumux::NumEqVector` type trait in `dumux/common/numeqvector.hh`Replace by `Dumux::NumEqVector` type trait in `dumux/common/numeqvector.hh`3.4https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1017Fix cmake guard for freeflow tests2021-04-14T12:18:50ZDennis GläserFix cmake guard for freeflow testsI noticed in a first test pipeline (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/jobs/10748), that the pipeline with minimal setup failed to build because UMFPack is not installed. Seems like the guard mechanism is not pro...I noticed in a first test pipeline (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/jobs/10748), that the pipeline with minimal setup failed to build because UMFPack is not installed. Seems like the guard mechanism is not properly implemented?Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1018SubDomainCCLocalAssembler: constructor yields undefined state2021-04-26T15:03:39ZBernd FlemischSubDomainCCLocalAssembler: constructor yields undefined stateApparently, constructing a `SubDomainCCLocalAssembler` in the context of the new staggered implementation leaves the object in an undefined state. Running a modified `test_ff_navierstokes_angeli_new` from !2573 with address sanitizer giv...Apparently, constructing a `SubDomainCCLocalAssembler` in the context of the new staggered implementation leaves the object in an undefined state. Running a modified `test_ff_navierstokes_angeli_new` from !2573 with address sanitizer gives
```text
bernd@majestix:/temp/bernd/DUNE28/dumux/build-debug/test/freeflow/navierstokes/angeli$ ASAN_OPTIONS=new_delete_type_mismatch=0 ./test_ff_navierstokes_angeli_new
No parameter file given. Defaulting to 'params.input' for input file.
Reading parameters from file params.input.
Writing output for problem "test_angeli". Took 0.082 seconds.
Instantiated assembler for an instationary problem.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==1102263==ERROR: AddressSanitizer: SEGV on unknown address 0x63133294e188 (pc 0x5639fb7bc733 bp 0x7ffeccc61050 sp 0x7ffeccc61040 T0)
==1102263==The signal is caused by a READ memory access.
#0 0x5639fb7bc733 in __gnu_cxx::__normal_iterator<unsigned int const*, std::vector<unsigned int, std::allocator<unsigned int> > >::__normal_iterator(unsigned int const* const&) (/temp/bernd/DUNE28/dumux/build-debug/test/freeflow/navierstokes/angeli/test_ff_navierstokes_angeli_new+0xdd733)
#1 0x5639fb78dfdd in std::vector<unsigned int, std::allocator<unsigned int> >::end() const (/temp/bernd/DUNE28/dumux/build-debug/test/freeflow/navierstokes/angeli/test_ff_navierstokes_angeli_new+0xaefdd)
#2 0x5639fb763513 in Dumux::scvfs(Dumux::CCTpfaFVElementGeometry<Dumux::CCTpfaFVGridGeometry<Dune::GridView<Dune::DefaultLeafGridViewTraits<Dune::YaspGrid<2, Dune::EquidistantOffsetCoordinates<double, 2> > const> >, true, Dumux::CCTpfaDefaultGridGeometryTraits<Dune::GridView<Dune::DefaultLeafGridViewTraits<Dune::YaspGrid<2, Dune::EquidistantOffsetCoordinates<double, 2> > const> >, Dumux::DefaultMapperTraits<Dune::GridView<Dune::DefaultLeafGridViewTraits<Dune::YaspGrid<2, Dune::EquidistantOffsetCoordinates<double, 2> > const> >, Dune::MultipleCodimMultipleGeomTypeMapper<Dune::GridView<Dune::DefaultLeafGridViewTraits<Dune::YaspGrid<2, Dune::EquidistantOffsetCoordinates<double, 2> > const> > >, Dune::MultipleCodimMultipleGeomTypeMapper<Dune::GridView<Dune::DefaultLeafGridViewTraits<Dune::YaspGrid<2, Dune::EquidistantOffsetCoordinates<double, 2> > const> > > > > >, true> const&) (/temp/bernd/DUNE28/dumux/build-debug/test/freeflow/navierstokes/angeli/test_ff_navierstokes_angeli_new+0x84513)
#3 0x5639fb7246bf in main /temp/bernd/DUNE28/dumux/test/freeflow/navierstokes/angeli/main_new.cc:209
#4 0x7fc060ca4cb1 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x28cb1)
#5 0x5639fb70f35d in _start (/temp/bernd/DUNE28/dumux/build-debug/test/freeflow/navierstokes/angeli/test_ff_navierstokes_angeli_new+0x3035d)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/temp/bernd/DUNE28/dumux/build-debug/test/freeflow/navierstokes/angeli/test_ff_navierstokes_angeli_new+0xdd733) in __gnu_cxx::__normal_iterator<unsigned int const*, std::vector<unsigned int, std::allocator<unsigned int> > >::__normal_iterator(unsigned int const* const&)
==1102263==ABORTING
```
Calling `localAssembler.bindLocalViews()` explicitly fixes the issue but should not have to be done user-side.Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1019Add section on the scripts to the handbook2021-05-07T09:33:15ZBernd FlemischAdd section on the scripts to the handbook3.4Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1020Complete CHANGELOG for 3.42021-05-07T13:04:31ZBernd FlemischComplete CHANGELOG for 3.4The following merged MRs are worth to be considered for mentioning in the changelog for 3.4. Please have a look and add their content in a few words if necessary, and then mark it in the checkbox.
- [x] !2408
- [x] !2569
- [x] !2296
- ...The following merged MRs are worth to be considered for mentioning in the changelog for 3.4. Please have a look and add their content in a few words if necessary, and then mark it in the checkbox.
- [x] !2408
- [x] !2569
- [x] !2296
- [x] !2507
- [x] ~~!2285~~ (We want to include this new grid variable concept after this can be really used instead of still in namespace 'Experimental')
- [x] !2521
- [x] !2510
- [x] !2509
- [x] !2505
- [x] !2243
- [x] !2239 The `LinearPDESolver` can reuse the matrix and thus avoid unnecessary reassembly. See `test/porousmediumflow/tracer/constvel/main.cc` for an example.
- [x] !2414
- [x] !2454
- [x] !2421
- [x] !2457
- [x] !2422
- [x] !2419 : This MR is mentioned in the changelog for 3.3. Please check if this is correct.
- [x] !2425
- [x] ~~!2282~~ (This was not merged into `master`but into the new staggered dev branch)
- [x] !24173.4https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1021Install / get used versions fails for checked out commit2021-07-30T18:27:19ZTimo Kochtimokoch@math.uio.noInstall / get used versions fails for checked out commitWhen a module is checked out on a specific commit (detached HEAD) the scripts geusedversions/makeinstallscript fail:
```
An error occurred during subprocess run:
-- command: git log -n 1 --format=%H @{upstream}
-- folder: dune-istl
-- e...When a module is checked out on a specific commit (detached HEAD) the scripts geusedversions/makeinstallscript fail:
```
An error occurred during subprocess run:
-- command: git log -n 1 --format=%H @{upstream}
-- folder: dune-istl
-- error: Command 'git log -n 1 --format=%H @{upstream}' returned non-zero exit status 128.
```
what is the `@{upstream}` doing?3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1022Cmake error in DumuxTestMacros2021-04-29T14:57:38ZTimo Kochtimokoch@math.uio.noCmake error in DumuxTestMacrosSeems like !2408 introduces some cmake bug. With cmake 3.16 I get
```
CMake Error at dumux/cmake/modules/DumuxTestMacros.cmake:260 (file):
Syntax error in cmake code at
dumux/cmake/modules/DumuxTestMacros.cmake:261
when parsin...Seems like !2408 introduces some cmake bug. With cmake 3.16 I get
```
CMake Error at dumux/cmake/modules/DumuxTestMacros.cmake:260 (file):
Syntax error in cmake code at
dumux/cmake/modules/DumuxTestMacros.cmake:261
when parsing string
\{\n \"name\": \"${ADDTEST_NAME}\",\n \"target\": \"${ADDTEST_TARGET}\"\n\}\n
Invalid escape sequence \{
```3.4Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1023Message warning about suboptimal performance of AMG in case no direct solver ...2021-05-09T12:17:02ZTimo Kochtimokoch@math.uio.noMessage warning about suboptimal performance of AMG in case no direct solver is availableIf no direct solver (UMFPack, SuperLU) is found (both are optional dependencies),
the coarse grid solver in the AMG is a `BiCGSTABSolver` hard-coded to a tolerance of 1e-2 (see https://gitlab.dune-project.org/core/dune-istl/-/blob/master...If no direct solver (UMFPack, SuperLU) is found (both are optional dependencies),
the coarse grid solver in the AMG is a `BiCGSTABSolver` hard-coded to a tolerance of 1e-2 (see https://gitlab.dune-project.org/core/dune-istl/-/blob/master/dune/istl/paamg/amg.hh#L771) which
may not be precise enough depending on the application.
I suggest to print a warning if an AMG-based solver is instantiated and neither UMFPack or SuperLU is found.
We have a patch in dumux that can be applied to decrease the tolerance (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/patches/istl-2.6.patch)3.4Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1024Richards test do not converge2021-05-06T08:56:37ZDennis GläserRichards test do not convergeIt seems that after !2574, some richards tests don't converge anymore, causing all pipelines to fail: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/pipelines/3789
I only checked one output log and saw that `test_richards_b...It seems that after !2574, some richards tests don't converge anymore, causing all pipelines to fail: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/pipelines/3789
I only checked one output log and saw that `test_richards_benchmark_infiltration_tpfa` fails due to timeout with poor newton convergence. There may be more tests affected.
In the MR I see that at the latest stage at least, there was no pipeline triggered. Did you test locally before merge @heck, @timok ?3.4https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1025InvertCubicPolynomial test fails2021-05-10T14:35:37ZDennis GläserInvertCubicPolynomial test failsIn our pipeline, `test_math` regularly fails. According to GitLab it failed 4 times in the last 14 days - although I think we have the CI only since about a week. The `invertCubicPolynomial` test seems to be the cause of error, here is t...In our pipeline, `test_math` regularly fails. According to GitLab it failed 4 times in the last 14 days - although I think we have the CI only since about a week. The `invertCubicPolynomial` test seems to be the cause of error, here is the output from tonight:
```sh
terminate called after throwing an instance of 'Dune::Exception'
what(): Dune::Exception [operator():/builds/dumux-repositories/dumux/test/common/math/test_math.cc:282]: [invertCubicPolynomial] Root 0 of 3: -7.81946 does not match reference
```
The night before, for instance, it seems that it did not fail. @timok, I believe you implemented this? I haven't looked into the test yet, but could it be that the deviation threshold in the test is chosen too small?3.4Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1026Minimal CI Setup failing tests2021-05-10T12:22:33ZTimo Kochtimokoch@math.uio.noMinimal CI Setup failing tests421 - test_3p3cni_columnxylol_box (Failed)
427 - test_3pwateroil_sagd_box (Failed)
Probably related to the solver tolerance in the AMG without direct solver backend.421 - test_3p3cni_columnxylol_box (Failed)
427 - test_3pwateroil_sagd_box (Failed)
Probably related to the solver tolerance in the AMG without direct solver backend.3.4Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1027Minimize compiler/deprecation warnings with dune 2.8-git2021-05-27T12:44:54ZTimo Kochtimokoch@math.uio.noMinimize compiler/deprecation warnings with dune 2.8-gitThere is a couple of deprecation warnings we should get rid off for the release version. See recent pipelines: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/jobs/13567 https://git.iws.uni-stuttgart.de/dumux-repositories/dum...There is a couple of deprecation warnings we should get rid off for the release version. See recent pipelines: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/jobs/13567 https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/jobs/13569
**Alight here is a quick summary (As of 26.05.2021):**
~~Tests with warnings related to the `GeometryTypes::cube(dim)` deprecation in UG and Alu:~~
- ~~test_2p_boxdfm_quads_alu~~
- ~~test_2p_boxdfm_trias_alu~~
- ~~test_2p_boxdfm_trias_ug~~
- ~~test_2p_boxdfm_tets_ug~~
**Tests with warnings related to the `Dune::GmshReader<Grid>::read(` deprecation in UG, Alu and Foam:**
- test_shallowwater_poiseuilleflow
- test_gmshboundaryflag
- test_gridmanager_dgf_ug
- test_gridmanager_gmsh_e_markers_ug
- test_gridmanager_gmsh_3d_ug
- test_gridmanager_dgf_alu
- test_gmshboundaryflag_caching
- test_md_embedded_1d3d_1p1p_boxbox_average
- test_md_embedded_1d3d_1p1p_boxtpfa_average
- test_md_embedded_1d3d_1p1p_tpfabox_average
- test_md_embedded_1d3d_1p1p_tpfatpfa_surface
- test_md_embedded_1d3d_1p1p_tpfatpfa_kernel
- test_md_embedded_1d3d_1p_richards_tpfatpfa
- test_md_embedded_2d3d_fracture1p_tpfa
- test_1p_convergence_analytic_box
- test_1p_convergence_analytic_tpfa
- test_1p_pointsources_timeindependent_box_prism
- test_1p_pointsources_timeindependent_tpfa_prism
- test_1p_incompressible_tpfa_anadiff
- test_1p_fracture2d3d_mpfa
- test_1p_fracture2d3d_tpfa
- test_1p_fracture2d3d_box
- test_1p_network1d3d_box
- test_1p_network1d3d_tpfa
- test_1p2c_transport_mpfa
- test_1p2c_transport_tpfa
- test_1p2c_saltwaterintrusion_box
- test_1p2cni_conduction_tpfa
- test_1p2cni_conduction_mpfa
- test_1p2cni_conduction_box
- test_1p2cni_convection_mpfa
- test_1p2cni_convection_tpfa
- test_1p2cni_convection_box
- test_1pncni_transientbc_box_caching
- test_1pncni_transientbc_box
- test_1pncni_transientbc_tpfa_caching
- test_1pncni_transientbc_mpfa_caching
- test_1pncni_transientbc_mpfa
- test_1p2c_nonequilibrium_tpfa
- test_1pnc_maxwellstefan_tpfa
- test_2p_pointsource_adaptive_tpfa
- test_2p_adaptive_tpfa
- test_2p_fracture_mpfa
- test_2p_fracture_tpfa
- test_2p_fracture_box
- test_2pni_tpfa_simplex
- test_2pni_box_simplex
- test_2p_rotationsymmetry_dome
- test_co2_tpfa
- test_co2ni_tpfa
- test_co2_box
- test_richards_lens_tpfa_parallel_ug
- test_richards_lens_tpfa_parallel_alu
- test_richards_lens_box_parallel_ug
- test_richards_lens_box_parallel_alu
- example_1ptracer
**Sequential Tests with warnings related to `vtkmultiwriter.hh`, `start.hh`, `timeloop.hh` (Not dune related, #869 ):**
- test_dec1p
- test_3d2pmpfal
- test_impeswithamg
- test_3d2pmimetic
- test_3d2pfv
- test_dec2p2c
- test_adaptive2p2c2d
**Both Sequential and Gmshreader warnings:**
- test_diffusion
- test_3d2pmimeticadaptive
- test_impesadaptive
- test_impesadaptiverestart
- test_3d2pfvadaptive
- test_transport
- test_3d2pfv
- test_3d2pmpfaladaptive
- test_adaptive2p2c3d
- test_solidenergy_tpfa3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1028[CI] keep going when some targets can't be built2021-05-12T10:32:09ZTimo Kochtimokoch@math.uio.no[CI] keep going when some targets can't be builtCurrently builds stop on first failure. But it's usually good to get the full picture of failing tests.
We can add `-k`/`--keep-going` to `make`. I don't know if the number of failed target builds can be limited. With `ninja` this is po...Currently builds stop on first failure. But it's usually good to get the full picture of failing tests.
We can add `-k`/`--keep-going` to `make`. I don't know if the number of failed target builds can be limited. With `ninja` this is possible, e.g. stop after 20 targets couldn't be made because then there is something seriously wrong which is probably clear by then.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1029test_mpfa2p.cc broken with Clang 122021-05-13T20:54:30ZChristoph Grüningertest_mpfa2p.cc broken with Clang 12Using Clang 12 I get an error, not sure why it complains…
```
In file included from /home/gruenich/dune/complete/dumux/test/porousmediumflow/sequential/2p/test_mpfa2p.cc:32:
In file included from /home/gruenich/dune/complete/dumux/test/...Using Clang 12 I get an error, not sure why it complains…
```
In file included from /home/gruenich/dune/complete/dumux/test/porousmediumflow/sequential/2p/test_mpfa2p.cc:32:
In file included from /home/gruenich/dune/complete/dumux/test/porousmediumflow/sequential/2p/test_mpfa2pproblem.hh:50:
/home/gruenich/dune/complete/dumux/test/porousmediumflow/sequential/2p/test_mpfa2pspatialparams.hh:83:91: error: use of class template 'LinearMaterialDefault' requires template arguments
return std::is_same_v<PcKrSwCurve, LinearMaterial> || std::is_same_v<PcKrSwCurve, LinearMaterialDefault>;
^
/home/gruenich/dune/complete/dumux/test/porousmediumflow/sequential/2p/test_mpfa2pspatialparams.hh:51:7: note: template is declared here
class LinearMaterialDefault;
```3.4Hanchuan WuHanchuan Wuhttps://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/1031[ci] Do MR test selection also for dumux-lecture in downstream trigger2021-05-16T19:49:35ZTimo Kochtimokoch@math.uio.no[ci] Do MR test selection also for dumux-lecture in downstream triggerCurrently all tests in dumux-lecture will be run although we could also check there which tests are actually affected by doing the diff in dumux when the pipeline is triggered from upstream.Currently all tests in dumux-lecture will be run although we could also check there which tests are actually affected by doing the diff in dumux when the pipeline is triggered from upstream.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1032[ci] Change downstream dumux-lecture trigger to master2021-06-02T11:18:08ZTimo Kochtimokoch@math.uio.no[ci] Change downstream dumux-lecture trigger to masterTrigger builds of dumux-lecture `master` branch. Depends on dumux-lecture!146 to be merged first.Trigger builds of dumux-lecture `master` branch. Depends on dumux-lecture!146 to be merged first.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1033Update list of contributors2021-05-19T08:37:06ZTimo Kochtimokoch@math.uio.noUpdate list of contributorsLICENSE.md for release 3.4LICENSE.md for release 3.43.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1034Segfault in McWorther test (currently untested)2021-08-16T12:23:18ZTimo Kochtimokoch@math.uio.noSegfault in McWorther test (currently untested)The test added in !2630 fails. Continuing discussion there.The test added in !2630 fails. Continuing discussion there.3.5Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1036Dumux Day 26.05.212021-06-07T12:42:51ZKilian WeishauptDumux Day 26.05.21- [x] #1027 (+lecture) @nedc
- [x] Test skipped tests @felixw
- [x] #1008 @farid
- [x] Update mailmap @emmert
- [x] ~~#970 @hommel @tkurz~~ to be continued (towards 3.5)
- [x] create release branch for dumux-course
- [x] fix gstat, qu...- [x] #1027 (+lecture) @nedc
- [x] Test skipped tests @felixw
- [x] #1008 @farid
- [x] Update mailmap @emmert
- [x] ~~#970 @hommel @tkurz~~ to be continued (towards 3.5)
- [x] create release branch for dumux-course
- [x] fix gstat, quad, ... test in ci @DennisGlaeser
- [x] implement BJS for new staggered @kweis
- [x] change dumux version in `installdumux.py` (!2647)
- [x] change default dumux version in `installexternal.py` (!2647)3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1037Extract module does not create patches for local changes2021-07-30T18:27:17ZTimo Kochtimokoch@math.uio.noExtract module does not create patches for local changesThe old script had the functionality that it would create patches if you have local uncommitted changes or unpushed commits. This seems to be missing in the Python script.The old script had the functionality that it would create patches if you have local uncommitted changes or unpushed commits. This seems to be missing in the Python script.3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1038Release 3.42021-08-03T08:11:27ZTimo Kochtimokoch@math.uio.noRelease 3.4<!--
This form is for release issue ONLY!
If you're looking for help check out the [readme](/README.md).
-->
This a release issue template with a checklist based on [Release Manager Tasks](https://git.iws.uni-stuttgart.de/dumux-repositor...<!--
This form is for release issue ONLY!
If you're looking for help check out the [readme](/README.md).
-->
This a release issue template with a checklist based on [Release Manager Tasks](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Release-Manager-Tasks). Check there for details on each task.
# [5 Weeks] prior to the release:
- [x] Call a meeting
- [x] Assign developers to the major subtasks
- Manager: @hanchuan
- Lecture: @yue
- Doxygen: @melaniel
- Handbook: @farid
- Course: @tschol
- Examples: @nedc
- Website: @RoWin
- [x] Create a group (dumux-repositories) milestone in GitLab
- [x] Fix planned [Dune] and compiler compatibility: Dune 2.7/2.8-git, C++17 gcc7/clang5
- [x] Go through all existing Gitlab tasks ([issues] or [MRs])
- [x] Assign the open [issues] and [MRs] to the developers
- [x] Post a release schedule announcement on the mailing list
# [3 weeks] prior to the release:
- [x] Check all open MRs and Issues for severity and impact
- [x] Update the milestone issue
- [x] Generate example documentation with the script `generate_example_docs.py`
- [x] Announce soft feature freeze on the mailing list
- [x] Check in with the managers of the sub-tasks
# [2 weeks] prior to the release:
__Hard Feature Freeze!__
- [x] Check remaining MRs and Issues
- [x] Update the milestone issue
- [x] Update CHANGELOG
- [x] Announce hard feature freeze on the mailing list
- [x] Update all install scripts and the install text in the handbook
- [x] Header check (run `make headercheck`) (#1040, #1067)
- [x] Check and update the runtime parameters (see `bin/doc/getparameterlist.py`)
- [x] Make sure the CMakeLists.txt in `dumux` subfolder are up-to-date (generated with `bin/utils/create_cmakelists.py`, dumux `make install` should result in a useable installed dumux version)
- [x] Create release branches
- [x] Configure CI to test release branch
- [x] Local Testing (different compilers and dependency setups)
# During the week of the release:
__Final testing!__
- [x] Re-run tests
- [x] Update copyright
- [x] Update License
- [x] Test Lecture and Course
- [x] Update Website
- [x] Create a release candidate
- [x] Call for testing
# Releasing DuMu<sup>x</sup>
__Important:__ These steps are normally done together with Bernd. Make sure to schedule the time properly.
- [x] Protect release branch (in GitLab)
- [x] Create new tags
- [x] Prepare a Zenodo citation
# After the release
- [x] Bump version in dune.module to next version
- [x] Sent an E-Mail to the dumux mailing list about updates on supported features and upcoming changes3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1039[ci] Test release branch2021-06-02T14:32:14ZTimo Kochtimokoch@math.uio.no[ci] Test release branchThe question is how often?
Also for the release branch we should test a setup with OPMThe question is how often?
Also for the release branch we should test a setup with OPMhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1040Run and fix make headercheck (3.4)2022-02-22T14:03:45ZTimo Kochtimokoch@math.uio.noRun and fix make headercheck (3.4)* [ ] Review the dumux
* [x] Review the dumux-course
* [x] Review the dumux-lecture* [ ] Review the dumux
* [x] Review the dumux-course
* [x] Review the dumux-lecture3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1041[ci] Test cornerpoint grid + OPM2022-05-03T11:25:42ZTimo Kochtimokoch@math.uio.no[ci] Test cornerpoint grid + OPMMaybe just on the release branch. Needs a different Docker image?
Many people seem to have difficulties getting OPM to run (e.g. #1036), so a Dockerfile might help to at least show the minimal steps required to set it up on a new system...Maybe just on the release branch. Needs a different Docker image?
Many people seem to have difficulties getting OPM to run (e.g. #1036), so a Dockerfile might help to at least show the minimal steps required to set it up on a new system. I also have the feeling from the mailing list posts that cornerpoint grids quite a popular feature for external users.3.5Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1042[ci] Test python bindings2021-07-28T10:00:01ZTimo Kochtimokoch@math.uio.no[ci] Test python bindingsOnly against dune master / 2.8. Different Docker container?Only against dune master / 2.8. Different Docker container?3.5Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1043Unify guards for uggrid2021-06-28T12:45:42ZTimo Kochtimokoch@math.uio.noUnify guards for uggrid* The cmake guard should be: `dune-uggrid_FOUND`
* The preprocessor guard should be `HAVE_DUNE_UGGRID`
Replace outdated `HAVE_UG`.* The cmake guard should be: `dune-uggrid_FOUND`
* The preprocessor guard should be `HAVE_DUNE_UGGRID`
Replace outdated `HAVE_UG`.3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1044Update CMakeLists.txt2021-06-09T07:08:02ZHanchuan WuUpdate CMakeLists.txtMake sure the CMakeLists.txt in `dumux` subfolder are up-to-date (generated with `bin/utils/create_cmakelists.py`, dumux `make install` should result in a useable installed dumux version)Make sure the CMakeLists.txt in `dumux` subfolder are up-to-date (generated with `bin/utils/create_cmakelists.py`, dumux `make install` should result in a useable installed dumux version)3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1045improve time information in TimeLoop2021-06-25T18:31:42ZLeopold Stadlerimprove time information in TimeLoop<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
There are two small issues about the output of time information in the class TimeLoop.
1. The output f...<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
There are two small issues about the output of time information in the class TimeLoop.
1. The output format of wall clock time and other CPU times is in a low precision `{:.2g}`, so it is impossible to measure the time in detail.
2. (Optional) The output shows **_Simulation took_** but **_Time loop took_** seams more consistent since only the time of the time loop is measured.
For parallel computations the start-up (partitioning etc.) may take a lot of time and this time belongs also to as simulation, but is not measured by TimeLoop.
**What does this feature / why does DuMux need it**:
- Change the precision to {:.5g} for _Wall clock time_, _Simulation took_ and the _cumulative CPU time_
- (Optional) Rename _**Simulation took**_ to _**Time loop took**_
DuMux needs a higher output precision for time related information to allow users to measure the time used by the time loop for performance studies, benchmarks and checking/plotting the convergence. Making a plot of _**Wall clock time_** and **_time_** or **_time step size_** only works if all variables are given in a sufficient precision.
**Which issue does this feature fix (if any)**
**Anything else we need to know?**:
This issue is related to #916
I'm not sure if the formulation **_Simulation took_** has been explicitly chosen instead of something like **_Time loop took_**.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1046Replace tabulated2dfunction2023-12-13T11:13:08ZTimo Kochtimokoch@math.uio.noReplace tabulated2dfunctionMight be worth replacing this class ([common/tabulated2dfunction.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/common/tabulated2dfunction.hh)) by a specialization of `math.hh:interpolate` for `Bilinear...Might be worth replacing this class ([common/tabulated2dfunction.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/common/tabulated2dfunction.hh)) by a specialization of `math.hh:interpolate` for `BilinearTable` (Scalar = randomaccess container size 2). And some function that computes the sampling points.
Follow-up from !2692https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1047co2 test fails with grid flux variables cache using mpfa2021-09-22T11:29:52ZDennis Gläserco2 test fails with grid flux variables cache using mpfaenabling the grid flux variables cache leads to some time steps to converge worse, and ultimately, failure of the test. One should also try if the same issue appears with tpfa.enabling the grid flux variables cache leads to some time steps to converge worse, and ultimately, failure of the test. One should also try if the same issue appears with tpfa.3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1049GitLab CI ignored the tests with OPM2021-07-08T08:12:30ZHanchuan WuGitLab CI ignored the tests with OPMThe current CI pipeline maintaining our project would not check the tests with OPM,
e.g. `test/porousmediumflow/2p/cornerpoint`.
It would be nice if these cases could also be tested automatically in the future.The current CI pipeline maintaining our project would not check the tests with OPM,
e.g. `test/porousmediumflow/2p/cornerpoint`.
It would be nice if these cases could also be tested automatically in the future.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1050use consistent style in python scripts2021-09-02T21:40:02ZDennis Gläseruse consistent style in python scriptsSince !2654 there are some functions that use snake_case while before we had always used camelCase. We should probably decide on a consistent style and adjust the scripts/functions accordingly.Since !2654 there are some functions that use snake_case while before we had always used camelCase. We should probably decide on a consistent style and adjust the scripts/functions accordingly.3.5Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1051Remove deprecation warning from mapper.update()2021-07-17T19:13:18ZTimo Kochtimokoch@math.uio.noRemove deprecation warning from mapper.update()In Dune >= 2.8 the `mapper.update(gridview)` now has to receive a grid view as argument. Add version checks in the places where `update` is called as Dune 2.7 only implements `mapper.update()`.In Dune >= 2.8 the `mapper.update(gridview)` now has to receive a grid view as argument. Add version checks in the places where `update` is called as Dune 2.7 only implements `mapper.update()`.3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1052Bug found for multidomain_embedded_1d3d test case in dune-foam grid after swi...2021-07-14T08:00:12ZHanchuan WuBug found for multidomain_embedded_1d3d test case in dune-foam grid after switching dune-grid>=2.8<!--
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**:
I got the following error message:
```
In file included from /Applicat...<!--
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**:
I got the following error message:
```
In file included from /Applications/DUMUX/dune-foamgrid/dune/foamgrid/foamgrid.hh:796,
from /Applications/DUMUX/dumux/dumux/io/grid/gridmanager_foam.hh:29,
from /Applications/DUMUX/dumux/test/multidomain/embedded/1d3d/1p_1p/main.cc:41:
/Applications/DUMUX/dune-foamgrid/dune/foamgrid/foamgrid/foamgridfactory.hh: In instantiation of 'Dune::ToUniquePtr<Dune::FoamGrid<1, dimworld, ct> > Dune::GridFactory<Dune::FoamGrid<1, dimworld, ct> >::createGrid() [with int dimworld = 3; ct = double; Dune::ToUniquePtr<Dune::FoamGrid<1, dimworld, ct> > = std::unique_ptr<Dune::FoamGrid<1, 3>, std::default_delete<Dune::FoamGrid<1, 3> > >]':
/Applications/DUMUX/dumux/dumux/io/grid/gridmanager_foam.hh:160:73: required from 'void Dumux::GridManager<Dune::FoamGrid<1, dimworld> >::init(const string&) [with int dimworld = 3; std::string = std::__cxx11::basic_string<char>]'
/Applications/DUMUX/dumux/test/multidomain/embedded/1d3d/1p_1p/main.cc:76:27: required from here
/Applications/DUMUX/dune-foamgrid/dune/foamgrid/foamgrid/foamgridfactory.hh:259:20: error: could not convert 'tmp' from Dune::FoamGrid<1, 3>*' to 'Dune::ToUniquePtr<Dune::FoamGrid<1, 3> >' {aka 'std::unique_ptr<Dune::FoamGrid<1, 3>, std::default_delete<Dune::FoamGrid<1, 3> > >'}
259 | return tmp;
| ^~~
| |
| Dune::FoamGrid<1, 3>*
```
It looks like a type convert problem in `foamgridfactory.hh`.
But I am not sure what caused this and how to fix it. Can anyone give me some help?
**How to reproduce it (as minimally and precisely as possible)**: Test dumux with dune>=2.8
**Anything else we need to know?**:
**Environment**:
- Dune version: 2.8
- DuMux version: 3.4
- Others: compliers are gcc-11, g++-11https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1053Deprecation warning from Vtk::FieldType2021-07-18T13:09:29ZTimo Kochtimokoch@math.uio.noDeprecation warning from Vtk::FieldTypeThere are some deprecation warnings in the poreentwork model from `OutputModule::FieldType` which is now `Vtk::FieldType`There are some deprecation warnings in the poreentwork model from `OutputModule::FieldType` which is now `Vtk::FieldType`3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1054Discretization method as tag instead of enum2021-10-26T18:39:39ZTimo Kochtimokoch@math.uio.noDiscretization method as tag instead of enumTags (see https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/common/tag.hh) have some advantages over enums and, as far as I know, no disadvantages (edit: one disadvantage is that interfaces receiving a method ...Tags (see https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/common/tag.hh) have some advantages over enums and, as far as I know, no disadvantages (edit: one disadvantage is that interfaces receiving a method as an argument need to be templated while this is not necessary for the enum implementation). The most prominent advantage being that a new tag can be added in user code without modifying the `discretization/method.hh` header which is currently required. This makes is difficult/impossible to add a new discretization in a separate module.
Tags have been introduced for the `CouplingMode` in [couplingmanager1d3d.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/multidomain/embedded/couplingmanager1d3d.hh) which previously was an enum and enabled implemented new modes in downstream modules. There was also a deprecation period possible which should be possible for the discretization method as well.
!2795
!28443.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1055Remove deprecated warnings2021-07-30T17:51:33ZHanchuan WuRemove deprecated warningsTest all cases in `dumux` deprecated warnings, except the ones from sequential cases.
Warnings need to be removed are posted below:
- [x] Warnings brought by newly introduced customized dumux `mapper.update(gridView)`:
```
[ 9%] Buil...Test all cases in `dumux` deprecated warnings, except the ones from sequential cases.
Warnings need to be removed are posted below:
- [x] Warnings brought by newly introduced customized dumux `mapper.update(gridView)`:
```
[ 9%] Building CXX object test/freeflow/navierstokes/channel/1d/CMakeFiles/test_ff_navierstokes_1d.dir/main.cc.o
In file included from /Applications/DUMUX/dumux/dumux/discretization/staggered.hh:43,
from /Applications/DUMUX/dumux/dumux/discretization/staggered/freeflow/properties.hh:35,
from /Applications/DUMUX/dumux/test/freeflow/navierstokes/channel/1d/properties.hh:28,
from /Applications/DUMUX/dumux/test/freeflow/navierstokes/channel/1d/main.cc:45:
/Applications/DUMUX/dumux/dumux/discretization/staggered/fvgridgeometry.hh: In instantiation of 'void Dumux::StaggeredFVGridGeometry<GV, true, T>::update() [with GV = Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<1> > >; T = Dumux::StaggeredFreeFlowDefaultFVGridGeometryTraits<Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<1> > >, 1, Dumux::DefaultMapperTraits<Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<1> > >, Dune::MultipleCodimMultipleGeomTypeMapper<Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<1> > > >, Dune::MultipleCodimMultipleGeomTypeMapper<Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<1> > > > > >]':
/Applications/DUMUX/dumux/test/freeflow/navierstokes/channel/1d/main.cc:78:25: required from here
/Applications/DUMUX/dumux/dumux/discretization/staggered/fvgridgeometry.hh:285:35: warning: 'void Dumux::ConformingGridIntersectionMapper<GridView>::update() [with GridView = Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<1> > >]' is deprecated: Use update(gridView) instead! Will be removed after release 3.4. [-Wdeprecated-declarations]
285 | intersectionMapper_.update();
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~
In file included from /Applications/DUMUX/dumux/dumux/discretization/staggered/freeflow/properties.hh:32,
from /Applications/DUMUX/dumux/test/freeflow/navierstokes/channel/1d/properties.hh:28,
from /Applications/DUMUX/dumux/test/freeflow/navierstokes/channel/1d/main.cc:45:
/Applications/DUMUX/dumux/dumux/common/intersectionmapper.hh:68:10: note: declared here
68 | void update()
| ^~~~~~
```
- [x] Warnings from gmsh reader interface: --> cannot be reasonbly fixed without https://gitlab.dune-project.org/core/dune-grid/-/merge_requests/410
```
[ 18%] Building CXX object test/freeflow/shallowwater/poiseuilleflow/CMakeFiles/test_shallowwater_poiseuilleflow_unstructured.dir/main.cc.o
In file included from /Applications/DUMUX/dumux/dumux/io/grid/gridmanager_yasp.hh:33,
from /Applications/DUMUX/dumux/test/freeflow/shallowwater/poiseuilleflow/main.cc:36:
/Applications/DUMUX/dumux/dumux/io/grid/gridmanager_base.hh: In instantiation of 'void Dumux::GridManagerBase<GridType>::makeGridFromFile(const string&, const string&) [with GridType = Dune::UGGrid<2>; std::string = std::__cxx11::basic_string<char>]':
/Applications/DUMUX/dumux/dumux/io/grid/gridmanager_ug.hh:77:41: required from 'void Dumux::GridManager<Dune::UGGrid<dim> >::init(const string&) [with int dim = 2; std::string = std::__cxx11::basic_string<char>]'
/Applications/DUMUX/dumux/test/freeflow/shallowwater/poiseuilleflow/main.cc:55:21: required from here
/Applications/DUMUX/dumux/dumux/io/grid/gridmanager_base.hh:218:45: warning: 'static void Dune::GmshReader<GridType>::read(Dune::GridFactory<GridType>&, const string&, std::vector<int>&, std::vector<int>&, bool, bool) [with GridType = Dune::UGGrid<2>; std::string = std::__cxx11::basic_string<char>]' is deprecated: Deprecated after Dune 2.7 (ca. 2020-02): The insertBoundarySegments argument for this overload of the read method is deprecated, please omit it. See https://gitlab.dune-project.org/flyspray/FS/issues/1698. When setting insertBoundarySegments=false there is no way to correctly use the data returned in boundarySegmentToPhysicalEntity, which makes using the old method error-prone. [-Wdeprecated-declarations]
218 | Dune::GmshReader<Grid>::read(*gridFactory, fileName, boundaryMarkers, elementMarkers, verbose, boundarySegments);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /Applications/DUMUX/dune-grid/dune/grid/io/file/dgfparser/gridptr.hh:31,
from /Applications/DUMUX/dune-grid/dune/grid/io/file/dgfparser/dgfparser.hh:28,
from /Applications/DUMUX/dune-grid/dune/grid/io/file/dgfparser/dgfyasp.hh:8,
from /Applications/DUMUX/dumux/dumux/io/grid/gridmanager_yasp.hh:30,
from /Applications/DUMUX/dumux/test/freeflow/shallowwater/poiseuilleflow/main.cc:36:
/Applications/DUMUX/dune-grid/dune/grid/io/file/gmshreader.hh:963:17: note: declared here
963 | static void read (Dune::GridFactory<Grid>& factory,
| ^~~~
```3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1056Add gridGeometry.update(gridView)2022-07-15T18:47:22ZTimo Kochtimokoch@math.uio.noAdd gridGeometry.update(gridView)In a recent update in dune the mappers got a new `update(gridView)` interface reflecting the value semantics of grid views introduced some time ago. In the same way we should also add `gridView` then to the `gridgeometry.update` function...In a recent update in dune the mappers got a new `update(gridView)` interface reflecting the value semantics of grid views introduced some time ago. In the same way we should also add `gridView` then to the `gridgeometry.update` function.
In our current usage it's slightly strange to write
```
GridGeometry gridGeometry(gridView);
gridGeometry.update(gridView);
```
So I suggest to change the behaviour of the grid geometry so that it already calls update in the constructor. We could add a special policy to be able to choose not initialize the grid geometry in the constructor if this is really needed.
As update gets a new signature, deprecation would be fairly easy I think if we accept that using the old interface `update()` means that you initialize the grid geometry twice (and you get a deprecation warning)3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1057Document Python generator classes2023-12-13T11:13:09ZTimo Kochtimokoch@math.uio.noDocument Python generator classesFollow-up from "Feature/python main file"
The following discussion from !2681 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2681#note_62023):
> ...Follow-up from "Feature/python main file"
The following discussion from !2681 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2681#note_62023):
> we have to document these generators very well because it's the interface used from the Python side. But I think that's a separate task for when the bindings are a bit more stable...https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1058No OPM modules in GitLab CI containers2021-07-23T06:41:20ZBernd FlemischNo OPM modules in GitLab CI containersThe containers for the CI apparently don't contain opm-common and opm-grid so that the cornerpoint functionality is not tested.The containers for the CI apparently don't contain opm-common and opm-grid so that the cornerpoint functionality is not tested.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1059Use dynamic polymorphism in mpfa interaction volumes2023-12-13T11:13:09ZDennis GläserUse dynamic polymorphism in mpfa interaction volumesThe mpfa code is super difficult to understand. One thing that makes it additionally complicated is the fact that it allows for two different interaction volume types to be used - because some mpfa methods (like mpfa-l) cannot handle bou...The mpfa code is super difficult to understand. One thing that makes it additionally complicated is the fact that it allows for two different interaction volume types to be used - because some mpfa methods (like mpfa-l) cannot handle boundary conditions properly. So one approach is to use the o-method at boundaries.
To make it possible to implement such thing, one can define to use different interaction volumes around tagged vertices (default: boundary). But this introduces a bunch of if/else branches that clutter the code.
We could probably get rid of this by using dynamic polymorphism on interaction volumes. The computations to construct an interaction volume and to compute transmissibilities are typically expensive, so I guess the runtime penalty should not matter. We should give this a try to make the mpfa code (at least a tiny bit) less frustrating to read.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1060Simplify localView2021-08-17T17:59:39ZTimo Kochtimokoch@math.uio.noSimplify localViewWe write a lot of code like this
```cpp
auto fvGeometry = localView(gridGeometry);
fvGeometry.bind(element);
```
How about introducing an overload
```cpp
auto localView(g, element) { auto view = g.localView(); view.bind(element); retu...We write a lot of code like this
```cpp
auto fvGeometry = localView(gridGeometry);
fvGeometry.bind(element);
```
How about introducing an overload
```cpp
auto localView(g, element) { auto view = g.localView(); view.bind(element); return view; }
```
so we can write instead (for most cases)
```cpp
auto fvGeometry = localView(gridGeometry, element);
```3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1061Disable or fix Python tests in CI for release 3.42021-07-28T10:03:33ZTimo Kochtimokoch@math.uio.noDisable or fix Python tests in CI for release 3.4The new Docker images enable the Python bindings in the full container (previously untested). The Python bindings are tested if Dune >= 2.8.
However due to a configuration issue the tests currently fail to run/compile. Help is on the way...The new Docker images enable the Python bindings in the full container (previously untested). The Python bindings are tested if Dune >= 2.8.
However due to a configuration issue the tests currently fail to run/compile. Help is on the way in !2681 but this is not going to be part of 3.4. Therefore we should probably just manually disable the Python tests in the CI config on master+release/3.4. Or if the problem is solved in !2681 soon, add the fix to the current CI config.3.4https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1062DuMux Day 28.07.20212021-10-27T08:31:49ZHanchuan WuDuMux Day 28.07.2021- [x] Test the extract module script @yue @hanchuan
- [x] Fix Python CI @timok #1061
- [x] Simplify localView with bind(element) @nedc #1060 !2736
- [x] First to modify the GridGeometry update interface @martins #1056
- [x] Discretiza...- [x] Test the extract module script @yue @hanchuan
- [x] Fix Python CI @timok #1061
- [x] Simplify localView with bind(element) @nedc #1060 !2736
- [x] First to modify the GridGeometry update interface @martins #1056
- [x] Discretization method as tag instead of enum @IvBu #1054
- [x] Consider enthalpy of vaporization for constant component (e.g. SimpleH2O) @heck #1013 #1015 (see #1092)
- [x] extrusionFactor should be a spatial parameter interface @felixw #1001 (moved to next dumux day)
- [x] #1000 @bernd (continued in next dumux day)
- [x] !2565 @Maziar (see #1092)
- [x] #970 @tschol (see #1092)
- [x] #959 @RoWin, @yue(see #1092)3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1063[ci][python] Implement test selection2021-08-27T06:26:57ZTimo Kochtimokoch@math.uio.no[ci][python] Implement test selectionPython tests are excluded in the normal pipeline (they don't require the `build` job and can run therefore run earlier). There is a separate `test` job for the Python tests. What's currently missing for these tests is a `select` mechanis...Python tests are excluded in the normal pipeline (they don't require the `build` job and can run therefore run earlier). There is a separate `test` job for the Python tests. What's currently missing for these tests is a `select` mechanism like for the C++ tests.
Since stuff in the Python code is just-in-time compiled it's not possible to know what header will be compiled without running the actual test.
I suggest to apply a heuristic and only run Python tests if something changed in a file in `dumux/python` or `dumux/dumux/python`. If that is the case we run all Python tests. That way the Python tests are only run when a merge request changes something in the Python bindings. Unfortunately it can happen then that a change in the C++ headers breaks the bindings. But this hopefully doesn't happen since the interfaces used by the binding code have some backwards-compatibility assurance. If not we will get the failure in the next nightly build.
Python test take quite long because they build&test so it would be good to have this selection.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1064Extract module script CMake macros not considered2022-02-23T20:26:33ZTimo Kochtimokoch@math.uio.noExtract module script CMake macros not consideredThe extract module script does not consider cmake macros. So if you extract from a module that defines some cmake macros/functions and then use them, the extracted module will not find these functions because it shouldn't depend on its p...The extract module script does not consider cmake macros. So if you extract from a module that defines some cmake macros/functions and then use them, the extracted module will not find these functions because it shouldn't depend on its parent module anymore.
Maybe we can simply copy the cmake/modules folder (might need some renaming) of the module extracted from.3.5https://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/1066Documentation for python bindings2023-02-20T10:54:36ZTimo Kochtimokoch@math.uio.noDocumentation for python bindingsPython bindings are still experimental but we should
* Move pointers to Python installation setup to main readme
* Improve installation and test instructions
* think about how to generate docs for Python. Maybe have a look and follow wh...Python bindings are still experimental but we should
* Move pointers to Python installation setup to main readme
* Improve installation and test instructions
* think about how to generate docs for Python. Maybe have a look and follow what Dune does too. Sphinx is a popular tool for automated doc generation for Python.
* For automated docs we also need to decide on a docstring format (e.g. the google format understood by Sphinx)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1067Headercheck fails 3.42022-02-22T14:03:45ZTimo Kochtimokoch@math.uio.noHeadercheck fails 3.4Fix make headercheckFix make headercheck3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1068Change construction and update of MultiDomainFVGridGeometry2022-04-01T18:28:44ZMartin SchneiderChange construction and update of MultiDomainFVGridGeometryIn MR !2737 the construction of grid geometries is such that no further call of `update` is needed after construction. For some gg this requires to pass additional objects to the constructor. Therefore, the MultiDomainFVGridGeometry has ...In MR !2737 the construction of grid geometries is such that no further call of `update` is needed after construction. For some gg this requires to pass additional objects to the constructor. Therefore, the MultiDomainFVGridGeometry has to be changed such that the grid geometries of the sub-problems are set and not constructed within this class.3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1069[parameters] Specifying parameters without input file does not work2021-08-25T11:31:44ZKilian Weishaupt[parameters] Specifying parameters without input file does not workThe following does not work
```c++
int main(int argc, char** argv)
{
using namespace Dumux;
auto defaultParams = [] (Dune::ParameterTree& p) { p["Grid.UpperRight"] = "2 2";
...The following does not work
```c++
int main(int argc, char** argv)
{
using namespace Dumux;
auto defaultParams = [] (Dune::ParameterTree& p) { p["Grid.UpperRight"] = "2 2";
p["Grid.Cells"] = "20 20"; };
Dumux::Parameters::init(argc, argv, defaultParams);
Dumux::Parameters::print();
return 0;
}
```
The resulting parameter tree will be empty.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1070[io] Cake grid manager does not yield partioned grids in parallel2021-08-16T13:46:43ZKilian Weishaupt[io] Cake grid manager does not yield partioned grids in parallelRunning `mpirun -n 2 ./test_gridmanager_cake_alu test_gridmanager_cake.input -Grid.Name test` shows that
the grid manager returns two identical, non-partioned grids.
Is this the desired behavior?Running `mpirun -n 2 ./test_gridmanager_cake_alu test_gridmanager_cake.input -Grid.Name test` shows that
the grid manager returns two identical, non-partioned grids.
Is this the desired behavior?Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1071Tracer is not conserved2024-03-25T10:25:34ZBernd FlemischTracer is not conserved**Problem description:**
In a multi-phase setting, the amount of a tracer in one fluid phase is possibly not conserved from one time step to the next.
**Explanation:**
When solving the flow problem, the phase distribution usually chang...**Problem description:**
In a multi-phase setting, the amount of a tracer in one fluid phase is possibly not conserved from one time step to the next.
**Explanation:**
When solving the flow problem, the phase distribution usually changes. For example, the saturation in one cell increases. Since flow and tracer problems are decoupled, one should assume in this flow step that the added fluid doesn't contain tracer. For conserving the amount of tracer in each cell, the tracer concentration should be adapted to this change. While the concentration should be reduced in case of an increasing saturation, it stays the same and therefore the amount of tracer in the cell is increased. This is not corrected by the tracer solution step, as that step just redistributes the tracer according to the volume flux and the given (possibly wrong) concentration.
**How to reproduce it:**
Check out the branch `fix/tracer-concentration` and consider [test/porousmediumflow/tracer/conservation](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/fix/tracer-conservation/test/porousmediumflow/tracer/conservation). Comment the line
```cpp
equilibrateTracer(xOld, oldSaturation_, saturation_);
```
of `main.cc`.
**Possible fix:**
Equilibrate the tracer after each flow solve and before each tracer solve. To be discussed in !2767.X.Xhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1072Failure of richards benchmark2021-08-20T18:39:45ZTimo Kochtimokoch@math.uio.noFailure of richards benchmarkThere was a spurious failure of the Richards benchmark in the CI. No such failure had been previously observed in many runs. The job log is attached [job_log](/uploads/de092059c7504c36e9b73073c68aa798/job_log)
Seems to be quite a consis...There was a spurious failure of the Richards benchmark in the CI. No such failure had been previously observed in many runs. The job log is attached [job_log](/uploads/de092059c7504c36e9b73073c68aa798/job_log)
Seems to be quite a consistent failure ~~after !2736~~ when using the new runner on sal.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1073Dumux Day 25.08.20212021-10-26T17:49:31ZDennis GläserDumux Day 25.08.2021- [x] make progress on #885 (@martins)
- [x] #1047 (@DennisGlaeser)
- [x] !2792,!2793 (@melaniel)
- [x] !2708 (@timok)
- [x] !2734 (@nedc) (moved to next dumux day)
- [x] see #1062: @heck, @yue, @IvBu
- [x] all: test !2769 and report ...- [x] make progress on #885 (@martins)
- [x] #1047 (@DennisGlaeser)
- [x] !2792,!2793 (@melaniel)
- [x] !2708 (@timok)
- [x] !2734 (@nedc) (moved to next dumux day)
- [x] see #1062: @heck, @yue, @IvBu
- [x] all: test !2769 and report if test fails3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1074Spatialparams folder2022-02-14T15:47:13ZTimo Kochtimokoch@math.uio.noSpatialparams folderThe spatial parameter classes are located under material/spatialparams. I think this historically may have made sense when only porous media were considered. However, the spatial parameters are more general that. With parameters like `gr...The spatial parameter classes are located under material/spatialparams. I think this historically may have made sense when only porous media were considered. However, the spatial parameters are more general that. With parameters like `gravity` and `extrusionFactor` (see #1001) that are not necessarily connected to some material, we interpret the spatial parameters really just as (potentially) spatially varying parameter fields.
What would be a better place? `common/spatialparams`? Or just move the headers to the respective subfolders, i.e. porousmediumflow spatial params to `porousmediumflow` and porenetwork spatial params to `porenetwork` and so on?3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1075BaseGridGeometry Traits2022-10-25T14:05:19ZMartin SchneiderBaseGridGeometry TraitsIs there any reason why the type of the `Traits` class given as template argument to the `BaseGridGeometry` is not publicly available within this class? This would for example simplify checking if a class inherits from `BaseGridGeometry`...Is there any reason why the type of the `Traits` class given as template argument to the `BaseGridGeometry` is not publicly available within this class? This would for example simplify checking if a class inherits from `BaseGridGeometry`, without the need of any parameter pack.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1076Staggered draw grid preprocessor warning2021-08-27T11:02:35ZTimo Kochtimokoch@math.uio.noStaggered draw grid preprocessor warningDon't use `#warning` in staggered draw grid (pollutes the CI output). The gnuplot file will still be created, only the image cannot be produced, so an `std::cout` info (or nothing) is enough I think.Don't use `#warning` in staggered draw grid (pollutes the CI output). The gnuplot file will still be created, only the image cannot be produced, so an `std::cout` info (or nothing) is enough I think.3.5Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1077Consistent naming in test/references2021-09-30T17:31:43ZTimo Kochtimokoch@math.uio.noConsistent naming in test/referencesMake sure the references
* [ ] start with `test_` and end with `-reference.*`
* other rules?Make sure the references
* [ ] start with `test_` and end with `-reference.*`
* other rules?3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1078PrimaryVariablesSwitch::reset does not reset wasSwitched values2021-09-04T19:37:15ZTimo Kochtimokoch@math.uio.noPrimaryVariablesSwitch::reset does not reset wasSwitched valuesThe reset function uses resize which does not reset values in the vector that keeps track of switches privars
see !2812The reset function uses resize which does not reset values in the vector that keeps track of switches privars
see !28123.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1079Staggered geometry updated twice seems to differ from updating once2021-09-02T12:46:06ZTimo Kochtimokoch@math.uio.noStaggered geometry updated twice seems to differ from updating onceThis commit is identified as "causing" the bug. But I think it just makes it appear.
When using unmodified code the gridgeometry gets updated twice with this commit. This should not change anything but it does unfortunately.
```
commit ...This commit is identified as "causing" the bug. But I think it just makes it appear.
When using unmodified code the gridgeometry gets updated twice with this commit. This should not change anything but it does unfortunately.
```
commit f67d6b2c9f6f1e3cd582577c2bf88ef0e0294932
Author: Martin Schneider <martin.schneider@iws.uni-stuttgart.de>
Date: Wed Jul 28 13:52:27 2021 +0200
[gg] Call update function already in constructor
dumux/discretization/basegridgeometry.hh | 1 +
dumux/discretization/box/fvgridgeometry.hh | 8 ++++++--
dumux/discretization/cellcentered/mpfa/fvgridgeometry.hh | 4 ++++
dumux/discretization/cellcentered/tpfa/fvgridgeometry.hh | 4 ++++
dumux/discretization/staggered/fvgridgeometry.hh | 4 ++++
5 files changed, 19 insertions(+), 2 deletions(-)
```
Result:
I get a scaling of two of all the entries in the gradient block of Stokes when the geometry is updated twice.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1080Investigate alternatives for weak_ptr in coupling manager2021-10-18T20:59:11ZTimo Kochtimokoch@math.uio.noInvestigate alternatives for weak_ptr in coupling managerThe following discussion from !2823 should be addressed:
- [ ] @DennisGlaeser started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2823#note_66168): (+4 comments)
> is the call to `this...The following discussion from !2823 should be addressed:
- [ ] @DennisGlaeser started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2823#note_66168): (+4 comments)
> is the call to `this->problem()` expensive because of the `if` check I guess? But compared to the subsequent call to `bindCouplingContext` that `if` should be negligible, no? If that's the case, I would be in favor of removing the comment and the if/else block for clearer code.
>
> I'm not sure how expensive the call to `weakPtr.expired` is, but an `if` statement is generated here as well by checking if the context is empty..
In general the problem interface of the base coupling manager pops up in performance analysis so it's a non-negligible overhear involved with obtaining a reference to a sub-problem. We could switch to a raw pointer which has the only disadvantage that you get a segfault instead of a runtime error in case the you use the coupling manger _after_ the problem is destroyed. I the usual setup that should never occur. But it might occur in some future configurations...
Note that shared_ptr is not an option because that would lead to a cyclic dependency and a memory leak.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1081Port free flow tests to new staggered2022-03-30T08:19:13ZBernd FlemischPort free flow tests to new staggeredTests should be ported one by one in separate merge requests. In principle, the new implementations are available in !2201. Move changes from `problem_new.hh` and `main_new.hh` to `problem.hh`, `main.hh`and `properties.hh`. Be careful as...Tests should be ported one by one in separate merge requests. In principle, the new implementations are available in !2201. Move changes from `problem_new.hh` and `main_new.hh` to `problem.hh`, `main.hh`and `properties.hh`. Be careful as !2201 is already partly outdated. !2830 is a port based on the current master.
- [x] `navierstokes/angeli`: @heck
- [x] `navierstokes/channel/1d`: @RoWin
- [x] `navierstokes/channel/pipe`: @hanchuan
- [x] `examples/liddrivencavity`: @nedc3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1082DuMux Day 29.09.20212021-10-27T08:33:25ZBernd FlemischDuMux Day 29.09.2021- [x] #1081: @heck, @RoWin, @hanchuan, @nedc, @yue (some tests are still failing but require features/fixes for new staggered, so Dumux task is done for now)
- [x] #1054: @IvBu
- [x] #1074, #1001: @DennisGlaeser starts, @nedc joins (see ...- [x] #1081: @heck, @RoWin, @hanchuan, @nedc, @yue (some tests are still failing but require features/fixes for new staggered, so Dumux task is done for now)
- [x] #1054: @IvBu
- [x] #1074, #1001: @DennisGlaeser starts, @nedc joins (see #1092)
- [x] #1000: @bernd check how to include for new staggered
- [x] #1077, !2837 : @farid
- [x] #885: @martins (see #1092)
- [x] #996: @Maziar (see #1092)
- [x] Darcy-Stokes new staggered: @timok
- [x] #966: @emmert (continued in next dumuxday)
- [x] #983: @mathis (see #1092)
- [x] dumux-lecture: @holle, @stefaniekiemle (continued ndd)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1083[test] Gridmanager test fails with Dune `master`2021-10-06T09:31:09ZMathis Kelm[test] Gridmanager test fails with Dune `master`Recently the gridmanager test `test_gridmanager_dgf_ug_parallel` has been failing when run with Dune `master` through CI. Discrepancies appear to include element marker assignments, see the output below. Is this a core issue with our tes...Recently the gridmanager test `test_gridmanager_dgf_ug_parallel` has been failing when run with Dune `master` through CI. Discrepancies appear to include element marker assignments, see the output below. Is this a core issue with our test or just some runtime property that should not be tested (in this manner).
```
Rank 0: Reading parameters from file test_gridmanager_dgf.input.
Rank 1: Reading parameters from file test_gridmanager_dgf.input.
UGGridParameterBlock: Parameter 'closure' not specified, using default: 'GREEN'.
UGGridParameterBlock: Parameter 'copies' not specified, using default: 'NO'.
UGGridParameterBlock: Parameter 'closure' not specified, using default: 'GREEN'.
UGGridParameterBlock: Parameter 'copies' not specified, using default: 'NO'.
UGGridParameterBlock: Parameter 'closure' not specified, using default: 'GREEN'.
UGGridParameterBlock: Parameter 'copies' not specified, using default: 'NO'.
UGGridParameterBlock: Parameter 'closure' not specified, using default: 'GREEN'.
UGGridParameterBlock: Parameter 'copies' not specified, using default: 'NO'.
Fuzzy comparison...
Comparing /builds/dumux-repositories/dumux/test/references/gridmanager-co2-quad-element-reference.vtu and /builds/dumux-repositories/dumux/build-cmake/test/io/gridmanager/s0002-co2_ug_parallel-element-00000.pvtu
... with a maximum relative error of 0.01 and a maximum absolute error of 1.5e-07*max_abs_parameter_value.
Sorting vtu by coordinates...
Data differs in parameter: elementMarker
Difference is too large: 100.00% -> between: 3.0 and 0.0 Info for elementMarker: max_abs_parameter_value=3.0 and min_abs_parameter_value=0.0.
Fuzzy comparison done (not equal)
Fuzzy comparison...
Comparing /builds/dumux-repositories/dumux/test/references/gridmanager-co2-quad-element-reference-refined.vtu and /builds/dumux-repositories/dumux/build-cmake/test/io/gridmanager/s0002-co2_ug_parallel-element-00001.pvtu
... with a maximum relative error of 0.01 and a maximum absolute error of 1.5e-07*max_abs_parameter_value.
Sorting vtu by coordinates...
Data differs in parameter: elementMarker
Difference is too large: 100.00% -> between: 3.0 and 0.0 Info for elementMarker: max_abs_parameter_value=3.0 and min_abs_parameter_value=0.0.
Fuzzy comparison done (not equal)
Fuzzy comparison...
Comparing /builds/dumux-repositories/dumux/test/references/gridmanager-co2-quad-vertex-reference.vtu and /builds/dumux-repositories/dumux/build-cmake/test/io/gridmanager/s0002-co2_ug_parallel-vertex-00000.pvtu
... with a maximum relative error of 0.01 and a maximum absolute error of 1.5e-07*max_abs_parameter_value.
Sorting vtu by coordinates...
Data differs in parameter: vertexData
Difference is too large: 100.00% -> between: 96.0 and 0.0 Info for vertexData: max_abs_parameter_value=3793.0 and min_abs_parameter_value=0.0.
Fuzzy comparison done (not equal)
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1084mpnc does not work with brineair fluidsystem2022-04-14T07:51:49ZTheresa Schollenbergermpnc does not work with brineair fluidsystemIf the brineair fluidsystem is used with the mpnc model you get a singular matrix immediately. The 2pncmin/nonisothermal test works using the brineair fluidsystem and the 2pncmin model.
On the branch fix/mpnc-with-brineair you can find t...If the brineair fluidsystem is used with the mpnc model you get a singular matrix immediately. The 2pncmin/nonisothermal test works using the brineair fluidsystem and the 2pncmin model.
On the branch fix/mpnc-with-brineair you can find this test now using the mpnc model. Here the mineralization part is removed. On the branch fix/mpncmin-with-brineair the test is using a mpncmin model. In both cases a singular matrix is obtained immediately.3.5Theresa SchollenbergerTheresa Schollenbergerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1085Staggered problem dirichlet/neumann return convention2022-04-01T13:00:12ZTimo Kochtimokoch@math.uio.noStaggered problem dirichlet/neumann return conventionThe following discussion from !2852 should be addressed:
- [ ] @martins started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2852#note_66920): (+2 comments)
> I aggree and I also think ...The following discussion from !2852 should be addressed:
- [ ] @martins started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2852#note_66920): (+2 comments)
> I aggree and I also think that there should be some direct traits mechanics.
>
> However, this issue might also exist for user-defined functions. I think the discrepancy here is between how we actually think of `PrimaryVariables` and how it is used in the test cases. So maybe using for both situations the name `PrimaryVariables` might be confusing?
The staggered Navier-Stokes code expects full velocities fluxes (in all dimensions) from the problem. This makes it easier to set boundary conditions for when complex treatment due to the discretization is needed in the background.
The correct sizes are now statically asserted !2852. Still the problem uses the type names `PrimaryVariables` and `NumEqVector` but means different types than the corresponding types specified via properties and used in the assembly. This makes this error-prone and confusing. Moreover, it is currently necessary to overload all such functions inherited from the `FVProblem` because the type information is not properly propagated into the base class.
One solution would be to overload the functions in the navierstokes problem and actually use different type names such as `Velocity` and `MomentumFlux` so that it's completely clear that these are different.
TODO: how does this generalize to more complex models? Is it always only the momentum model affected by this? How to treat the difference with the mass model since both are currently implemented in one class with template switches.
- [x] Also change numeq confusion in boundarytypes and modeltraits for the momentum problem -> !30373.5Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1086Extractline data script does not work with pvpython 5.7.0, Kudo Paula2021-12-16T10:47:41ZHanchuan WuExtractline data script does not work with pvpython 5.7.0, Kudo Paula<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
The `extractlinedata.py` does not work with `Paraview` (`pvpython`) under version 5.7.0.
The following error me...<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
The `extractlinedata.py` does not work with `Paraview` (`pvpython`) under version 5.7.0.
The following error messages would be obtained:
```
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/paraview/servermanager.py", line 1312, in SetData
position = self.Available.index(values)
ValueError: 'Line' is not in list
```
**How to reproduce it (as minimally and precisely as possible)**:
Run `pvpython extractlinedata.py -f REVScale_BJS_darcy-00000.vtu -p1 0.0 0.0 0.0 -p2 0.0 0.5 0.0` for the attached file [REVScale_BJS_darcy-00001.vtu](/uploads/326e8bf4bac1444043e1a0df83e4d717/REVScale_BJS_darcy-00001.vtu). In principle, with `pvpython` version 5.7.0 use `extractline.py` in `bin` folder to extract a line data from any `vtu/vtp` file can reproduce the error.
**PS**:
The script works with Paraview 5.9.0 and some old versions.Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1087VelocityOutput doesn't work correctly for Richards2021-10-20T16:55:17ZRoman WinterVelocityOutput doesn't work correctly for Richards**Bug report**
**What happened / Problem description**:
When running a Richards test with `vtkWriter.addVelocityOutput(....);`
and `AddVelocity = true` in `params.input` Paraview crashes while loading the files, because the gas velocit...**Bug report**
**What happened / Problem description**:
When running a Richards test with `vtkWriter.addVelocityOutput(....);`
and `AddVelocity = true` in `params.input` Paraview crashes while loading the files, because the gas velocity is -nan.
**What you expected to happen**:
The gas velocity should not be written out for the Richards model.
**How to reproduce it (as minimally and precisely as possible)**:
Add
`[Vtk]
AddVelocity = true`
to a Richards test i.e. richards/nonisothermal/conduction/params.inputRoman WinterRoman Winterhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1088Shallow water turbulent diffusion wrong mobility2021-12-13T20:51:15ZLeopold StadlerShallow water turbulent diffusion wrong mobility
**Problem description:**
The computation of the momentum exchange in `ShallowWaterViscousFlux` is wrong for "waterfall" cases when no direct water to water connection exists at the interface there should be no transport/flux of moment...
**Problem description:**
The computation of the momentum exchange in `ShallowWaterViscousFlux` is wrong for "waterfall" cases when no direct water to water connection exists at the interface there should be no transport/flux of momentum.
![viscfluxbug](/uploads/2369ebbd8cda8995fe39d8dab91c427f/viscfluxbug.png)
**Explanation:**
In the actual code the flux is computed as:
```
uViscousFlux = turbViscosity * averageDepth * gradU;
vViscousFlux = turbViscosity * averageDepth * gradV;
```
With `averageDepth` as harmonic average between the water depths from the left/right side. Later the momentum flux is limited by a mobility (depending on water depths). For the `ShallowWaterFlux` the same mobility term is applied to limit the water flux, but not the momentum flux. For the `ShallowWaterFlux` the limiting works since the water depth is taken based on the hydrostatic reconstruction.
**Possible fix:**
Instead of `averageDepth` the connected water surface:
```math
h_{interface} = max[min(z_{left} + h_{left}, z_{right} + h_{right}) - max(z_{left},z_{right}), 0.0]
```
can be used. No limiting will be needed.Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1089Remove deprecation warning from extended source stencil2021-10-26T14:56:22ZTimo Kochtimokoch@math.uio.noRemove deprecation warning from extended source stencil```
/builds/dumux-repositories/dumux/dumux/multidomain/embedded/couplingmanager1d3d_average.hh:138:9: warning: ‘decltype(auto) Dumux::CouplingManager<Traits>::curSol() [with Traits = Dumux::MultiDomainTraits<Dumux::Properties::TTag::Tiss...```
/builds/dumux-repositories/dumux/dumux/multidomain/embedded/couplingmanager1d3d_average.hh:138:9: warning: ‘decltype(auto) Dumux::CouplingManager<Traits>::curSol() [with Traits = Dumux::MultiDomainTraits<Dumux::Properties::TTag::TissueBox, Dumux::Properties::TTag::BloodFlowBox>]’ is deprecated: This function returns a Dune::MultiTypeBlockVector<SubDomainSolutionVector&, ....> (i.e. storing references). Use curSol(domainIdx) to get a reference to the corresponding subdomain solution vector. Will be removed after 3.5 [-Wdeprecated-declarations]
138 | extendedSourceStencil_.evalAdditionalDomainDerivatives(*this, domainI, localAssemblerI, this->curSol(), A, gridVariables);
| ^~~~~~~~~~~~~~~~~~~~~~
```
The extended source stencil receives `this->curSol()` but this is actually not necessary since it already gets `*this`. Internally it currently only uses the solution of domainI which can be obtained from the couplingmanager.
TODO
- deprecated old interface
- implement interface without curSol3.5Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1090CI fails with new Python stuff in dune-common master2021-11-23T08:14:45ZTimo Kochtimokoch@math.uio.noCI fails with new Python stuff in dune-common masterThe modules don't seem to be found anymore. At least not with the same method as before...The modules don't seem to be found anymore. At least not with the same method as before...3.5Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1091Central place for geometry intersection tolerances2023-12-13T11:13:09ZDennis GläserCentral place for geometry intersection tolerancesIn the `GeometryIntersection` algorithms we define a `baseEps_ = 1.5e-7` in every specialization. I think it could be beneficial to define the tolerance once in a central place. Something like
```
template<typename ctype>
class Precisio...In the `GeometryIntersection` algorithms we define a `baseEps_ = 1.5e-7` in every specialization. I think it could be beneficial to define the tolerance once in a central place. Something like
```
template<typename ctype>
class Precision
{
public:
static ctype relativeTolerance()
{ return 1.5e-7; } // or get from parameter tree as a static const variable? or from configure step?
};
```
Personally, I would be in favor of the solution with the parameter tree such that users can change the tolerance via the input file.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1092Dumux Day 27.10.2021 / 24.11.2021 / 26.01.20222022-03-30T08:57:09ZKilian WeishauptDumux Day 27.10.2021 / 24.11.2021 / 26.01.2022- [x] Spatial Params #1107 @DennisGlaeser @IvBu ( + test port: @bernd, @mathis, @stefaniekiemle, @RoWin)
- [x] #996 @Maziar
- [ ] #966 @DennisGlaeser
- [ ] #970 @tschol @hommel
- [x] #883 @farid
- [x] #1094 @RoWin
- [x] #1088 @leopo...- [x] Spatial Params #1107 @DennisGlaeser @IvBu ( + test port: @bernd, @mathis, @stefaniekiemle, @RoWin)
- [x] #996 @Maziar
- [ ] #966 @DennisGlaeser
- [ ] #970 @tschol @hommel
- [x] #883 @farid
- [x] #1094 @RoWin
- [x] #1088 @leopold.stadler
- [ ] #1084 @heck @hanchuan
- [x] #1064 @hanchuan
- [x] #959 @yue
- [ ] #1101 @yue
- [x] #1015 @heck @hommel
- [x] !2930 @nedc (#807, #538) scheduled for 3.6
- [x] !2926 @nedc (#1081) scheduled for 3.6
- [ ] !2986 @mathis @nedc
- [x] #1120 @utz
- [x] #1113 @yue
- [x] !3006 !2984 #1112 #1111 @nedc
- [x] !2994 @ackerm
- [x] !3000 @bernd
- [ ] dumux-docker-ci!9 @bernd3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1093Baseepsilon hardcoded for geometry module2021-10-27T19:46:52ZTimo Kochtimokoch@math.uio.noBaseepsilon hardcoded for geometry moduleThe base epsilon is hardcoded in many places to 1.5e-7, which might be useful for double precision geometry stuff. However it would be nice to change depending on the type and for each application separately.The base epsilon is hardcoded in many places to 1.5e-7, which might be useful for double precision geometry stuff. However it would be nice to change depending on the type and for each application separately.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1094Search and remove deprecated stuff2021-11-02T16:43:57ZKilian WeishauptSearch and remove deprecated stuff- [x] run a grep search for deprecation warnings and remove code if needed ("after 3.4")
- [x] check lecture, etc- [x] run a grep search for deprecation warnings and remove code if needed ("after 3.4")
- [x] check lecture, etcRoman WinterRoman Winterhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1095Pore network model needs dune-foamgrid to work2021-11-02T17:17:19ZMaziar VeyskaramiPore network model needs dune-foamgrid to workAdd dune-foamgrid to the dune-module list which needs to be installed in the [Dumux webpage](https://dumux.org/installation/) or mention it separately that to use pore network model you need to install dune-foamgrid.Add dune-foamgrid to the dune-module list which needs to be installed in the [Dumux webpage](https://dumux.org/installation/) or mention it separately that to use pore network model you need to install dune-foamgrid.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1096Check consistency of FluidSystems2023-12-13T11:13:09ZKilian WeishauptCheck consistency of FluidSystemsWe should go through all FluidSystems and check them for consistency (assumptions, simplifications, etc.)
There seems to be a lot of copy and paste without physical justification.
Idea: separate FluidSystems into more "general" ones and...We should go through all FluidSystems and check them for consistency (assumptions, simplifications, etc.)
There seems to be a lot of copy and paste without physical justification.
Idea: separate FluidSystems into more "general" ones and "application"-type FS which are specifically tailored to a certain application.
Changes will likely cause failing tests so this needs discussion. Could be done on a Dumux Day or by a very talented Hiwi.Tim JupeTim Jupehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1097Harmonic mean and other helpers in spatial params2022-03-31T12:29:52ZTimo Kochtimokoch@math.uio.noHarmonic mean and other helpers in spatial paramsThe spatialparams contain an harmonic mean function and a special averaging for tensors. Why is this part of the spatial params interface? It should probably be out-sourced.
The following discussion from !2888 should be addressed:
- [ ...The spatialparams contain an harmonic mean function and a special averaging for tensors. Why is this part of the spatial params interface? It should probably be out-sourced.
The following discussion from !2888 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2888#note_67814): (+3 comments)
> Is this still used? Seems like the wrong place for such a function.3.5Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1098[ci] Run website ci when a merge happens2022-02-14T12:22:33ZDavid Werner[ci] Run website ci when a merge happensThe documentation on website needs updated then. Also consider don't merge if the build fails. The daily build job of website can be removed if implemented.The documentation on website needs updated then. Also consider don't merge if the build fails. The daily build job of website can be removed if implemented.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1099[test] test_md_embedded_1d3d_1p2c_richards2c fails to build2021-11-01T09:45:54ZRa Ry[test] test_md_embedded_1d3d_1p2c_richards2c fails to buildOS: Ubuntu 20.04
Dune Modules: v2.8
Dumux: v3.4
Fresh install of Dumux v3.4; using Dune modules v2.8, including dune-foamgrid and dune-uggrid.
The latter are required to build "test_md_embedded_1d3d_1p2c_richards2c", which failed to bu...OS: Ubuntu 20.04
Dune Modules: v2.8
Dumux: v3.4
Fresh install of Dumux v3.4; using Dune modules v2.8, including dune-foamgrid and dune-uggrid.
The latter are required to build "test_md_embedded_1d3d_1p2c_richards2c", which failed to build:
make test_md_embedded_1d3d_1p2c_richards2c
All other tests ran OK in folder: /multidomain/embedded
Attached is a zip archive containing the test error log and the dumux v3.4 install log.
The error log is quite long and I cannot interpret why that test build fails.
For some reason module dune-uggrid is mentioned.
Which version of dune-uggrid is needed to run "test_md_embedded_1d3d_1p2c_richards2c"?
As a side note, dumux-course builds "test_md_embedded_1d3d_1p2c_richards2c", but fails to run because module dune-uggrid is missing. This I understand.
I came to this specific test, as it was recommended in Koch2017a (dumux-pub repository web page):
https://git.iws.uni-stuttgart.de/dumux-pub/Koch2017a
> If you want to work with root models in DuMu<sup>x</sup> check out the newest DuMu<sup>x</sup> version at (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux.git) which includes and updated and better documented version of the root-soil interaction models (an updated version of example of the tracer example from the paper can be found [here](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/tree/master/test/multidomain/embedded/1d3d/1p2c_richards2c).
[ERRORS_Tests.zip](/uploads/d5d99313a8c31250f6e0fe3a576830d4/ERRORS_Tests.zip)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1100Add documentation on website on how to install external dependencies so that ...2022-02-23T18:20:51ZTimo Kochtimokoch@math.uio.noAdd documentation on website on how to install external dependencies so that Dune finds themSome explanations on build system, how to work with dunecontrol, on the website would be nice.Some explanations on build system, how to work with dunecontrol, on the website would be nice.3.5Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1101Update parameterlist2022-06-01T11:42:34ZTimo Kochtimokoch@math.uio.noUpdate parameterlistThe parameter list is now generated by a new script !2933. The script still reports several errors that should be fixed. Some of these result from wrong configuration in the new input file. Some of them are related to old parameter which...The parameter list is now generated by a new script !2933. The script still reports several errors that should be fixed. Some of these result from wrong configuration in the new input file. Some of them are related to old parameter which have been removed. Some of them are related to new parameters.
The script can be run by
```
python3 bin/doc/generate_parameterlist.py
```
This creates a log file with all info in the current directory.
Debug output can be added to the log file by running
```
DUMUX_DEBUG_LEVEL=Debug python3 bin/doc/generate_parameterlist.py
```3.5Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1102[python] Add doc for Python with Dune 2.92022-06-02T17:27:11ZTimo Kochtimokoch@math.uio.no[python] Add doc for Python with Dune 2.93.6https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1103[python] Find out how to package with Dune 2.92023-12-13T11:13:09ZTimo Kochtimokoch@math.uio.no[python] Find out how to package with Dune 2.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1104Multiphase/ Component specific Dispersion tensors2022-03-31T14:16:48ZNed ColtmanMultiphase/ Component specific Dispersion tensors<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Complex Dispersion tensors
**What does this feature / why does DuMux need it**:
Currently there are di...<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Complex Dispersion tensors
**What does this feature / why does DuMux need it**:
Currently there are dispersion fluxes implemented for compositional-flow(1pnc) and tracer models. The dispersion tensors are either user defined, or defined using the scheidegger dispersion relation, which is velocity dependent.
Other dispersion tensors exist, and can be component specific or dependent on state and phase conditions. These dipsersion tensors could be added to make the dispersion interface useable in complex cases.3.5Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1105(Velocity-dependent) Dispersion for tpfa2023-11-24T08:25:06ZTimo Kochtimokoch@math.uio.no(Velocity-dependent) Dispersion for tpfaConstant dispersion tensor are implemented in !2921.
Velocity-dependency (fully-implicit) could be realized by using a cell velocity-based scheme and harmonic averaging of the dispersion tensor on the face. But this extends the flux ste...Constant dispersion tensor are implemented in !2921.
Velocity-dependency (fully-implicit) could be realized by using a cell velocity-based scheme and harmonic averaging of the dispersion tensor on the face. But this extends the flux stencil of a single flux to the element stencil required for the velocity reconstruction.
Follow-up from #320 and !2921.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1106[test][cleanup] Remove test description above problem/spatialparams/main (in-...2022-04-07T12:50:35ZTimo Kochtimokoch@math.uio.no[test][cleanup] Remove test description above problem/spatialparams/main (in-code doc)In many (system-)tests, we have a description of the scenario on top of the problem and sometimes running instructions. Such a description is only required for documented examples. In the test folder, it tends to easily become outdated o...In many (system-)tests, we have a description of the scenario on top of the problem and sometimes running instructions. Such a description is only required for documented examples. In the test folder, it tends to easily become outdated or it's often wrong in the first place due to copy and paste. Running the test is already documented by CMakeLists.txt and should be done through CTest anyways. The description easily becomes outdated if the test is extended or changes.
This suggests removing any such "documentation" in the test folder.3.5Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1107Put overload detection helpers in separate header2022-02-15T15:24:52ZDennis GläserPut overload detection helpers in separate headerThe spatial parameters implementations perform some inspections on which functions are overloaded by the user, using some helper structs defined in the `Detail` namespace. The issue is that the poroelastic spatial params need the same ki...The spatial parameters implementations perform some inspections on which functions are overloaded by the user, using some helper structs defined in the `Detail` namespace. The issue is that the poroelastic spatial params need the same kind of checks as the 1p porous medium spatial params. But if the poroelastic spatial params header defines the helpers again with the same name we run into a redefinition error in case an application includes both headers (e.g. in multidomain simulations). We can of course name the struct differently, but then we violate the DRY rule. Currently, the poroelastic spatial params include the 1p spatial params header only to get those details.
One solution would be to put the detail helpers in some extra header that can be included by all spatial params implementations.
On the other hand, maybe we are missing a level in our spatial params class hierarchy, because the poroelastic spatial params redefine a whole bunch of things related to porosity, inertVolumeFractions, etc. from the 1p spatial params. Maybe we should have porous medium-related (not porousmediumFLOW) spatial params that both 1p and poroelastic can derive from.3.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1108Face data and restart for new staggered2023-12-13T11:13:09ZKilian WeishauptFace data and restart for new staggeredIn the old staggered implementation, it was possible to write out face data (velocities) as points to a `.vtp` file.
This file could then be used for restarting simulations.
Visualizing and analyzing these point-wise face velocities in ...In the old staggered implementation, it was possible to write out face data (velocities) as points to a `.vtp` file.
This file could then be used for restarting simulations.
Visualizing and analyzing these point-wise face velocities in ParaView is rather cumbersome, so I introduced an `IntersectionWriter` for the new staggered such that the element edges actually appear graphically (looks like the `Surface With Edges` representation in ParaView).
However, this class seems overly complicated and furthermore, interior edges always appear twice (one intersection per element). The latter point may make it difficult to use the resulting `.vtp` files for restarting a simulation, unless we also always write out the `dofIdx`, too.
How should we proceed here?
(a) Stick to the "old" point-wise solution?
(b) Further improve the intersection writer such that it can also be used within our `VTKOutputModule`?
(c) Write out `.vtp` files manually (as done with the points), where the element edges are treated as 2d/1d elements
I guess (c) would be the most readable solution. One could try to figure out the element connectivity stuff for VTK "manually" (don't know yet how complicated that is) or one could use `FoamGrid` which would make the implementation really simple (at the cost of
an additional dependency).https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1109More user-friendly way of specifying initial conditions for mpnc2022-07-28T08:25:54ZDennis GläserMore user-friendly way of specifying initial conditions for mpncSince mpnc uses fugacities, users have to use a constraint solver to compute them from whatever initial conditions they want to have in terms of saturations, mole fractions, etc...
If one wants single-phasic initial conditions (without ...Since mpnc uses fugacities, users have to use a constraint solver to compute them from whatever initial conditions they want to have in terms of saturations, mole fractions, etc...
If one wants single-phasic initial conditions (without dissolved components), and one does for instance:
```cpp
GetPropType<TypeTag, Properties::FluidState> fs;
// ... set stuff in fluid state -> I want single-phasic state
// use constraint solver to compute fugacities
using MiscibleMultiPhaseComposition = Dumux::MiscibleMultiPhaseComposition<Scalar, FluidSystem>;
typename FluidSystem::ParameterCache paramCache;
MiscibleMultiPhaseComposition::solve(fs, paramCache);
```
one gets already nonzero mole fractions of the non-present phases in the initially present phase, because `MiscibleMultiPhaseComposition` seems to assume that all phases are present. One therefore has to use `ComputeFromReferencePhase` in this case, which to me does not seem obvious.
We should maybe either rethink our assumptions in `MiscibleMultiPhaseComposition`, or give the user some hints/warnings/info... This could be achieved by adding an "impl" layer which we use internally, while `MiscibleMultiPhaseComposition`, etc. forward to the impl but give some descriptive information message. For instance:
"This uses the assumption that all phases are present. For single-phase situations, use ..."Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1110I want to contribute (open for suggestions)2022-04-18T11:53:27ZLarissa BrencherI want to contribute (open for suggestions)Hello,
as a part of the lecture [Simulation Software Engineering](https://simulation-software-engineering.github.io/homepage/) I would like to contribute something to DuMuX. I am enrolled in the Master's Degree of SimTech (specialized i...Hello,
as a part of the lecture [Simulation Software Engineering](https://simulation-software-engineering.github.io/homepage/) I would like to contribute something to DuMuX. I am enrolled in the Master's Degree of SimTech (specialized in (multiphase, multiscale) flow simulation in porous media with some additional knowledge about Machine Learning/Deep Learning).
The aim of the aforementioned lecture is for each student to contribute to an open source project within the framework of an individual challenge, in order to work through one entire contribution cycle "in real life" following all the steps. The contribution's focus is more on learning the procedures of working on a larger project. Consequently, it does not necessarily need to be on a scientific topic, e.g. implementing a tutorial or fixing bugs, but can also be a task like writing something for the documentation or homepage etc.
Since I don't just want to e.g. fix some typos, I am open to suggestions in order to contribute something useful to DuMuX :grin:https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1111Use new spatialparams interface to add spatialparams for freeflow models2022-02-09T13:23:06ZTimo Kochtimokoch@math.uio.noUse new spatialparams interface to add spatialparams for freeflow modelsSee !2888See !28883.5https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1112Move porenetwork spatialparams to porenetwork folder2022-02-09T13:23:05ZTimo Kochtimokoch@math.uio.noMove porenetwork spatialparams to porenetwork folderSee !2888
- [x] In the boundary coupled ff_pnm tests, try to reuse the psuedo 3D spatial params used in the psuedo 3d channel freeflow testsSee !2888
- [x] In the boundary coupled ff_pnm tests, try to reuse the psuedo 3D spatial params used in the psuedo 3d channel freeflow tests3.5