dumux-repositories issueshttps://git.iws.uni-stuttgart.de/groups/dumux-repositories/-/issues2024-02-16T08:57:42Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1356[test][porousmediumflow][2pncmin][nonisothermal] Neumann flux at top has to b...2024-02-16T08:57:42ZAnna Mareike Kostelecky[test][porousmediumflow][2pncmin][nonisothermal] Neumann flux at top has to be adaptedWithin in the [non-isothermal 2pncmin test](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2pncmin/nonisothermal?ref_type=heads) a few things for the Neumann BC at the top should be adapted:...Within in the [non-isothermal 2pncmin test](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2pncmin/nonisothermal?ref_type=heads) a few things for the Neumann BC at the top should be adapted:
1. In the upwind term ([here](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/problem.hh?ref_type=heads#L239)) the reference mass-specific density of air is used, but there should be the molar density of air.
With the mass-specific density $\rho = 1.2 ~\text{kg}/\text{m}^3$ and the molar mass of air $M=28.96 * 10^{-3} ~\text{kg}/\text{mol}$, we have $\rho^{\text{mol}}=\rho/M \approx 41,44 ~\text{mol}/\text{m}^3$
2. The density of air (e.g. [here](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/problem.hh?ref_type=heads#L231)) for the liquid flux should generally be harmonic averaged if CCFV is used with TPFA and arithmetic averaged for box method (as flux for liquid phase is purely diffusive and we do upwind just for advective processes)
3. The comments for "gas flux in/out" ([here](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/problem.hh?ref_type=heads#L246)) should be switched.
4. For the energy exchange the harmonic mean of the effective heat conductivity within the porous medium and the heat conductivity within the free-flow should be taken. (Note, that applying the same harmonic averaging for the diffusion coefficient is counter-productive as the effective diffusion coefficient, using Millington-Quirk, is small for highly water-saturated porous media. This would lead to a lower evaporation rate for highly water saturated porous-media in comparison to high evaporation rates for almost dried-out porous media. Hence, only the pure binary diffusion coefficient is taken - It could be scaled e.g. linearly with the porosity)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1325[porousmediumflow][2pncmin][nonisothermal] Use current permeability for Neuma...2024-01-10T08:34:05ZSimon Grether[porousmediumflow][2pncmin][nonisothermal] Use current permeability for Neumann gas fluxIn the [non-isothermal 2pncmin test](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2pncmin/nonisothermal?ref_type=heads) the reference permeability is used in the [problem](https://git.iws....In the [non-isothermal 2pncmin test](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2pncmin/nonisothermal?ref_type=heads) the reference permeability is used in the [problem](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/problem.hh?ref_type=heads) for calculating the Neumann flux of the component air. However, the permeability changes during the simulation due to the precipitation of salt.
Therefore, I propose to use the current permeability here:
`...`
`*volVars.permeability()`
`...`
`*volVars.permeability()`
`...`Anna Mareike KosteleckyAnna Mareike Kosteleckyhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1324[porousmediumflow][2pncmin][nonisothermal] Use mass fractions for diffusive N...2023-12-13T14:15:55ZSimon Grether[porousmediumflow][2pncmin][nonisothermal] Use mass fractions for diffusive Neumann fluxIn the [non-isothermal 2pncmin test](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2pncmin/nonisothermal?ref_type=heads) the mole fraction is used in the [problem](https://git.iws.uni-stutt...In the [non-isothermal 2pncmin test](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2pncmin/nonisothermal?ref_type=heads) the mole fraction is used in the [problem](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/problem.hh?ref_type=heads) for calculating the diffusive Neumann flux of the evaporation rate. However, when using a mass-averaged reference system, the mass fraction should be used for the difference quotient of diffusive fluxes.
Therefore, I propose the following correction:
`static const Scalar massFracRefH2O = getParam("FreeFlow.RefMassFracH2O");`
`...`
`const Scalar massFracH2OInside = volVars.massFraction(gasPhaseIdx, H2OIdx);`
`...`
`if (massFracH2OInside - massFracRefH2O > 0)`
`...`
`* (massFracH2OInside - massFracRefH2O)`
`...`
`* (massFracH2OInside - massFracRefH2O)`
`...`
Moreover, the reference value for the free-flow in the [input-file](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/params.input?ref_type=heads) should be converted into the mass fraction.Anna Mareike KosteleckyAnna Mareike Kosteleckyhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1301[porousmediumflow][2pncmin] Use correct time step size for problem file2023-12-11T14:53:06ZAnna Mareike Kostelecky[porousmediumflow][2pncmin] Use correct time step size for problem fileIn the [2pncmin](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal) test the time step size is used in the [problem](https://git.iws.uni-stuttgart.de/dumux-repositories/du...In the [2pncmin](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal) test the time step size is used in the [problem](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/problem.hh?ref_type=heads#L331) for calculating the amount of precipitating salt per time. For this the time step is set in the [main file](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/2pncmin/nonisothermal/main.cc?ref_type=heads#L140) at the beginning of each new time step. For this case this works so far.
However, @Simon Grether pointed out that for simulations where the [newton solver](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/nonlinear/newtonsolver.hh?ref_type=heads#L340) does not converge and hence reduces the time step, this is not correctly implemented. This modification of the time step is not accounted for in the problem file, when just setting the time step once in the time loop.
Hence this would be nice to adapt already in the 2pncmin test, such that if this test case is copied and gets modified there is one possible error source less.3.9https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1209[cleanup] Use new ignore field feature of the test driver2023-03-14T18:01:36ZTimo Kochtimokoch@math.uio.no[cleanup] Use new ignore field feature of the test driverThe dumux test script https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/bin/testing/runtest.py gets with !3353 an option to ignore fields (`--ignore "fielda" "fieldb"`). This can be used instead of setting a very hi...The dumux test script https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/bin/testing/runtest.py gets with !3353 an option to ignore fields (`--ignore "fielda" "fieldb"`). This can be used instead of setting a very high zero threshold to make the intent clear.
Example: `rank` should be ignored when comparison parallel and sequential files.
Example implementation: `test/freeflow/shallowwater/dambreak/CMakeLists.txt`3.7Harsha Pallamharsha.pallam@iws.uni-stuttgart.deHarsha Pallamharsha.pallam@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1180New Compositional Staggered2023-10-26T08:13:30ZNed ColtmanNew Compositional Staggeredmentioned in #1115
Implementation and ported tests addressed in !2986 .
New Analytical solution and convergence test implemented in !3044 . Also implemented for old staggered in !3561 .
Troubleshooting branch: `feature/misc_naviersto...mentioned in #1115
Implementation and ported tests addressed in !2986 .
New Analytical solution and convergence test implemented in !3044 . Also implemented for old staggered in !3561 .
Troubleshooting branch: `feature/misc_navierstokesnc` .
Using this issue to collect all of the ideas and progress we have made (the MRs are not organized for this)3.8Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1126Add CO2 benchmark case?2023-12-13T11:13:09ZTimo Kochtimokoch@math.uio.noAdd CO2 benchmark case?Is it possible/feasible to add the benchmark case Holger Class et al , A benchmark study on problems related to CO2 storage in geologic formations, Computational Geosciences 13 (2009), no. 4, 409–434.
into the test suite?Is it possible/feasible to add the benchmark case Holger Class et al , A benchmark study on problems related to CO2 storage in geologic formations, Computational Geosciences 13 (2009), no. 4, 409–434.
into the test suite?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/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/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/997Add non-Darcy flow upscaling example2022-09-08T07:44:35ZTimo Kochtimokoch@math.uio.noAdd non-Darcy flow upscaling exampleThe following discussion from !2420 should be addressed:
- [x] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2420#note_54324): (+2 comments)
> I would be awesome to have a...The following discussion from !2420 should be addressed:
- [x] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2420#note_54324): (+2 comments)
> I would be awesome to have a test that computes permeability in one direction for a network e.g. extracted from the Berea sandstone sample for different pressure gradients. Then we could do at least a qualitative comparison with Muljadi et al. https://doi.org/10.1016/j.advwatres.2015.05.019 (essentially reproduce one of the plots of El-Zehairy et al. https://doi.org/10.1016/j.advwatres.2019.103378)3.6Maziar VeyskaramiMaziar Veyskaramihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/987[test] Extend tests for 1d3d intersection2021-04-11T12:08:10ZTim Jupe[test] Extend tests for 1d3d intersectionIntersection tests for line-hexahedron, line-pyramid and line-prism are missing.Intersection tests for line-hexahedron, line-pyramid and line-prism are missing.3.4Tim JupeTim Jupehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/984Document if density and viscosity can be changed in freeflow tests2021-02-03T09:58:54ZMelanie LippDocument if density and viscosity can be changed in freeflow testsCurrently, there is free-flow tests which have LiquidDensity in there input file, but you can not change it (e.g. sincos). I think that we could
* adapt the test such that changes are possible
* throw a warning, or
* write a comment af...Currently, there is free-flow tests which have LiquidDensity in there input file, but you can not change it (e.g. sincos). I think that we could
* adapt the test such that changes are possible
* throw a warning, or
* write a comment after the repective variable in the input file.Melanie LippMelanie Lipphttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/982[cleanup] Remove implicit folder in test structure2021-01-20T09:21:54ZTimo Kochtimokoch@math.uio.no[cleanup] Remove implicit folder in test structureIn the test folder we group the test by model->implicit/sequential->case
However, only a few model have a sequential implementation (IMPES-like schemes).
I suggest to remove the implicit/sequential level. We can keep the sequential fold...In the test folder we group the test by model->implicit/sequential->case
However, only a few model have a sequential implementation (IMPES-like schemes).
I suggest to remove the implicit/sequential level. We can keep the sequential folders for those models where they exist. Or move sequential to test/sequential/ to signify that they are an entirely separate implementation.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/968Use gitlab ci for automated testing2021-04-29T09:49:22ZDennis GläserUse gitlab ci for automated testingIt could be useful to integrate build and test jobs into our ci such that one can conveniently let the runner test everything in a merge request. That makes it less probable that stuff gets merged that breaks anything.
I would suggest t...It could be useful to integrate build and test jobs into our ci such that one can conveniently let the runner test everything in a merge request. That makes it less probable that stuff gets merged that breaks anything.
I would suggest to create pipelines for commits to master, tags and merge requests. Regarding automatic start of the pipelines, I would suggest the following strategy:
- add manual trigger for build & test pipeline for merge requests. Especially on Dumux days, when there is a lot of pushing to open MRs, we would trigger a lot of unneccesary pipeline runs, I guess. I would prefer a manual trigger here.
- automatic start of the pipeline for master and tags. The first is useful as you always see which commit destroyed the pipeline on master. This is of course a bit redundant as one maybe already triggered and verified a successful pipeline on the branch just before merging. In some cases, it could still break on master if someone didn't rebase before running the pipeline. For safety reasons, I think it could be nice to always test master.
I am thinking of some default setup (Dune2.7, release opts) to be used, but we could schedule one nightly build with different setups as on buildbot. However, that is basically currently done on buildbot, so this would only make sense if we want to stop using buildbot at one point. So, this is probably irrelevant for now.
Another point is that our build and test times are quite long, and it would be nice to build and run only those tests that are necessary, at least for MRs. Here's a first idea for merge requests:
- 1 use `git diff-tree -r --name-only $CI_COMMIT_SHA $CI_MERGE_REQUEST_TARGET_BRANCH_SHA` to list the modified files
- 2 use `ctest -N` to list all tests we currently have
- 3 do something like in `extractmodulepart.sh` to determine required headers of the tests
- 4 select those tests which use any of the files obtained in (1)
- 5 compile and run those tests only
point (2) and (3) might be expensive. We could also store that info in a json file or so, but on the other hand, that file would need to be up-to-date, and maybe someone adds a test in the MR thats not in the file. Or, maybe someone adds a dependency with the MR. For now, I'd opt for always doing that, should be much less expensive than building and running a lot of tests.
_Docker images_
Dune's Docker images for testing are built here: https://gitlab.dune-project.org/docker/ci
It would be nice to reuse some of the base images they use there. Also I propose a `dumux-docker-ci` project that
* automatically builds the dumux test images in GitLabCI (services images from Dune, e.g. `buildah` can be hopefully reused for that purpose)
* pushes the images to the `dumux-docker-ci` container registry (see gitlab-ci.yaml in the dune project)
* reuse base images from Dune if possible
_BuildBot_
Our current images are in https://git.iws.uni-stuttgart.de/timok/dumux-bb-ci
and our current buildbot setup is here: https://git.iws.uni-stuttgart.de/timok/buildbot-master
_Multi module setup_
After new commits in dumux we also want to trigger builds of dumux-lecture (maybe dumux-course). There is also (a bit outdated) dumux-testing with the first system test for dumux. See !2396.
_Coverage reports_
The coverage report is generated here in a weekly build. It already uses GitlabCI.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-coverage3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/966[ci] Test installation scripts in CI2022-05-04T14:28:20ZTimo Kochtimokoch@math.uio.no[ci] Test installation scripts in CIWe could add a Docker container for testing the new installation script and maybe the install external in the CI.We could add a Docker container for testing the new installation script and maybe the install external in the CI.3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/958[doc] Document the tests2020-11-04T18:17:59ZFarid Mohammadi[doc] Document the testsIn the old version (<=3.2) of the handbook, it was pointed out that the available test cases had been documented:
```tex
An overview over the available test cases can be found in the class documentation \url{http://www.dumux.org/document...In the old version (<=3.2) of the handbook, it was pointed out that the available test cases had been documented:
```tex
An overview over the available test cases can be found in the class documentation \url{http://www.dumux.org/documentation.php}.
```
Apparently, that is not the case. Let's document the test cases.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-lecture/-/issues/22heavyoil exercises need reference solutions for realistic testing2023-03-16T13:15:41ZNed Coltmanheavyoil exercises need reference solutions for realistic testingThe following exercises are not tested against reference solutions:
- [ ] mm_sagd
- [ ] mm_sagd_cyclic
- [ ] mm_sagd_cyclic_hystThe following exercises are not tested against reference solutions:
- [ ] mm_sagd
- [ ] mm_sagd_cyclic
- [ ] mm_sagd_cyclic_hystYue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/915[test][cleanup] Remove or reduce exception handlers2020-10-02T08:12:11ZTimo Kochtimokoch@math.uio.no[test][cleanup] Remove or reduce exception handlersWe usually have a list of exception handlers like this at the end of each main file
```cpp
catch (Dumux::ParameterException &e)
{
std::cerr << std::endl << e << " ---> Abort!" << std::endl;
return 1;
}
catch (Dune::DGFException ...We usually have a list of exception handlers like this at the end of each main file
```cpp
catch (Dumux::ParameterException &e)
{
std::cerr << std::endl << e << " ---> Abort!" << std::endl;
return 1;
}
catch (Dune::DGFException & e)
{
std::cerr << "DGF exception thrown (" << e <<
"). Most likely, the DGF file name is wrong "
"or the DGF file is corrupted, "
"e.g. missing hash at end of file or wrong number (dimensions) of entries."
<< " ---> Abort!" << std::endl;
return 2;
}
catch (Dune::Exception &e)
{
std::cerr << "Dune reported error: " << e << " ---> Abort!" << std::endl;
return 3;
}
catch (...)
{
std::cerr << "Unknown exception thrown! ---> Abort!" << std::endl;
return 4;
}
```
Small cleanup point:
* Catch all exceptions as `const&`
Actual discussion points:
* The default terminate handler usually provides the exception message as well so manually catching exception is not necessary
* In case of the `Dune::DGFException` we actually add more information so that is a sensible use of the exception handler. However not every test will have the chance to throw a `Dune::DGFException` because not every test uses DGF mesh files.
* In the other cases we just print the exception message which is what the default handler does anyway on most system AFAIK
* Catching `(...)` suppresses the exception message completely. This is a code smell. When such an exception occurs you have to manually remove the line to be able to read the exception message.
Suggestions:
* Try what is printed when we remove exception handlers completely (probably we don't need handlers at all for tests)
* Think about how to reduce handlers to a minimum
* Remove default catch case `(...)`
Note:
These comments are specifically for tests. If you have some Dumux application you might want to add exception handlers to gracefully exit out of an exception situation.3.3Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/858Put property definitions in tests in separate header (tests and lecture)2021-04-03T22:57:08ZNed ColtmanPut property definitions in tests in separate header (tests and lecture)Follow up from #648.
To make another step away from the problem-does-everything-mentality that was common (and a necessary evil) in dumux 2,
we plan on putting the property definitions into a separate header.
Previous work accomplish...Follow up from #648.
To make another step away from the problem-does-everything-mentality that was common (and a necessary evil) in dumux 2,
we plan on putting the property definitions into a separate header.
Previous work accomplished in #648:
* Separate properties into `properties.hh` for the examples (!1933)
* Separate properties into `properties.hh` for the dumux-course#24
Current goals:
* [x] Separate properties into `properties.hh` for the dumux-lecture dumux-lecture#18
* [ ] Separate properties into `properties.hh` for the tests
This doesn't have to be in one go. If someone edits a test anyway feel free to do this change as well.3.4Martin SchneiderMartin Schneider