dumux issues
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues
2024-01-30T14:53:03Z
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).
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/1323
[doc] Large number of uncategorized files in Fluidmatrixinteractions group
2024-03-25T10:37:27Z
Lars Kaiser
[doc] Large number of uncategorized files in Fluidmatrixinteractions group
<!--
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**
I propose to add more subgroups to the Fluidmatrixinteractions group to make it easier to see what kind of constitutive relations are contained in this group.
**What does this feature / why does DuMux need it**:
Currently, there is a large number of files directly in the Fluidmatrixinteractions group and it is hard to get an overview of what is available. Introducing the subgroups will also bring the organization of the documentation closer to the internal folder structure of Dumux, where the files are already grouped.
Lars Kaiser
Lars Kaiser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1212
License text
2023-02-19T16:36:58Z
Timo Koch
timokoch@math.uio.no
License text
Our default header license text mentions COPYING but that file has been removed. We should also clearly state how to reuse DUmux files, i.e. what text needs to be provided
I think the license headaer should refer to Authors and say some...
Our default header license text mentions COPYING but that file has been removed. We should also clearly state how to reuse DUmux files, i.e. what text needs to be provided
I think the license headaer should refer to Authors and say something like copyright "the dumux developers". (And in Authors there should be a headline "the dumux developers")
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1197
CodeMeta Data: Authors/contributors?
2023-10-26T11:16:22Z
Timo Koch
timokoch@math.uio.no
CodeMeta Data: Authors/contributors?
The following discussion from !3101 should be addressed:
- [ ] @bernd started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3101#note_75683): (+5 comments)
> The most relevant open quest...
The following discussion from !3101 should be addressed:
- [ ] @bernd started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3101#note_75683): (+5 comments)
> The most relevant open questions concern authorship. CodeMeta distinguishes between "authors" and "contributors". Should we also distinguish? Who will be included? (How) do we automate the update of the file?
Add generic author (Dumux development team / Dumux developers) and list of contributors
3.9
Bernd Flemisch
Bernd Flemisch
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/1066
Documentation for python bindings
2023-02-20T10:54:36Z
Timo Koch
timokoch@math.uio.no
Documentation for python bindings
Python bindings are still experimental but we should
* Move pointers to Python installation setup to main readme
* Improve installation and test instructions
* think about how to generate docs for Python. Maybe have a look and follow wh...
Python bindings are still experimental but we should
* Move pointers to Python installation setup to main readme
* Improve installation and test instructions
* think about how to generate docs for Python. Maybe have a look and follow what Dune does too. Sphinx is a popular tool for automated doc generation for Python.
* For automated docs we also need to decide on a docstring format (e.g. the google format understood by Sphinx)