dumux-repositories issueshttps://git.iws.uni-stuttgart.de/groups/dumux-repositories/-/issues2023-04-04T11:40:44Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course/-/issues/36Place property stuff earlier2023-04-04T11:40:44ZDennis GläserPlace property stuff earlierMaybe it would help to put the property stuff in the beginning of the course, otherwise people see properties in the first exercises without knowing what that is.
On the other hand, the properties is what people usually don't understand...Maybe it would help to put the property stuff in the beginning of the course, otherwise people see properties in the first exercises without knowing what that is.
On the other hand, the properties is what people usually don't understand. Maybe we should change the presentation such that
- we start with the syntax, how it looks, and what it does - without explaining how the mechanism work
- leave out the details as optional or self studyhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course/-/issues/35Iterating over grid, compute boundary fluxes2023-04-02T23:43:03ZTimo Kochtimokoch@math.uio.noIterating over grid, compute boundary fluxesAdd some slides/exercise on how to do thatAdd some slides/exercise on how to do thathttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course/-/issues/34Clear copyright for images2023-04-02T23:33:22ZTimo Kochtimokoch@math.uio.noClear copyright for imagesWe want to make this available under an open license. Need to check if all images are suitable.We want to make this available under an open license. Need to check if all images are suitable.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1222In DuneVectorType add a check for blockLevel requirements or implement recurs...2023-02-22T11:18:02ZTimo Kochtimokoch@math.uio.noIn DuneVectorType add a check for blockLevel requirements or implement recursivelyThe following discussion from !3385 should be addressed:
- [ ] @DennisGlaeser started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3385#note_84501): (+2 comments)
> I think it could be ...The following discussion from !3385 should be addressed:
- [ ] @DennisGlaeser started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3385#note_84501): (+2 comments)
> I think it could be good to statically check that the vector has a depth of 2 here, since this seems to be the case? Otherwise one gets a surprising result for vectors of different depth (although unlikely, and it would probably not compile due to "misuse" of the resulting vector type in other places)...
We could either add a static_assert or try to do the same recursion as for multitypevector to recursively use the template to convert block types.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1221Anisotropic permeability Law2024-03-25T10:38:56ZJohannes HommelAnisotropic permeability Law**What does this feature / why does DuMux need it**:
An anisotropic permeability law is needed to account for precipitation having a different impact on the permeability in different directions. This is necessary for modeling a developi...**What does this feature / why does DuMux need it**:
An anisotropic permeability law is needed to account for precipitation having a different impact on the permeability in different directions. This is necessary for modeling a developing anisotropy due to precipitation as observed in the microfluidic experiments of the CRC1313, Project C04 by Felix Weinhardt.
My goal would be to have a permeability Law that used different exponents in a power law for each of the directions:
kxxFactor = (poro/refPoro)^exponentX
kyyFactor = (poro/refPoro)^exponentY
K = kxxFactor * Kxx_0 0
0 kyyFactor * Kyy_0
I guess the easiest would be to have a matrix multiplication of the initial permeability K_0 with a "factor matrix" F:
K = K_0 * F
with
K_0 = Kxx_0 0
0 Kyy_0
and
F = kxxFactor 0
0 kyyFactor
**Which issue does this feature fix (if any)**
This issue/feature does not fix any other open issues.
**Anything else we need to know?**:
I would like to discuss whether there is an elegant, general solution for implementing anisotropic permeability laws recycling the current permeability laws (assuming isotropic permeability change) or whether I should just implement a new permeability law for my specific case.
Also, my question would be how to do this potentially even more generalized for 2D and 3D in one permeability law, if possible.3.9Johannes HommelJohannes Hommelhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1218Code quality report Gitlab+cppcheck2023-02-10T16:26:51ZTimo Kochtimokoch@math.uio.noCode quality report Gitlab+cppcheckUsing this tool https://gitlab.com/ahogen/cppcheck-codequality
we might be able to integrate the cppcheck report with GitlabUsing this tool https://gitlab.com/ahogen/cppcheck-codequality
we might be able to integrate the cppcheck report with Gitlabhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1217Parallel computing for Navier-Stokes2023-02-28T15:08:26ZMojtaba BarzegariParallel computing for Navier-StokesHi,
I have difficulty finding proper examples of parallel execution of coupled Navier-Stokes problems (like https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/freeflow/navierstokes/channel/3d_nonuniform). When ...Hi,
I have difficulty finding proper examples of parallel execution of coupled Navier-Stokes problems (like https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/freeflow/navierstokes/channel/3d_nonuniform). When I apply the typical workflow for enabling parallel run (as described in the handbook, by including `<dumux/linear/amgbackend.hh>` and replacing the sequential solver with `using LinearSolver = AMGBiCGSTABBackend<LinearSolverTraits<GridGeometry>>; auto linearSolver = std::make_shared<LinearSolver>(leafGridView, gridGeometry->dofMapper());`), I face a couple of errors similar to this:
`/dune-istl/dune/istl/novlpschwarz.hh:80:42: error: no type named ‘ConstColIterator’ in ‘class Dune::MultiTypeBlockMatrix<Dune::MultiTypeBlockVector<Dune::BCRSMatrix<Dune::FieldMatrix<double, 3, 3>, std::allocator<Dune::FieldMatrix<double, 3, 3> > >, Dune::BCRSMatrix<Dune::FieldMatrix<double, 3, 1>, std::allocator<Dune::FieldMatrix<double, 3, 1> > > >, Dune::MultiTypeBlockVector<Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 3>, std::allocator<Dune::FieldMatrix<double, 1, 3> > >, Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > > > >’
`
I checked it with both `MomentumGridGeometry` and `MassGridGeometry`, both resulting in the same error. I see that there are quite a few examples and tests for `AMGBiCGSTABBackend` for Stokes free flow and flow in porous media, but I couldn't find any relevant thing for NS where mass and momentum equations are coupled. Is parallel AMG backend not supported for such coupled problems?
I'm checking all these things with DuMux 3.6.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1213Metadata collection2023-10-20T13:57:37ZMartin SchneiderMetadata collectionImprove metadata collection of dumux.
TODOs:
- [ ] Add test case that collects metadata from dumux objects
- [ ] Add parameter tree to collectorImprove metadata collection of dumux.
TODOs:
- [ ] Add test case that collects metadata from dumux objects
- [ ] Add parameter tree to collector3.9Hamza OukiliHamza Oukilihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1212License text2023-02-19T16:36:58ZTimo Kochtimokoch@math.uio.noLicense textOur 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/1205[freeflow] Spatially varying extrusionFactor causes unphysical results for th...2024-03-25T10:40:04ZFelix Weinhardt[freeflow] Spatially varying extrusionFactor causes unphysical results for the pressure distributionThe issue is illustrated with the following example scenario:
The example is based on the test “test_ff_stokes_channel_pseudo3d” and modified in a way that the domain is a square (0.005 x 0.005) with a lense in the middle which has a d...The issue is illustrated with the following example scenario:
The example is based on the test “test_ff_stokes_channel_pseudo3d” and modified in a way that the domain is a square (0.005 x 0.005) with a lense in the middle which has a different aperture (height) compared to the rest of the domain, the boundary conditions are fixed pressure at the inlet and outlet - the rest of the domain is no-slip. The motivation is, to be able to simulate microfluidic experiments with the pseudo-3D approach with different apertures of the micromodel (caused by precipitates).
For that, the friction source term in the problem.hh file is adapted:
```c
template<class ElementVolumeVariables>
Sources source(const Element& element,
const FVElementGeometry& fvGeometry,
const ElementVolumeVariables& elemVolVars,
const SubControlVolume& scv) const
{
auto source = Sources(0.0);
if constexpr (ParentType::isMomentumProblem() && enablePseudoThreeDWallFriction)
{
auto globalPos = scv.center();
Scalar heightRel = 1. ;
if(globalPos[0] > 0.001 && globalPos[0]< 0.004 && globalPos[1] > 0.001 && globalPos[1] < 0.004)
{
heightRel = relativeFrictionFactorLense_;
}
static const Scalar height = getParam<Scalar>("Problem.Height");
static const Scalar factor = getParam<Scalar>("Problem.PseudoWallFractionFactor", 8.0);
source[scv.dofAxis()] = this->pseudo3DWallFriction(element, fvGeometry, elemVolVars, scv, heightRel*height, factor);
}
return source;
}
```
and the extrusion factor in the spatialParams.hh is adapted:
```c
Scalar extrusionFactorAtPos(const GlobalPosition& globalPos) const
{
Scalar heightRel = 1.;
if(globalPos[0] > 0.001 && globalPos[0]< 0.004 && globalPos[1] > 0.001 && globalPos[1] < 0.004)
{
heightRel = relativeExtrusionFactorLens_; // = 0.5
}
return extrusionFactor_*heightRel;
}
```
In the attached files, three scenarios are compared:
+ a) (blue graphs): only the source term in the problem file is modified.
+ b) (red graphs): only the extrusion factor in the spatialParams file are modified.
+ c) (violette graphs): both, the source term in the problem and the extrusion factor in spatialParams file are modified.
In case of spatially varying extrusionFactors, there are discontinuities in the pressure (plot over line horizontally), while the velocities (plot over line vertically) look reasonable.
![ExtrusionSimTest](/uploads/eca0b5582a0139defdc09238dfdb1333/ExtrusionSimTest.png)3.9https://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-web-app/-/issues/30deployment code breaks with python3.102022-12-13T19:09:06ZDavid Wernerdeployment code breaks with python3.10https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1197CodeMeta Data: Authors/contributors?2023-10-26T11:16:22ZTimo Kochtimokoch@math.uio.noCodeMeta 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 contributors3.9Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux-website/-/issues/50Link to DaRUS for citing releases2022-11-18T10:13:17ZBernd FlemischLink to DaRUS for citing releasesStarting with 3.6, release tarballs are uploaded to DaRUS instead of Zenodo. This has to be advertised on
https://dumux.org/about/#howtocite,
particularly, linked to
https://darus.uni-stuttgart.de/dataverse/iws_lh2_dumux.Starting with 3.6, release tarballs are uploaded to DaRUS instead of Zenodo. This has to be advertised on
https://dumux.org/about/#howtocite,
particularly, linked to
https://darus.uni-stuttgart.de/dataverse/iws_lh2_dumux.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1173Remove scv/scvf.geometry()/corner()2023-12-13T14:27:03ZTimo Kochtimokoch@math.uio.noRemove scv/scvf.geometry()/corner()Scv and Scvf do not need to store any corners and/or geometries.
The geometry can be computed on-the-fly given an element geometry.
We could provide such a feature in the element geometries.
Since I assume that this is a hardly used fea...Scv and Scvf do not need to store any corners and/or geometries.
The geometry can be computed on-the-fly given an element geometry.
We could provide such a feature in the element geometries.
Since I assume that this is a hardly used feature, and all occurrences in Dumux (can be counted on one hand) can use a replacement, I suggest to remove these interfaces without deprecation.
The benefit is much less memory usage when caching the scv/scvfs.
The proposed interface is two free functions
`auto geometry(fvElementGeometry, scv)`
`auto geometry(fvElementGeometry, scvf)`
Alternatively, we can think about
`auto geometry(element_geometry, scv)`
`auto geometry(element_geometry, scvf)`
then all local Dune index information has to be available from the scv/scvf object, while the first version allows to do some additional mapping only known to the `fvElementGeometry` implementation.3.9Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1160Prototypical math models for testing and as examples2023-09-23T18:14:28ZTimo Kochtimokoch@math.uio.noPrototypical 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:_
* #867https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1156FluxVariables is a misnomer2023-10-26T08:07:56ZTimo Kochtimokoch@math.uio.noFluxVariables is a misnomerThe classes `[...]FluxVariables` actually computes fluxes for which it uses variables from the `VolumeVariables` and `FluxVariablesCache`. It does store local variable objects in its state but the main interface is all about computing fl...The classes `[...]FluxVariables` actually computes fluxes for which it uses variables from the `VolumeVariables` and `FluxVariablesCache`. It does store local variable objects in its state but the main interface is all about computing fluxes. Also, they are used directly within `LocalResidal::computeFlux` as a helper to compute fluxes (evaluate the flux-part of the local residual).
Possible better names would be `[...]Flux` `[...]Fluxes`.3.9Mathis KelmMathis Kelmhttps://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/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/1146Investigate parallel assembly with Python2023-02-22T08:57:02ZTimo Kochtimokoch@math.uio.noInvestigate parallel assembly with PythonCalling Python code from C++ (which is what we do for the problem for example) requires acquiring the GIL because the Python interpreter is serial. We should test whether this nulls all of the speed-up of multithreading. And if yes, thin...Calling Python code from C++ (which is what we do for the problem for example) requires acquiring the GIL because the Python interpreter is serial. We should test whether this nulls all of the speed-up of multithreading. And if yes, think about some other options. There might be options around this like using multithreading from Python already (?)