dumux issues
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues
2023-02-19T16:18:47Z
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1155
How to make the Dumux day more interesting
2023-02-19T16:18:47Z
Maziar Veyskarami
How 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/1203
[ci] fix ci concurrent runs
2023-03-20T10:55:34Z
David Werner
[ci] fix ci concurrent runs
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 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/1154
Add high-level documentation on the main concepts in Dumux
2024-03-25T10:09:45Z
Dennis Gläser
Add high-level documentation on the main concepts in Dumux
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 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 !358
3.9
Leon Keim
Leon Keim
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/908
[disc] Implementation of nonlinear fv schemes
2023-02-22T08:57:22Z
Martin Schneider
[disc] Implementation of nonlinear fv schemes
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/826
Diffusion confusion (implementation)
2024-03-25T10:24:47Z
Timo Koch
timokoch@math.uio.no
Diffusion 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.X
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/814
Extract "constraint solvers" from volume variables
2023-02-22T09:00:40Z
Timo Koch
timokoch@math.uio.no
Extract "constraint solvers" from volume variables
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 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 Wang
yue.wang@iws.uni-stuttgart.de
Yue Wang
yue.wang@iws.uni-stuttgart.de
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1160
Prototypical math models for testing and as examples
2023-09-23T18:14:28Z
Timo Koch
timokoch@math.uio.no
Prototypical math models for testing and as examples
__Proposed feature__:
Many models in Dumux are relatively general and support many variations. This can also often be distracting both when understanding the code and when thinking about general concepts and structure. I propose (someth...
__Proposed feature__:
Many models in Dumux are relatively general and support many variations. This can also often be distracting both when understanding the code and when thinking about general concepts and structure. I propose (something similar has been proposed in dumux-repositories/dumux-course#17) to add some models with simple structure. For example:
* Poisson's equation
* Heat equation / Diffusion equation
* Wave equation
* Burger's equation
* Cahn-Hillard equation(s)
* (Multidomain) Incompressible Stokes equations
These prototypical models have the advantage that we can mostly assume scalar constant parameters (no need for fluid systems and so on), a small number of primary variables (e.g. 1 scalar), and simple local residual. Parameter names could be generic and not imply specific physics.
__The goal would be to use such models__
* to demonstrate (to users and developers) what the essential and minimal ingredients of a new model are
* to use them as starting point for new models
* to test if our software components work well in isolation and are small enough (testing). If they turn out not to be these models should be good candidates to think about better abstractions (development).
* to have simple demonstrators for teaching/outreach
* to use them directly as tools/components
__Open questions:__
* In which folder would such models go?
* Do we even want to hard-code some models for one spatial discretization scheme to further simplify?
_Examples where a procedure like this helped to improve the code:_
* #867
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/940
Clean incoporation of new time integration methods
2023-07-14T14:41:12Z
Dennis Gläser
Clean incoporation of new time integration methods
@timok, @bernd, @kweis, @martins and I are currently discussing/developing the incorporation of a generic time integration framework in Dumux. In general, time handling is currently problematic in Dumux and leads to a bug in MultiDomain ...
@timok, @bernd, @kweis, @martins and I are currently discussing/developing the incorporation of a generic time integration framework in Dumux. In general, time handling is currently problematic in Dumux and leads to a bug in MultiDomain (#792, #619).
The following work plan is currently envisioned to incorporate the features into an `Experimental` namespace while guaranteeing that the current features and tests on master still work:
1. [x] introduce new grid variables concept, where they represent the complete state of a simulation - thus, not only secondary but also primary variables and possibly a time level. (see !2285)
2. introduce new assembly concept <br>
- [x] make `NewtonSolver`, `PDESolver` accept both assemblers that assemble around given `SolutionVectors` or more generic `Variables` (see !2291) <br>
- [x] add time step methods (see !2296)<br>
- [ ] add generic version of `FVAssembler`, which assembles around `Variables` and uses the time integration methods (see !2519)<br>
- [ ] Introduce solution state (name is to be discussed) class that substitutes elementSolution during the assembly - that is, as argument to volume variables updates and in spatial parameters interfaces. The concept of this state class is to carry time information in addition to the element solution, that can be used within user interfaces. (!2520)
- [ ] Introduce context class, that wraps the local views after bind in order to pass that into the user interfaces. That reduces the number of arguments in a bunch of interfaces, and moreover, we usually have interfaces like `function(element, fvGeometry, elemVolVars,...)`, but `fvGeometry` makes little sense if not bound to `element` anyway and it also carries the bound element. With the same argument `elemVolVars` are basically unusable if you don't have the `scvs` at hand to access the corresponding volume variables. So in all those interfaces it makes sense to group the arguments. This is also introduced together with the solution state in !2520
- [ ] Extend problem/parameter/volvars interfaces to make it possible to inject some container with additionally required data, which in `MultiDomain` could be used to pass the coupling data. This is probably a lot of work and requires some thought regarding compatibility.<br>
- [ ] port the above concepts to `MultiDomain` (first goal: make `test_el2p` work, fixing the main bug)
Edit 25.03: We may postpone the introduction of the additional container to hold the coupling context for now and first realize multidomain in the new experimental framework but still with the context stored centrally in `CouplingManager` (an outdated but working draft is in !2448). This way, we can still reuse most interfaces in non-experimental namespace. Afterwards, we could address the issue of the central context separately, which would probably involve quite some interface changes... With either approach, the bug of non-converging Newton solver for poromechanics is addressed. Getting the context out of `CouplingManager` would additionally address thread safety in thread-parallel runs.
Problems that might need to be solved:
- The `assemble()` functions in the assembler now receive non-const GridVariables (introduced in 3d7068043ddb1cc7249aa0cd7d95ffa077733524). That was necessary because in the case of global caching we actually deflect the variables that come in. We should maybe think of a concept to circumvent this, and adapt !2519 accordingly.
Intermediate solutions/developments or related stuff, which should be deleted in case we favour the propositions above:
!2297, !2448, !2476, !2498, !2134, !2281, `feature/timestepmethods (now deleted)`
Things that should be revisited and adapted once this is ready:
!2130
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/761
Cleanup explicit flash of implicit 2p2c model
2023-02-22T08:57:13Z
Beatrix Becker
Cleanup explicit flash of implicit 2p2c model
The volumevariables of the 2p2c model have an explicit flash directly implemented in the volumevariables itself.
* In general I like the idea of a specialized 2p2c flash that is easy to understand and fast, but it shouldn't be included...
The volumevariables of the 2p2c model have an explicit flash directly implemented in the volumevariables itself.
* In general I like the idea of a specialized 2p2c flash that is easy to understand and fast, but it shouldn't be included in the volumevariables. I would propose implementing it as a separate class in a separate header, like the other constraintsolvers.
* The flash is only used if `useConstraintSolver` is false and the default is true. For the 2p2c model I would make the flash the default, since it is a faster calculation than using the more general `MiscibleMultiPhaseComposition` constraintsolver which solves a linear system of equations. Maybe we should even completely delete `useConstraintSolver` because in my opinion the solver has no benefit here, it solves the same equations, just less efficiently.
* For the case of one phase we may use the `ComputeFromReferencePhase` constraintsolver since it does exactly what the flash does.
* I don't think the flash is currently tested, so this should be added. It should have the same result as the other constraintsolvers.
What do you think? Another solution could be to delete the flash code and always use the solvers that we already have, but as mentioned above, I prefer having a 2p2c-specific flash.
There are a few points that I'm not sure of, maybe @holle can comment on this:
* In my opinion this flash is not as correct as it could be because it uses the assumption that vapor pressure of the liquid component and partial pressure of the liquid component in the gas phase are the same. This is only the case if we neglect the presence of other components in the gas phase. There is an equally quick method to calculate the mass fractions without using this assumption, see the 2p2c flash of the sequential models (note: pre release 3.4)
* It seems that the flash assumes that we deal with one liquid and one gas phase and that the liquid phase is the first phase. I think the 2p2c flash of the sequential models doesn't have this constraint.
* There seems to be a bug in the case that only the first phase is present, in the calculation of the mole fraction of the first component in the second phase. A multiplication with the mole fraction of the first component in the first phase is probably missing.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/707
Generic implementation of L2-norm calculation using generic L2-projection
2024-01-18T09:27:15Z
Timo Koch
timokoch@math.uio.no
Generic implementation of L2-norm calculation using generic L2-projection
With !1609 we get a generic l2-projection. In order to use it for interpolation between two arbitrary grids (arbitrary function spaces already works), we need to implement
* [x] 2d-2d intersections (!1625)
* [x] 3d-3d intersections (!29...
With !1609 we get a generic l2-projection. In order to use it for interpolation between two arbitrary grids (arbitrary function spaces already works), we need to implement
* [x] 2d-2d intersections (!1625)
* [x] 3d-3d intersections (!2977)
That would be a great tool for convergence tests.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/524
(Re-)Implement CFL criterion
2023-02-19T16:20:57Z
Timo Koch
timokoch@math.uio.no
(Re-)Implement CFL criterion
As a first step of porting the decoupled/sequential models to the new structure, it would be a good thing to implement a CFL criterion for the time step control for the current porousmediumflow models. Add good start is e.g. a CFL is e.g...
As a first step of porting the decoupled/sequential models to the new structure, it would be a good thing to implement a CFL criterion for the time step control for the current porousmediumflow models. Add good start is e.g. a CFL is e.g. the 1p_tracer test (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/tree/master/test/porousmediumflow/tracer/1ptracer) that uses an explicit Euler for the transport but currently has a constant time step that is small enough for the test. CFL would be a big improvement.
@martins Maybe you are the best to deal with this?
Martin Schneider
Martin Schneider
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1361
Follow-up from "pore network model: 2pnc test"
2024-03-27T18:38:06Z
Timo Koch
timokoch@math.uio.no
Follow-up from "pore network model: 2pnc test"
The following discussion from !3197 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3197#note_97135): (+1 comment)
> ```suggestion:-6+0
> #inc...
The following discussion from !3197 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3197#note_97135): (+1 comment)
> ```suggestion:-6+0
> #include <iostream>
>
> #include <dune/common/parallel/mpihelper.hh>
> ```
> These don't seem to be used
and also https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3197#note_97134 (add changelog entry and fix filename)
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1359
[freeflow] Momentum boundary flux helpers: Inertia terms in slip velocity mom...
2024-03-01T10:54:26Z
Mathis Kelm
[freeflow] Momentum boundary flux helpers: Inertia terms in slip velocity momentum flux
In [dumux/freeflow/navierstokes/momentum/fluxhelper.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/freeflow/navierstokes/momentum/fluxhelper.hh)
- [ ] Are the inertia terms correct and consistent betwee...
In [dumux/freeflow/navierstokes/momentum/fluxhelper.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/freeflow/navierstokes/momentum/fluxhelper.hh)
- [ ] Are the inertia terms correct and consistent between the two cases considered in the slip velocity momentum flux and compared to the outflow momentum flux?
- [ ] Currently the user has to apply the correct flux helper function in the correct part of the Neumann boundary (both helper functions compute inertia terms). If neither scv nor scvf lie on a slip boundary, the slip velocity helper currently returns 0 but should perhaps throw an exception, or assert/assume it's used correctly.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1358
Move special case treatments to appropriate classes: VelocityGradients
2024-03-01T10:54:56Z
Mathis Kelm
Move special case treatments to appropriate classes: VelocityGradients
For (fcstaggered) freeflow a normal velocity gradient at the boundary can only be computed if the velocity is specified through Dirichlet boundary conditions. While the `velocityGradients` uses `outsideVolVars` (=inside at non-Dirichlet ...
For (fcstaggered) freeflow a normal velocity gradient at the boundary can only be computed if the velocity is specified through Dirichlet boundary conditions. While the `velocityGradients` uses `outsideVolVars` (=inside at non-Dirichlet boundaries?), the slip velocity momentum flux allows to specify this gradient as an optional parameter. Instead, the `velocityGradients` could specify treatment of edge cases in a central spot such that other classes can apply it in a consistent manner.
This should be accompanied with an easily accessible option to switch such classes if you adapted them, e.g. through access to publicly readable model traits.
https://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:42Z
Anna Mareike Kostelecky
[test][porousmediumflow][2pncmin][nonisothermal] Neumann flux at top has to 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:...
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/1352
Print absolute residual when using LineSearch in Newton Solver
2024-02-10T00:00:05Z
Lars Kaiser
Print absolute residual when using LineSearch in Newton Solver
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/READ...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Print the absolute residual for each step of the newton solver to the console if `useLineSearch=true`.
**What does this feature / why does DuMux need it**:
The residual reduction and relative shift can make it look like we are/could be stuck on a saddle point. The information about the absolute residual can, in most cases, avoid this ambiguity.
```
Newton iteration 1 done, maximum relative shift = 6.4650e-08, residual = 4.2105e-13, residual reduction 1.0000e+00->1.5204e+00@lambda=0.1250
Newton iteration 2 done, maximum relative shift = 5.6569e-08, residual = 3.8752e-13, residual reduction 1.5204e+00->1.3993e+00@lambda=0.1250
Newton iteration 3 done, maximum relative shift = 4.9497e-08, residual = 3.8370e-13, residual reduction 1.3993e+00->1.3855e+00@lambda=0.2500
Newton iteration 4 done, maximum relative shift = 3.7123e-08, residual = 4.1695e-13, residual reduction 1.3855e+00->1.5056e+00@lambda=0.1250
Newton iteration 5 done, maximum relative shift = 3.2482e-08, residual = 3.6522e-13, residual reduction 1.5056e+00->1.3188e+00@lambda=0.5000
Newton iteration 6 done, maximum relative shift = 1.6241e-08, residual = 4.7623e-13, residual reduction 1.3188e+00->1.7196e+00@lambda=0.1250
Newton iteration 7 done, maximum relative shift = 1.4210e-08, residual = 4.2784e-13, residual reduction 1.7196e+00->1.5449e+00@lambda=1.0000
Newton iteration 8 done, maximum relative shift = 4.3042e-13, residual = 4.0635e-13, residual reduction 1.5449e+00->1.4673e+00@lambda=0.5000
Newton iteration 9 done, maximum relative shift = 2.1520e-13, residual = 3.9071e-13, residual reduction 1.4673e+00->1.4108e+00@lambda=0.5000
```
**Which issue does this feature fix (if any)**
**Anything else we need to know?**:
I would propose to print this information if there is no reason against it, with the hope to have an even better user experience.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1347
Pore Scale Simulations with Volume Averaging
2024-03-25T10:40:18Z
Ned Coltman
Pore Scale Simulations with Volume Averaging
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
**Feature request**
There are a few merge requests and issues related to the same thing.
Many of u...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
**Feature request**
There are a few merge requests and issues related to the same thing.
Many of us have been using the freeflow models for pore-scale evaluations. Developments to this have been made in a few merge requests and issues.
- !3154 fixed a discretization bug related to convex corners
- !3160 and !3161 would both add a freeflow test that simulates flow within a pore geometry.
- !3626 introduces a few methods for averaging pore-scale solutions. It assumes conforming quadrilateral grids. A single unit averaging method is introduced, as well as a ensemble/convolutional averaging.
There are a few open problems:
- Dune-subgrid does not currently pass periodicity from the host grid to the subgrid. This has been fixed in a branch: https://gitlab.dune-project.org/extensions/dune-subgrid/-/tree/feature/SPGrid-Periodicity?ref_type=heads and has been described in https://gitlab.dune-project.org/extensions/dune-subgrid/-/issues/8. The fix on the branch has not been merged as it causes tests on dune-subgrid to fail.
- If subgrid also allows periodicity, there are a few changes to dumux that can be added. These are addressed in !3166.
- Handling of non-conforming grids needs to be handled.
- Averaging with a kernel function for convolutional averaging.
- Further convolutional averages have been investigated in the context of sfb-A01's dft work, which could be added as well.
- Add a caching method for saving element indicies and volumes that belong to certain averaging volumes to accellerate averaging on multiple time steps.
Larger questions that need to be addressed:
- How do we handle averages over a solid inclusion, where no solution exists?
3.9
Ned Coltman
Ned Coltman
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1345
dofOnBoundary missing for some discretization schemes
2024-03-25T10:40:27Z
Leon Keim
dofOnBoundary missing for some discretization schemes
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/READ...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
Add dofOnBoundary function for various discretization schemes.
Currently implemented for box,diamond,pq1bubble,porenetwork.
**What does this feature / why does DuMux need it**:
Some preconditioners require a vector of dirichlet dof's to function properly. For instance StokesSolver's preconditioner (see [Test](test/freeflow/navierstokes/unstructured/main.cc)). In order to use these preconditioners a way to find dirichlet dof's needs to be introduced for various discretization schemes.
**Which issue does this feature fix (if any)**
Makes more preconditioners useable. StokesSolver should be usable with multidomain and staggered.
3.9
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1344
Release 3.9
2024-02-28T08:34:38Z
Leon Keim
Release 3.9
# Issue related for Dumux Day's leading to 3.9
## Introduction
- Second Dumux Day in this release cycle
- Trial of new way to approach Dumux Day
---
## New Approach to Dumux Days
### Few things we think that can be improved:
-...
# Issue related for Dumux Day's leading to 3.9
## Introduction
- Second Dumux Day in this release cycle
- Trial of new way to approach Dumux Day
---
## New Approach to Dumux Days
### Few things we think that can be improved:
- Motivation
- Stop endless discussions
- Reduce the contribution hurdle
### Ideas for this release:
- Identify three main contributions for the next release
- Smaller groups for each contribution
- Group should start by first defining the why,how and how much
+ Avoid to much discussion
+ Avoid doing work for nothing
- Ideally develop a roadmap for that
+ Includes to decide what is realistic and what not
- Group stays in that configuration for the release
- Every Dumux Day each group gets 5 min to present where they are
- To early feedback should be avoided
+ More power/responsibility for individual groups
---
## Main Contributions for this Release
### 1. Documentation @kaiw @stefaniekiemle @houkili @leonidas
- #1154 High-Level-Documentation !3755
- Architectural-Documentation
- #1338 Parameter Group
- #1323 Fluid-Matrix-Interactions
- #1346 Comments and Documentation in General
### 2. Physics @anna_m_kostelecky @yue @tschol @IvBu @RoWin @tufan @Maziar
- #1339 setRelativeHumidity and Fluid States @timok
- #1256 Energy balance implemetation @anna_m_kostelecky @tufan @Maziar
- #1255 Enthalpy of ideal gases @IvBu @RoWin @tschol @yue
- #1221 Anisotropic permeability law
### 3. FreeFlow @nedc @martins @mathis
- #1257 FF-PM Coupling
- #1205 Spatially varying extrusion Factor
- #1347 Pore Scale Simulations with Volume Averaging
- #1345 dofOnBoundary missing
3.9
Leon Keim
Leon Keim
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1338
Parameter group and documentation
2024-01-30T14:53:03Z
Timo Koch
timokoch@math.uio.no
Parameter group and documentation
In https://dumux.org/docs/doxygen/master/runtime-parameters.html add a description about the parameter model when dealing with multiple instances of the same class and a global parameter tree. We use group prefixes then to set different ...
In https://dumux.org/docs/doxygen/master/runtime-parameters.html add a description about the parameter model when dealing with multiple instances of the same class and a global parameter tree. We use group prefixes then to set different parameters for the different instances. This could be more transparent for most classes but definitely needs to be documented in the doc page.
We should also think about flexibility and better design to pass param groups. It would be good if the parameter group could be changed after construction. Or maybe we could think about some factory pattern that allows to set the parameter group of a class instance and use this pattern everywhere. Maybe parameterized classes could provide constructor overloads that take the param group as the first parameter (using some named type).