dumux-repositories issueshttps://git.iws.uni-stuttgart.de/groups/dumux-repositories/-/issues2023-12-13T09:54:51Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1258An example for "upscaling of two-phase flow properties using pore network"2023-12-13T09:54:51ZMaziar VeyskaramiAn example for "upscaling of two-phase flow properties using pore network"Since many people use pore network for upscaling purposes, there is a need to have a well-designed and documented example of how it can be done using the pore network in DUMUX. Although we already have an example for upscaling of a singl...Since many people use pore network for upscaling purposes, there is a need to have a well-designed and documented example of how it can be done using the pore network in DUMUX. Although we already have an example for upscaling of a single-phase flow system, having another example for upscaling of a two-phase system to obtain capillary-saturation and relative permeability-saturation curves is desirable.Maziar VeyskaramiMaziar Veyskaramihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1257[ff-pm] Generalize ff-pm coupling - allow different schemes and generalize sl...2024-03-26T09:28:33ZMartin Schneider[ff-pm] Generalize ff-pm coupling - allow different schemes and generalize slip condition- [x] The current implementation for coupling free-flow with porous medium flow is restricted to cctpfa-staggered coupling, this should be generalized to also allow other coupling schemes.
- [x] Generalization of slip condition !3762- [x] The current implementation for coupling free-flow with porous medium flow is restricted to cctpfa-staggered coupling, this should be generalized to also allow other coupling schemes.
- [x] Generalization of slip condition !37623.9Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1256[porousmedia] Energy balance implementation2024-03-25T10:31:55ZTimo Kochtimokoch@math.uio.no[porousmedia] Energy balance implementationWe currently have some inconsistencies in the energy balance for porous media. For thermal equilibrium models, we implement
```math
\frac{\partial \left( n_s \rho_s u_s + n_f \rho_f u_f \right)}{\partial t} =
- \nabla\cdot{\left( \rho...We currently have some inconsistencies in the energy balance for porous media. For thermal equilibrium models, we implement
```math
\frac{\partial \left( n_s \rho_s u_s + n_f \rho_f u_f \right)}{\partial t} =
- \nabla\cdot{\left( \rho_f h_f \boldsymbol{v}_f \right)} + \nabla\cdot{\left( \left\lbrace n_f \lambda_f + n_s \lambda_s \right\rbrace \nabla T \right)}.
```
but the correct balance would be
```math
\frac{\partial \left( n_s \rho_s u_s + n_f \rho_f \left\lbrace u_f - g z \right\rbrace \right)}{\partial t} =
- \nabla\cdot{\left( \left\lbrace \rho_f h_f - \rho_f g z\right\rbrace \boldsymbol{v}_f \right)} + \nabla\cdot{\left( \left\lbrace n_f \lambda_f + n_s \lambda_s \right\rbrace \nabla T \right)}.
```
This might seem like a small change but the difference actually shows some inconsistency. It's not just an omitted term.
Only looking at the fluid balance, the gravity term can also be written like this
```math
\frac{\partial \left( n_f \rho_f u_f \right)}{\partial t} = - \nabla\cdot{\left( \rho_f h_f \boldsymbol{v}_f \right)} + \nabla\cdot{\left(n_f \lambda_f \nabla T \right)} + \rho_f \boldsymbol{v}_f \cdot \boldsymbol{g} = - \nabla\cdot{\left( (\rho_f u_f + p) \boldsymbol{v}_f \right)} + \nabla\cdot{\left(n_f \lambda_f \nabla T \right)} + \rho_f \boldsymbol{v}_f \cdot \boldsymbol{g}.
```
Essentially, if we consider gravity in Darcy's law, we should also consider the corresponding term in the energy balance for consistency.
Subtracting the momentum balance multiplied by the velocity gives the balance of internal energy (non-conservative because only total energy is conserved):
```math
\frac{\partial \left( n_f \rho_f u_f \right)}{\partial t} = - \nabla\cdot{\left( \rho_f u_f \boldsymbol{v}_f \right)} + \nabla\cdot{\left(n_f \lambda_f \nabla T \right)} \underbrace{- p \left(\nabla\cdot{\boldsymbol{v}_f}\right)}_{\text{volume work}} \underbrace{+ \mu_f \boldsymbol{K}^{-1} \boldsymbol{v}_f \cdot \boldsymbol{v}_f}_{\text{viscous dissipation}}
```
This shows that there are conversion terms resulting in modification of the internal energy. Even if we assume that one of these is small, or both of these are small, we don't arrive at the implemented equation. If we don't have the gravity/potential energy term in the original balance, there would be an additional gravity term popping up here that mingles with the other energy conversion terms.
The gravity term vanishes if the fluid only moves perpendicular to the gravity field. However, for scenarios with strong upward/downward movement, this should have an effect.3.9Tufan GhoshTufan Ghoshhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1255Potential inconsistency in component enthalpies of ideal gases2024-03-19T12:43:26ZDennis GläserPotential inconsistency in component enthalpies of ideal gasesFor ideal gases, enthalpy is independent of pressure (see last paragraph of the introduction [here](https://en.wikipedia.org/wiki/Enthalpy) or [here](https://chem.libretexts.org/Bookshelves/Physical_and_Theoretical_Chemistry_Textbook_Map...For ideal gases, enthalpy is independent of pressure (see last paragraph of the introduction [here](https://en.wikipedia.org/wiki/Enthalpy) or [here](https://chem.libretexts.org/Bookshelves/Physical_and_Theoretical_Chemistry_Textbook_Maps/Physical_Chemistry_(LibreTexts)/22%3A_Helmholtz_and_Gibbs_Energies/22.04%3A_The_Enthalpy_of_an_Ideal_Gas)). We end up with
```math
dH = c_p dT
```
for enthalpy changes as function of temperature.
Some components implement
```cpp
static const Scalar gasEnthalpy(Scalar temperature, Scalar pressure)
{ return gasHeatCapacity(temperature, pressure) * temperature; }
```
However, with the above equation we should actually from a reference temperature (or state) to the given temperature.
Some Observations:
- `CH4` implements this:
```cpp
// method of Joback
const Scalar cpVapA = 19.25;
const Scalar cpVapB = 0.05213;
const Scalar cpVapC = 1.197e-5;
const Scalar cpVapD = -1.132e-8;
return
1/molarMass()* // conversion from [J/(mol*K)] to [J/(kg*K)]
(cpVapA + T*
(cpVapB/2 + T*
(cpVapC/3 + T*
(cpVapD/4))));
```
it says this is according to the method of Joback but I am having trouble finding out where the magic numbers come from. I cannot relate them to the Joback tables (e.g. Appendix C of [1]). Also, the equation looks as if this actually returns the average cp (integration of cp from 0 to T and then division by T). Sampling enthalpy values at specific temperatures also verifies that, as one gets closer to reported values when one removes the divisors (`/2`, `/3, `/4`)...
If we cannot find out where exactly these values come from, we could use Appendix A, Table Section C, row 26 of [1] for enthalpy computations. Seems to match reported values.
- The current implementation (`cp*T`) vs integration led to differences between 15% and > 30% in for
`150 < T < 600`
I suggest the following for all ideal gases that have this kind of implementation:
- (1) Use Appendix A from [1] or properly implement & cite the Joback method (i.e. Appendix C from [1]) for the heat capacities
- (2) integrate the enthalpy from a reference state to the given temperature using eq 3-1.5 of [1]
- (3) (maybe) re-evaluate the validity bounds (temperature, but also species) of the Joback method, and maybe emit a warning when one leaves the validity range? (Tricky, because it could happen in some Newton iterations but be fine at the end of the solve...)
- [1] also shows other methods than Joback, we could have a look if they provide advantages...
[1] B. Poling et al. (2001, fifth edition, pp A.35) - https://www.eng.uc.edu/~beaucag/Classes/ChEThermoBeaucage/Books/Bruce%20E.%20Poling,%20John%20M.%20Prausnitz,%20John%20P.%20O%27Connell%20-%20The%20properties%20of%20gases%20and%20liquids-McGraw-Hill%20Professional%20(2000).pdf3.9Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course/-/issues/47Making DuMux-course reuse compliant2023-09-07T12:35:03ZHamza OukiliMaking DuMux-course reuse compliantDuMux course license is insufficient. It needs to be reuse compliant like DuMux. See [MR=dumux:3442](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3442)DuMux course license is insufficient. It needs to be reuse compliant like DuMux. See [MR=dumux:3442](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3442)Mathis KelmMathis Kelmhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course/-/issues/43Changes to an exercise are not transferred to the solution2023-04-28T14:08:44ZBernd FlemischChanges to an exercise are not transferred to the solutionIt's error-prone that changes to an exercise don't get transfered to the corresponding solution. Find ways to
- check if the solution matches the exercise by, for example, maintaining a patch describing the change from exercise to solut...It's error-prone that changes to an exercise don't get transfered to the corresponding solution. Find ways to
- check if the solution matches the exercise by, for example, maintaining a patch describing the change from exercise to solution and integrate the patch application and check in the CI.
- automate from the solution to the exercise or vice versa.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course/-/issues/41Recap - Dumux Course 20232023-04-26T15:08:20ZIvan BunticRecap - Dumux Course 2023Minutes of the post-course discussion:
#### How to improve slides
- Tone down property system and multidomain slides -> include more images and refer to advanced documentation.
- Putting in images in the beginning of a presentation brin...Minutes of the post-course discussion:
#### How to improve slides
- Tone down property system and multidomain slides -> include more images and refer to advanced documentation.
- Putting in images in the beginning of a presentation brings people up to speed, invigorate interest.
- Maybe too many code snippets on the slides, also difficult to read from the back (code snippets) and understand what they do. If code is longer than 3 lines, basically useless.
- Not necessary to put whole interface of function on slides. Full signature is seen in exercise.
- Initial settings of our slides (we used to have) might be preferable, because it forces you to keep the code snippet short and clear. Never have pseudo code in README, but might be useful for slides. However, with pseudo code people might not be able to transfer.
#### How to handle prerequisites for the course
- Maybe have additional pre dumux-course day: how to use shell, git, WSL - maybe expect people to come with that knowledge.
- Probably cannot start at the level of explaining shell etc. - we are here to present Dumux, not the basic stuff
-> maybe make slides much easier. Exercises seem to work pretty well, as they are very easy. However, people might be underwhelmed if made too easy.
- We usually overestimate audience, though level of knowledge is very diverse.
- At least a short cheat sheet for shell could be helpful, ask HLRS for material: how to use linux - might require more days than 3 days in the end.
- Prepare participants for C++/templates, tell them what knowledge we expect them to bring. Ned has some good exercises for c++, maybe do: if they can solve these exercises, then they are good to go.
- Big thing: do we want to provide basic instructions on shell, ...
#### How to improve exercises
- Present the solution after an exercise - that would help people follow our procedure and thoughts. Maybe cut after 1 hour of doing an exercise and tell those how are already done can do other stuff, but for those who want to see the solution, this might be helpful.
- Maybe introduce used model (equations, mathematical problem...) in the beginning of the README of an exercise and do not only show domain. However, do not force people to read these equations, make it optional, link to module, make it dropdown etc.
- Incentivise people to do the next task - make clear what you actually in a task, what do you get out of it?
- Make commands in exercise more clear, "in which folder do I have to be to execute this command?". For example, show in the first exercise, so everyone knows, how to navigate folders within the terminal, how to configure with cmake etc.
#### Evaluation
- It was suggested to have a continuous form of evaluation, not only on the first day - in the end it is difficult to remember what went well and what went bad on the first days.
#### What else to cover in the course
- Tips on how to read and deal with an error: start at top, search for red stuff. Maybe show most frequent errors and how to solve them (how to choose which ones would be the most frequent ones)?
-> could be included in the part when we present the solution by ourselves. Put in errors on purpose and show how to handle them.
- Present the documentation, what we have, handbook, doxygen...
#### General thought and tasks
- Pure online format might be possible? But not hybrid. Online, you cannot help them that well and it is difficult to interact. People also get easily distracted.
- Introduce online forum for the course (on our website?)?
- Big task for next release: make doxygen better.https://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/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/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/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-web-app/-/issues/29simulation in docker runs not with user namespace isolation in deployment2022-11-30T16:58:31ZDavid Wernersimulation in docker runs not with user namespace isolation in deploymentThe user namespace isolation ([userns-remap](https://docs.docker.com/engine/security/userns-remap/)) is a suggested mean to run the processes of docker as non-root except for docker daemon itself. What fails with dumux-web-app is sharin...The user namespace isolation ([userns-remap](https://docs.docker.com/engine/security/userns-remap/)) is a suggested mean to run the processes of docker as non-root except for docker daemon itself. What fails with dumux-web-app is sharing of the directory for data (flask-backend with docker) via mount (possible bind mount). Maybe it would be better to omit the mount in some way if possible.