dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2023-12-13T11:13:10Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1195Discussion: Dumux 4.02023-12-13T11:13:10ZDennis GläserDiscussion: Dumux 4.0This place can be used to capture and discuss plans/wishes/improvements for a potential 4.0.
1. What is the main "selling point" or "goal" of Dumux? Maybe we should first define our place in the universe of numerics packages and try to ...This place can be used to capture and discuss plans/wishes/improvements for a potential 4.0.
1. What is the main "selling point" or "goal" of Dumux? Maybe we should first define our place in the universe of numerics packages and try to optimize for that. Is the specialty of Dumux the material framework? Is it discretization methods? What is most likely to be extended in the future (i.e. new disc methods or rather physics)?
2. What are the responsibilities of our different classes?
- `GridGeometry`: defines the entities of the discretization and allows to formulate finite-volume schemes in an abstract way (unclear if this extends to e.g. finite-element methods)
- `GridVariables`: defines the variables living on the entities of `GridGeometry`, required for the formulation of the discrete model equations
- `VolumeVariables`: an instance the variables living on a single entity of `GridGeometry`. Currently, they act both as storage as well as the logic to fill that storage. This could maybe be separated - turning `VolumeVariables` into solely storage, injecting the logic to fill the quantities (i.e. the used constitutive relationships) from outside.
Plan until 28.11.2022 (discussed on 14.11.2022):
- Think about desired high-level main file structure, possibly come up with snippets/code-comments/branches or whatever.
Main file brain-storming
* How would a nice main file look like in my opinion?
- No need to stick with the current structure
- Which components are essential to a/my simulation?
- What do I want to configure in the main (literally) file of the program?
- Which component needs to know about which other component?Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1192Discussion: make grid geometries observable2023-12-13T11:13:10ZDennis GläserDiscussion: make grid geometries observableFor the new assembly, we could think about using the Observer design pattern on our grid geometries. This way, we could make all classes that need updating when the grid/gridGeometry changes observers of the grid geometry such that users...For the new assembly, we could think about using the Observer design pattern on our grid geometries. This way, we could make all classes that need updating when the grid/gridGeometry changes observers of the grid geometry such that users don't have to update manually afterwards.
An example could be out grid variables. Upon construction, they could register themselves as observer to the grid geometry, and update themselves once notified that the grid geometry has changed.
In the current master, `GridVariables` store a `shared_ptr` to `GridGeometry`. If we made the observable base class use `shared_ptr` to the observers, we'd create a memory leak because both classes store `shared_ptr` to each other. So we have to be careful and maybe use raw pointers (or `weak_ptr`) somewhere...Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/881some interfaces in FVLocalResidual receive problem as function argument2023-12-13T11:13:08ZDennis Gläsersome interfaces in FVLocalResidual receive problem as function argumentIn the base local residual for finite-volume schemes we have some interfaces that receive a problem instance and some that use the private variable `problem_` which is instantiated in the class constructor. For some functions, there exis...In the base local residual for finite-volume schemes we have some interfaces that receive a problem instance and some that use the private variable `problem_` which is instantiated in the class constructor. For some functions, there exist two overloads - one receiving problem and one using the private variable.
I find this a bit confusing at the moment. The functions are not static, so you need the local residual object - which was instantiated with a specific problem instance, i.e. we have the constructor
```cpp
//! the constructor
FVLocalResidual(const Problem* problem,
const TimeLoop* timeLoop = nullptr)
: problem_(problem)
, timeLoop_(timeLoop)
{}
```
What I find even more surprising is that `Problem` comes out of the property system, so I can potentially only call the interfaces receiving a problem with another instance of the same problem type.
So, I am wondering if the functions receiving a problem instance were designed to allow for evaluations for any problem, independent of how the class was instantiated? But then I'd assume the function the function to be static, or, to be free functions that temporarily instantiate a local residual using the provided problem and then calling these functions on that local variable without passing `problem`.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/933Discussion: Unify LocalAssemblers and SubDomainCouplingAssemblers2023-12-13T11:13:08ZKilian WeishauptDiscussion: Unify LocalAssemblers and SubDomainCouplingAssemblersFrom a brief glance at `BoxLocalAssembler` and `SubDomainBoxLocalAssembler` it seems that there is a large degree of code duplication. I think it should be possible to make `SubDomainBoxLocalAssembler` inherit from `BoxLocalAssembler`.
...From a brief glance at `BoxLocalAssembler` and `SubDomainBoxLocalAssembler` it seems that there is a large degree of code duplication. I think it should be possible to make `SubDomainBoxLocalAssembler` inherit from `BoxLocalAssembler`.
The only critical parts are some calls to `couplingManager`. This could be replaced by some lambda calls which do nothing for the non-coupling assembler. The coupled assembler could then call the base class' function with a specialized lambda which .
, e.g., update the coupled variables.
We could evaluate the possibility of streamlining our code on the next Dumux day.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/1152Move FECache from gridgeometry to grid variables?2023-12-13T11:12:28ZTimo Kochtimokoch@math.uio.noMove FECache from gridgeometry to grid variables?The FECache in Box is the only type that requires to know about the scalar type. This is because it is supposed to map to variables. So shouldn't it be in the grid variables?
__More details__
The concept of the grid geometry does not h...The FECache in Box is the only type that requires to know about the scalar type. This is because it is supposed to map to variables. So shouldn't it be in the grid variables?
__More details__
The concept of the grid geometry does not have a notion of variables living on the grid and is strictly related to the geometrical description of the domain/grid adapted for a specific discretization scheme. As such it should also only be concerned with the coordinate type and not the scalar variable type.
One element breaking this is the finite element basis in Box which is currently used to interpolate variables. In the concept above it seems ok to use it for coordinate interpolation, but the concept of constructing discrete variable function spaces and bases seems to be what the grid variables are for (mapping variables onto a given grid geometry).