dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2023-02-19T16:18:47Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1155How to make the Dumux day more interesting2023-02-19T16:18:47ZMaziar VeyskaramiHow to make the Dumux day more interesting**Challenges a developer may face:**
- Some issues/merge requests are not descriptive enough. That could demotivate the developer to work on them.
- The discussion about some issues becomes too technical during the Dumux day meeting. Th...**Challenges a developer may face:**
- Some issues/merge requests are not descriptive enough. That could demotivate the developer to work on them.
- The discussion about some issues becomes too technical during the Dumux day meeting. That can be frightening to others with different area of expertise.
- Fear of failure deters people from contributing to unfamiliar issues.
- No solid/detailed description of some parts of the code.
- Strict guidelines
**The collected ideas:**
- The issues/merge requests should give more details and describe the issue in a proper way.
- When the discussion becomes so technical that concerns only a part of the group during the Dumux day main meetings, it should be interrupted and continued only by the interested people in a separate meeting.
- Dumux day is about learning things other than your own area. To realize that goal as well as to help those who their fear of failure prevent them to contribute, we can assign a task not to a single person but to a small group of people (2 or 3 persons). The group should consist of more experienced and less experienced members.
- After clarifying what each part of the code aims to do, we can add a description for developers to the handbook and at least cover the classes which are used in the main file.
- Another idea is to record or write down the tutorials given by experienced members of the group and keep them for the new members joining us in future.
- Every body can develop and implement their code in a separate module. However, if they want to integrate the module in the Dumux, they must follow the guidelines. By doing so, we prevent inconsistency and bugs in the future. We recommend to use the guidelines even in your private module. In addition, following the guidelines in the code could be seen as a learning process which improves the programming skills.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/463Rethink isothermal/mineralization type tags2018-03-19T13:15:14ZDennis GläserRethink isothermal/mineralization type tagsIn order to realize non-isothermal models, type tags inherit from the non-isothermal type tag and one has to set the properties IsothermalIndices, IsothermalNumEq etc. The actual types/values are then determined by the non-isothermal typ...In order to realize non-isothermal models, type tags inherit from the non-isothermal type tag and one has to set the properties IsothermalIndices, IsothermalNumEq etc. The actual types/values are then determined by the non-isothermal type tag.
Alternatively, one could also directly set the non-isothermal types (e.g. EnergyIndices<OnePIndices>), because the current way neither saves code nor does it improve readability. Since mineralization models use a similar pattern, in non-isothermal mineralization models it is particularly difficult to see which type is set/used.
Also, we would get rid of all properties like IsothermalIndices, IsothermalVolumeVariables, ..., NonMineralizationVtkOutputFields, NonMineralizationVolumeVariables ...3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1203[ci] fix ci concurrent runs2023-03-20T10:55:34ZDavid Werner[ci] fix ci concurrent runsDiclaimer: this is not a DuMux issue but I have no idea, where to put problems with the ci-configuration.
The concurrency parameter of gitlab-runner larger than one can be a trouble maker as several processes work within one environmen...Diclaimer: this is not a DuMux issue but I have no idea, where to put problems with the ci-configuration.
The concurrency parameter of gitlab-runner larger than one can be a trouble maker as several processes work within one environment and can write each others resources. See [https://docs.gitlab.com/ee/ci/runners/configure_runners.html#handling-concurrency
](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#handling-concurrency
). The configuration switches are also documented in [https://docs.gitlab.com/runner/configuration/advanced-configuration.html
](https://docs.gitlab.com/runner/configuration/advanced-configuration.html
).
There is in our setting interaction with the slurm system status. A python script checks periodically how many slurm jobs are running and writes out a parameter adapted gitlab-runner config file.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/804[staggered] Matrix block arrangement does not comply with literature standard2020-03-31T11:18:09ZKilian Weishaupt[staggered] Matrix block arrangement does not comply with literature standardPapers dealing with solvers for saddlepoint problems (like the incompressible Navier-Stokes equations, [example](https://epubs.siam.org/doi/abs/10.1137/16M1076770)) usually define the block matrix as
```math
M = \begin{pmatrix}
A & B...Papers dealing with solvers for saddlepoint problems (like the incompressible Navier-Stokes equations, [example](https://epubs.siam.org/doi/abs/10.1137/16M1076770)) usually define the block matrix as
```math
M = \begin{pmatrix}
A & B^T\\
B & C
\end{pmatrix}
```
where $`A`$ is the block for the derivatives of the momentum balance equation residuals w.r.t velocity ("velocity block")
and $`C`$ is is the block for the derivatives of the mass balance equation residuals w.r.t pressure ("pressure block").
For incompressible fluids, $`C`$ is zero.
However, the multitype blockmatrix in Dumux for staggered problems looks like this:
```math
M = \begin{pmatrix}
C & B^T\\
B & A
\end{pmatrix}
```
which causes confusion and requires special care, e.g, for the implementation of the Uzawa solver !1827
I suggest we adapt the matrix structure such that the velocity block is on the upper left. Are there any concerns / objections?3.2Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1154Add high-level documentation on the main concepts in Dumux2024-03-25T10:09:45ZDennis GläserAdd high-level documentation on the main concepts in DumuxI propose a new structure for the High-Level-Design Document (HLDD).
[HLD_Proposal.md](/uploads/613c0e4e889894693fbe5f2611d6538c/HLD_Proposal.md)
After reviewing more sources, I think we mixed here High-Level and Architecture and genera...I propose a new structure for the High-Level-Design Document (HLDD).
[HLD_Proposal.md](/uploads/613c0e4e889894693fbe5f2611d6538c/HLD_Proposal.md)
After reviewing more sources, I think we mixed here High-Level and Architecture and general Documentation. This could lower the pain of potential double documentation.
One could take the old HLD Branches/MR and:
1. Filter for HLDD
2. Take architectural parts such as interfaces and use this for Architectural Documentation
3. If something is now left behind and interesting think about adding it to the normal Documentation
It was decided to use the diagram added in !3755 as a starting point.
Each class here gets two to three sentences. Not more.
----
#### From here on the old Issue.
----
On Dumux Day, 25th of May, we said that it could be good to have such high-level docu somewhere (e.g. in the handbook?). This could describe generic concepts like grid geometry (is actually nicely described in the last Dumux paper), grid variables, etc...
Current status of this issue is related to !3406 <br>
If you want to work on the high_level_documentation: <br>
For each file you are working on: <br>
- Create a branch from !3406
- Create a MR to !3406
- When you are happy with the description of the class merge that branch in !3406 and tick of the box here. Afterwards tag yourself.Also include the MR number. <br>
Thank you in advance! <br>
Main problem that needs to be resolved: <br>
Doxygen move everything that is included in a group to that group.
One needs to find a way to have high-level docu in the groups while still having a monolithic one source high-level docu.
General approach to tackle this:
1st Describe entities that are modular
- In easy words, possible usage and interface to other entities
- Is this entity necessary to run a simulation
2nd Describe non modular entities
- In easy words, possible usage and interface to other entities
- Is this entity necessary to run a simulation
- Highlight dependencies and why they are necessary
3rd Find out and show how they are interconnected
- Highlight if this entity is necessary (i.e., green vs. red)
The following entities should be modular:
- [ ] Grid @IvBu !3621
- [ ] GridManager @IvBu (review: @DennisGlaeser) !3623
- [ ] Discretization Method
- [ ] GridGeometry @IvBu !3645
- [ ] GridView @kaiw
- [ ] FVElementGeometry
- [ ] VtkOutputModule @kaiw
- [ ] IOFields @kaiw !3587
- [ ] Solver @nedc (review: @leonidas) !3588
- [ ] NonLinearSolver @nedc
- [ ] NewtonLoop @nedc
- [ ] linearPDEsolver @nedc
- [ ] LinearSolver @nedc
- [ ] TimeLoop @kaiw
- [ ] LocalResidual @leonidas @mathis @kaiw
The following entities are not modular:
- [ ] Problem @kaiw
- [ ] BoundaryTypes
- [ ] PrimaryVariables
- [ ] Indices
- [ ] SolutionVector @kaiw
- [ ] NumEqVector
- [ ] GridVariables @leonidas @DennisGlaeser
- [ ] GridVolumeVariables @leonidas @DennisGlaeser
- [ ] Assembler @leonidas @mathis @kaiw
- [ ] localAssembler @leonidas @mathis @kaiw
- [ ] CouplingManager
- [ ] FluidSystem @leonidas
- [ ] FluidState @leonidas
- [ ] FluidMatrix ?
- [ ] SpatialParams @kaiw
General remarks and details about accessing data
- [ ] VolumeVariables @leonidas
- [ ] FluxVariablesCache @leonidas
- [ ] Element
- [ ] GlobalPosition
- [ ] ElementVolumeVariables @leonidas @DennisGlaeser
- [ ] ElementFaceVariables @leonidas
- [ ] ElementFluxVariablesCache @leonidas
- [ ] ControlVolume
- [ ] ControlVolumeFace
- [ ] SubControlVolume
- [ ] SubControlVolumeFace
General remarks on property system
- [ ] TypeTag
- [ ] Traits
- [ ] Model @kaiw !3583.9Leon KeimLeon Keimhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1065Raise dependency to dune >= 2.82021-10-19T06:34:38ZTimo Kochtimokoch@math.uio.noRaise dependency to dune >= 2.8For release 3.5 I suggest to raise the Dune requirement to 2.8 (which will be released shortly). I suggest this now simply to decrease a bit of maintenance cost. For example we can drop testing against dune 2.7 for the master branch. Som...For release 3.5 I suggest to raise the Dune requirement to 2.8 (which will be released shortly). I suggest this now simply to decrease a bit of maintenance cost. For example we can drop testing against dune 2.7 for the master branch. Some version checks can be removed.
* __Agree?__ Click thumbs up :thumbsup:
* __Disagree?__ Write comment below3.5Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1030Two unreachable code sections2021-05-27T21:24:08ZChristoph GrüningerTwo unreachable code sectionsClang 12 warns about two code section, which are not reachable. Often, this is a sign that the code behaves different from what the programmer expected. In other words, it could be a bug or it could be some overcautious code.
Do you mi...Clang 12 warns about two code section, which are not reachable. Often, this is a sign that the code behaves different from what the programmer expected. In other words, it could be a bug or it could be some overcautious code.
Do you mind having a look?
```
[ 30%] Building CXX object test/material/fluidsystems/CMakeFiles/test_fluidsystems.dir/test_fluidsystems.cc.o
In file included from /usr/include/c++/11/cassert:44,
from /home/gruenich/dune/complete/dune-common/dune/common/parallel/mpihelper.hh:7,
from /home/gruenich/dune/complete/dumux/dumux/common/parameters.hh:36,
from /home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh:31,
from /home/gruenich/dune/complete/dumux/test/material/fluidsystems/checkfluidsystem.hh:40,
from /home/gruenich/dune/complete/dumux/test/material/fluidsystems/test_fluidsystems.cc:28:
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh: In static member function ‘static constexpr int Dumux::FluidSystems::BrineCO2<Scalar, CO2Table, H2OType, Policy>::BrineAdapterPolicy::compIdx(int) [with Scalar = double; CO2Table = Dumux::HeterogeneousCO2Tables::CO2Tables; H2OType = Dumux::Components::SimpleH2O<double>; Policy = Dumux::FluidSystems::BrineCO2DefaultPolicy<false>]’:
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh:181:70: warning: statement will never be executed [-Wswitch-unreachable]
181 | assert(brineCompIdx == VariableSalinityBrine::H2OIdx || brineCompIdx == VariableSalinityBrine::NaClIdx);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh: In static member function ‘static constexpr int Dumux::FluidSystems::BrineCO2<Scalar, CO2Table, H2OType, Policy>::BrineAdapterPolicy::compIdx(int) [with Scalar = double; CO2Table = Dumux::HeterogeneousCO2Tables::CO2Tables; H2OType = Dumux::Components::H2O<double>; Policy = Dumux::FluidSystems::BrineCO2DefaultPolicy<false>]’:
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh:181:70: warning: statement will never be executed [-Wswitch-unreachable]
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh: In static member function ‘static constexpr int Dumux::FluidSystems::BrineCO2<Scalar, CO2Table, H2OType, Policy>::BrineAdapterPolicy::compIdx(int) [with Scalar = double; CO2Table = Dumux::HeterogeneousCO2Tables::CO2Tables; H2OType = Dumux::Components::TabulatedComponent<Dumux::Components::H2O<double>, true>; Policy = Dumux::FluidSystems::BrineCO2DefaultPolicy<false>]’:
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh:181:70: warning: statement will never be executed [-Wswitch-unreachable]
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh: In static member function ‘static constexpr int Dumux::FluidSystems::BrineCO2<Scalar, CO2Table, H2OType, Policy>::BrineAdapterPolicy::compIdx(int) [with Scalar = double; CO2Table = Dumux::HeterogeneousCO2Tables::CO2Tables; H2OType = Dumux::Components::TabulatedComponent<Dumux::Components::H2O<double>, true>; Policy = Dumux::FluidSystems::BrineCO2DefaultPolicy<false, true>]’:
/home/gruenich/dune/complete/dumux/dumux/material/fluidsystems/brineco2.hh:181:70: warning: statement will never be executed [-Wswitch-unreachable]
```
```
[ 99%] Building CXX object examples/shallowwaterfriction/CMakeFiles/example_shallowwaterfriction.dir/main.cc.o
In file included from /home/gruenich/dune/complete/dumux/examples/biomineralization/material/fluidsystems/biominsimplechemistry.hh:62,
from /home/gruenich/dune/complete/dumux/examples/biomineralization/properties.hh:48,
from /home/gruenich/dune/complete/dumux/examples/biomineralization/main.cc:57:
/home/gruenich/dune/complete/dumux/examples/biomineralization/material/fluidsystems/biominsimplechemistry.hh: In static member function ‘static constexpr int Dumux::FluidSystems::BioMinSimpleChemistryFluid<Scalar, CO2Table, H2OType>::BrineAdapterPolicy::compIdx(int) [with Scalar = double; CO2Table = Dumux::ICP::CO2Tables; H2OType = Dumux::Components::TabulatedComponent<Dumux::Components::H2O<double>, true>]’:
/home/gruenich/dune/complete/dumux/examples/biomineralization/material/fluidsystems/biominsimplechemistry.hh:236:25: warning: statement will never be executed [-Wswitch-unreachable]
233 | assert(brineCompIdx == Brine::H2OIdx
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
234 | || brineCompIdx == Brine::NaIdx
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
235 | || brineCompIdx == Brine::ClIdx
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
236 | || brineCompIdx == Brine::CaIdx
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```3.4Hanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/968Use gitlab ci for automated testing2021-04-29T09:49:22ZDennis GläserUse gitlab ci for automated testingIt could be useful to integrate build and test jobs into our ci such that one can conveniently let the runner test everything in a merge request. That makes it less probable that stuff gets merged that breaks anything.
I would suggest t...It could be useful to integrate build and test jobs into our ci such that one can conveniently let the runner test everything in a merge request. That makes it less probable that stuff gets merged that breaks anything.
I would suggest to create pipelines for commits to master, tags and merge requests. Regarding automatic start of the pipelines, I would suggest the following strategy:
- add manual trigger for build & test pipeline for merge requests. Especially on Dumux days, when there is a lot of pushing to open MRs, we would trigger a lot of unneccesary pipeline runs, I guess. I would prefer a manual trigger here.
- automatic start of the pipeline for master and tags. The first is useful as you always see which commit destroyed the pipeline on master. This is of course a bit redundant as one maybe already triggered and verified a successful pipeline on the branch just before merging. In some cases, it could still break on master if someone didn't rebase before running the pipeline. For safety reasons, I think it could be nice to always test master.
I am thinking of some default setup (Dune2.7, release opts) to be used, but we could schedule one nightly build with different setups as on buildbot. However, that is basically currently done on buildbot, so this would only make sense if we want to stop using buildbot at one point. So, this is probably irrelevant for now.
Another point is that our build and test times are quite long, and it would be nice to build and run only those tests that are necessary, at least for MRs. Here's a first idea for merge requests:
- 1 use `git diff-tree -r --name-only $CI_COMMIT_SHA $CI_MERGE_REQUEST_TARGET_BRANCH_SHA` to list the modified files
- 2 use `ctest -N` to list all tests we currently have
- 3 do something like in `extractmodulepart.sh` to determine required headers of the tests
- 4 select those tests which use any of the files obtained in (1)
- 5 compile and run those tests only
point (2) and (3) might be expensive. We could also store that info in a json file or so, but on the other hand, that file would need to be up-to-date, and maybe someone adds a test in the MR thats not in the file. Or, maybe someone adds a dependency with the MR. For now, I'd opt for always doing that, should be much less expensive than building and running a lot of tests.
_Docker images_
Dune's Docker images for testing are built here: https://gitlab.dune-project.org/docker/ci
It would be nice to reuse some of the base images they use there. Also I propose a `dumux-docker-ci` project that
* automatically builds the dumux test images in GitLabCI (services images from Dune, e.g. `buildah` can be hopefully reused for that purpose)
* pushes the images to the `dumux-docker-ci` container registry (see gitlab-ci.yaml in the dune project)
* reuse base images from Dune if possible
_BuildBot_
Our current images are in https://git.iws.uni-stuttgart.de/timok/dumux-bb-ci
and our current buildbot setup is here: https://git.iws.uni-stuttgart.de/timok/buildbot-master
_Multi module setup_
After new commits in dumux we also want to trigger builds of dumux-lecture (maybe dumux-course). There is also (a bit outdated) dumux-testing with the first system test for dumux. See !2396.
_Coverage reports_
The coverage report is generated here in a weekly build. It already uses GitlabCI.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-coverage3.5Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/914[cleanup][style] Remove comment for header guard #endif2020-10-02T07:16:33ZTimo Kochtimokoch@math.uio.no[cleanup][style] Remove comment for header guard #endifWe sometimes add a comment to the header guards `#endif` like
```cpp
#endif // DUMUX_COMMON_BLA
```
I think this is unnecessary clutter and should be removed.
* The last `#endif` in header files is always the header guard `#endif`
* W...We sometimes add a comment to the header guards `#endif` like
```cpp
#endif // DUMUX_COMMON_BLA
```
I think this is unnecessary clutter and should be removed.
* The last `#endif` in header files is always the header guard `#endif`
* When copying a header file to create a new header it is easy to forget to change this comment
* When changing the header guard it is easy to forget to change this comment3.3Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/908[disc] Implementation of nonlinear fv schemes2023-02-22T08:57:22ZMartin Schneider[disc] Implementation of nonlinear fv schemeshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/887[doxygen] Exclude tests from doxygen?2020-05-27T11:13:44ZTimo Kochtimokoch@math.uio.no[doxygen] Exclude tests from doxygen?There is a number of arguments for simply removing the tests and all files in the test directory from doxygen
* The is a large amount of classes and files that distract from the actual classes and files in the Dumux core
* The code doc ...There is a number of arguments for simply removing the tests and all files in the test directory from doxygen
* The is a large amount of classes and files that distract from the actual classes and files in the Dumux core
* The code doc of the tests is poorly structured and doesn't help much
* Unclear which information gain we get from inclusion
* Our doxygen takes very long to compile and is quite large. This would help reducing it a bit (all dumux source files in the `dumux` folder are `231,172` lines total, all source files (`.hh`,`.cc`) in the `test` folder are `90,691` lines total; using `find . -name '*.hh' -o -name '*.cc' | xargs wc -l`)
* Much of the doc is not very good (while that is a problem in itself and the doc comments in the tests should actually be of high quality too, this is in the current stage really distracting). Even if it would be better the other points remain.
I navigated through the test docs in the online class documentation a bit. I didn't find anything useful in the `Test & Benchmarks` section. Any other opinions and arguments for keeping it?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/884Group arguments in assembly rountines2023-12-13T11:13:08ZTimo Kochtimokoch@math.uio.noGroup arguments in assembly rountinesI think fv element geometry, elem volvars and flux vars cache belong together in an element-wise assembly view point.
This could be expressed, e.g. by grouping these objects together. This might reduce the number of arguments for some fu...I think fv element geometry, elem volvars and flux vars cache belong together in an element-wise assembly view point.
This could be expressed, e.g. by grouping these objects together. This might reduce the number of arguments for some functions.
It's not completely trivial since there are several sensible combination possible.
I added a suggestion for an element view in !2125.
Suggestions for improvement? What that speaks for/against this?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/826Diffusion confusion (implementation)2024-03-25T10:24:47ZTimo Kochtimokoch@math.uio.noDiffusion confusion (implementation)We decided at some point that diffusion laws, e.g. `FicksLaw`, should compute all component fluxes in one go. This means two things
* we can now more efficiently compute the diffusive fluxes depending on the law (Fick / Maxwell-Stefan)
...We decided at some point that diffusion laws, e.g. `FicksLaw`, should compute all component fluxes in one go. This means two things
* we can now more efficiently compute the diffusive fluxes depending on the law (Fick / Maxwell-Stefan)
* `FicksLaw` now depends on the equation system
__Example:__
1. If I want to neglect diffusion in one phase, i can set the diffusion coefficient to zero. However, then the diffusive fluxes are still computed and I can throw them away in the custom local residual.
2. The Richards model is an immiscible two-phase two-component model but the air phase is never balanced. To integrate this in the current framework, we introduced `BalanceEqOpts::mainComponentIsBalanced(phaseIdx)` which is overloaded for the Richards model and used in Fick's law. In this case the dependency is actually there in the code in form of the additional dependency on `BalanceEqOpts`.
__One thought for a possible solution:__
If we would have a class `DiffusionFlux` replacing the current `FicksLaw`, then we could have a custom implementation `RichardsDiffusionFlux` which takes care of special requirements. `DiffusionFlux` would be a class on the level of `LocalResidual` only containing physics/equations. Internally it could use something like `FicksLaw` (new implementation that only contains the transmissibility part and discretization specifics) to compute the actual individual fluxes. `DiffusionFlux` may need to be specialized on the Law type (Fick / Maxwell-Stefan) but not the discretization.
Maybe, this would essentially be a code renaming / reordering. But that needs to be further investigated.X.Xhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/814Extract "constraint solvers" from volume variables2023-02-22T09:00:40ZTimo Kochtimokoch@math.uio.noExtract "constraint solvers" from volume variablesThe computation of the secondary variables from the primary variables is currently often coded inside the volume variables' `update` function. For the purpose of potential code reusage, readability, and testability it is IMO better to mo...The computation of the secondary variables from the primary variables is currently often coded inside the volume variables' `update` function. For the purpose of potential code reusage, readability, and testability it is IMO better to move this functionality to constraint solver classes. Even if the computation is quite simple. This is sometimes done in the form of the `computeFluidState` function. However, there is no general interface for all models.
If the constraint solver is in a separate class it is much easier to write unit tests. Volume variables have a lot of dependencies but the constraint solver can easily be tested and mock object are simple to construct for values obtained from e.g. the spatial params or some physical law.Yue Wangyue.wang@iws.uni-stuttgart.deYue Wangyue.wang@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/691Staggered Lingo Unification2019-04-26T07:09:20ZNed ColtmanStaggered Lingo UnificationWe waste a lot of time getting confused with terms like "lateral", "normal", "parallel", "staggered", "sub-", "frontal", "tangential", and there are of course a few remaining.
Many of these terms actually refer to the same thing. It wou...We waste a lot of time getting confused with terms like "lateral", "normal", "parallel", "staggered", "sub-", "frontal", "tangential", and there are of course a few remaining.
Many of these terms actually refer to the same thing. It would be nice to have rules for when each of these words is used, and to unify their use within the staggered discretization and the freeflow models.
Is this possible?3.1Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/654Allow C++172020-01-29T13:09:44ZTimo Kochtimokoch@math.uio.noAllow C++17I think quite some new features speak for allowing C++17. There are some compilers supporting all features, gcc 8 or gcc 7 (without std::filesystem), clang 8 or 5 (without std::filesystem). https://en.cppreference.com/w/cpp/compiler_supp...I think quite some new features speak for allowing C++17. There are some compilers supporting all features, gcc 8 or gcc 7 (without std::filesystem), clang 8 or 5 (without std::filesystem). https://en.cppreference.com/w/cpp/compiler_support. However, there seems to be no cray compiler.
Who is using the newest Dumux version on a platform without C++17 support?3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/595Add labels to tests2019-03-01T14:09:21ZTimo Kochtimokoch@math.uio.noAdd labels to testsEvery label creates a `build_<label>_tests` CMake target. Could be convenient to build e.g. all freeflow tests.
We should decide on labels. Tests can have multiple labels. !1235 introduces the "unit" test label for unit tests. !1289 adde...Every label creates a `build_<label>_tests` CMake target. Could be convenient to build e.g. all freeflow tests.
We should decide on labels. Tests can have multiple labels. !1235 introduces the "unit" test label for unit tests. !1289 added "multidomain" label for multidomain tests, !1291 introduces "freeflow" and "rans", while all "rans" test are also "freeflow".3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/470Extract GlobalPosition from Grid2018-05-03T14:38:00ZDennis GläserExtract GlobalPosition from GridThere are many places where the global position type is locally defined as:
```cpp
using GlobalPosition = Dune::FieldVector<Scalar, dimWorld>;
```
We maybe should think about extracting it from the Element (i.e. Element::Geometry::Glob...There are many places where the global position type is locally defined as:
```cpp
using GlobalPosition = Dune::FieldVector<Scalar, dimWorld>;
```
We maybe should think about extracting it from the Element (i.e. Element::Geometry::GlobalCoordinate) or from the sub-control
volumes and sub-control volume faces (which itself should have been given the type extracted from the grid).
This is especially important when Scalar and ctype are not the same.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/442Collection of not working tests / errors on buildbot2018-08-28T12:56:57ZSimon EmmertCollection of not working tests / errors on buildbotThis is a collection of problems we currently have on buildbot. It is collected here to help everyone in fixing the last tests.
The following fail:
**test flow
* [ ] test_2p_fracture_gravity_mpfa --> Data differs -> Dennis
* [ ] tes...This is a collection of problems we currently have on buildbot. It is collected here to help everyone in fixing the last tests.
The following fail:
**test flow
* [ ] test_2p_fracture_gravity_mpfa --> Data differs -> Dennis
* [ ] test_2p_fracture_gravity_tpfa --> Data differs in parameter: Sn, mobW, pc -> Dennis
* [ ] test_box3pwateroil -> was fixed but still fails on buildbot while passing on my notebook+desktop -> Bernd
* [ ] test_3d2pfvadaptive -> Error from solvers.hh "abs(h) < EPSILON" (see !1038)3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/378[doc] Differentiate between test, tutorial/documented, tutorial/undocumented2019-08-28T11:24:39ZTimo Kochtimokoch@math.uio.no[doc] Differentiate between test, tutorial/documented, tutorial/undocumentedCurrently we have two general "getting started tutorials", however many of our _tests_ are also thought of tutorials as they demonstrate a certain model.
I suggest to distinguish between _tests_ in the _test_ -folder that are specifical...Currently we have two general "getting started tutorials", however many of our _tests_ are also thought of tutorials as they demonstrate a certain model.
I suggest to distinguish between _tests_ in the _test_ -folder that are specifically designed to test certain features and are small/run rather fast, and _tutorials_ in the _tutorial_-folder that are designed to show a certain feature, e.g. how to use the tensor grid factory in a Richards model to refine towards the soil top. I further suggest to create two new subfolders _documented_ and _undocumented_ where all _documented tutorials_ have a detailed latex/markdown problem and feature description. In the future, a number of maybe 10 such documented tutorials would be nice. All tutorials in undocumented can potentially become documented in the future.
Of course tutorials should also tested by the automated build system.