dumux issues
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues
2024-03-25T10:40:18Z
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/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/1335
Dispersion tensors
2024-01-25T14:22:59Z
Martin Schneider
Dispersion tensors
The current implementations of `ScheideggersDispersionTensor` and `FullDispersionTensor` are not very useful for real applications.
This is because of the following interfaces assumed in the spatialParams
- `problem.spatialParams().disp...
The current implementations of `ScheideggersDispersionTensor` and `FullDispersionTensor` are not very useful for real applications.
This is because of the following interfaces assumed in the spatialParams
- `problem.spatialParams().dispersionTensor(scvf.center(), phaseIdx, compIdx)` (`FullDispersionTensor`)
- `std::array<Scalar,2> dispersivity = problem.spatialParams().dispersionAlphas(scvf.center(), phaseIdx, compIdx);` (`ScheideggersDispersionTensor`)
- `velocity = problem.spatialParams().velocity(scvf);` (`ScheideggersDispersionTensor`)
The first two functions assume that the full tensor or the alpha parameters can be determined by the position. However, usually this is not the case but rather by some element marker, etc.
Also for the full tensor it is unlikely that the position is suitable for determining the tensor. E.g. for thermal dispersion, one usually multiplies with fluid density...
The velocity call is one needed when assuming a stationary velocity field. However, when using the Box scheme and having a pre-calculated velocity field on scvfs, just passing the scvf as an argument is not enough for directly accessing a container that stores these velocities, because the Box scvf only knows its local index and not a global one.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1290
Add convenience function to construct default gridgeometry given a discretiza...
2023-08-01T21:59:07Z
Timo Koch
timokoch@math.uio.no
Add convenience function to construct default gridgeometry given a discretization scheme
`makeGridGeometry<DiscMethod>(gridView, ...)`
`makeGridGeometry<DiscMethod>(gridView, ...)`
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1221
Anisotropic permeability Law
2024-03-25T10:38:56Z
Johannes Hommel
Anisotropic 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.9
Johannes Hommel
Johannes Hommel
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1218
Code quality report Gitlab+cppcheck
2023-02-10T16:26:51Z
Timo Koch
timokoch@math.uio.no
Code quality report Gitlab+cppcheck
Using this tool https://gitlab.com/ahogen/cppcheck-codequality
we might be able to integrate the cppcheck report with Gitlab
Using this tool https://gitlab.com/ahogen/cppcheck-codequality
we might be able to integrate the cppcheck report with Gitlab
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1217
Parallel computing for Navier-Stokes
2023-02-28T15:08:26Z
Mojtaba Barzegari
Parallel computing for Navier-Stokes
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 ...
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/1173
Remove scv/scvf.geometry()/corner()
2023-12-13T14:27:03Z
Timo Koch
timokoch@math.uio.no
Remove 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.9
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1156
FluxVariables is a misnomer
2023-10-26T08:07:56Z
Timo Koch
timokoch@math.uio.no
FluxVariables is a misnomer
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 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.9
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1146
Investigate parallel assembly with Python
2023-02-22T08:57:02Z
Timo Koch
timokoch@math.uio.no
Investigate parallel assembly with Python
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, 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 (?)
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1105
(Velocity-dependent) Dispersion for tpfa
2023-11-24T08:25:06Z
Timo Koch
timokoch@math.uio.no
(Velocity-dependent) Dispersion for tpfa
Constant dispersion tensor are implemented in !2921.
Velocity-dependency (fully-implicit) could be realized by using a cell velocity-based scheme and harmonic averaging of the dispersion tensor on the face. But this extends the flux ste...
Constant dispersion tensor are implemented in !2921.
Velocity-dependency (fully-implicit) could be realized by using a cell velocity-based scheme and harmonic averaging of the dispersion tensor on the face. But this extends the flux stencil of a single flux to the element stencil required for the velocity reconstruction.
Follow-up from #320 and !2921.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1000
[freeflow] Properly include the volume work term in the energy balance
2023-07-24T13:11:04Z
Kilian Weishaupt
[freeflow] Properly include the volume work term in the energy balance
We currently implement
$`\frac{\partial}{\partial t}(\rho u) = - \nabla \cdot (\rho \mathbf{v}h) + \nabla \cdot (\lambda \nabla T)`$
with $`h = u + \frac{p}{\rho}`$
However, the a correct form of the energy balance equation is (see ...
We currently implement
$`\frac{\partial}{\partial t}(\rho u) = - \nabla \cdot (\rho \mathbf{v}h) + \nabla \cdot (\lambda \nabla T)`$
with $`h = u + \frac{p}{\rho}`$
However, the a correct form of the energy balance equation is (see !2473, !2471)
$`\frac{\partial}{\partial t}(\rho u) = - \nabla \cdot (\rho \boldsymbol{v}u) + \nabla \cdot (\lambda \nabla T) \underbrace{- p \left(\nabla\cdot{\boldsymbol{v}}\right)}_{\text{volume work}} + \underbrace{2\mu\boldsymbol{D}(\boldsymbol{v}) : \boldsymbol{D}(\boldsymbol{v})}_{\text{viscous dissipation}} `$
where $`\vec{D}(\vec{v}) = \frac{1}{2}\left( \nabla{\vec{v}} + \nabla{\vec{v}}^T \right)`$.
Viscous dissipation can often be neglected. Replacing enthalpy with internal energy in the first divergence term is simple but
the discretization of
$`p \nabla \cdot \mathbf{v}`$
is not straight-forward.
A possible simple solution would be:
Include in calculation of flux terms, i.e., evaluate $`\nabla \cdot \mathbf{v}`$
and assume a cell-constant $`p`$ which is just multiplied to the term. This gives a first-order scheme but should be ok since the term is often small. For incompressible flow the term also vanishes discretely since $`\nabla \cdot \mathbf{v} = 0`$.
This seems to work for cell-centered schemes without much additional effort (!2494).
For the box method it seems more difficult since the code assumes that fluxes on scvfs are symmetric. However the energy contribution (assembled on the scvfs) is different depending on the control volume (different control volume pressure).
Another solution is to implement the full conservative form of the energy equation
```math
\frac{\partial}{\partial t}\left( \frac{1}{2}\rho ||{\boldsymbol{v}}||^2 + \rho u \right) =
- \nabla\cdot{\left( \left[\frac{1}{2}\rho ||{\boldsymbol{v}}||^2 + \rho u \right] \boldsymbol{v}\right)}
+ \nabla\cdot{\left( \boldsymbol{T} \boldsymbol{v} + \lambda \nabla T\right)}
+ \rho \boldsymbol{v}\cdot \vec{g},
```
where $`\boldsymbol{T} = 2\mu\boldsymbol{D}(\boldsymbol{v}) - p\boldsymbol{I}`$.
__Edit 24 Jul 23 (@timok):__ included viscous dissipation term, annotations and conservative energy balance.
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/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/839
[freeflow][test] Add analytical solution to non-isothermal test
2023-02-22T08:55:56Z
Kilian Weishaupt
[freeflow][test] Add analytical solution to non-isothermal test
There are analytical solutions for some non-isothermal porous medium tests.
We could do the same for the free flow model.
There are analytical solutions for some non-isothermal porous medium tests.
We could do the same for the free flow model.
Kilian Weishaupt
Kilian Weishaupt
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/807
[RANS] Evaluate possibility to chose turbulence model at runtime
2023-09-27T08:51:41Z
Kilian Weishaupt
[RANS] Evaluate possibility to chose turbulence model at runtime
Currently, we have a myriad of different RANS models (zeroeq, oneeq, twoeq-kepsilon, twoeq-komega, twoeq-lowrekepsilon).
Maybe we could choose the turbulence model (at least for the two-eq models) at runtime.
This would decrease the nu...
Currently, we have a myriad of different RANS models (zeroeq, oneeq, twoeq-kepsilon, twoeq-komega, twoeq-lowrekepsilon).
Maybe we could choose the turbulence model (at least for the two-eq models) at runtime.
This would decrease the number of executables for the tests and maybe also decrease the effort to add new turbulence models.
3.9
Ned Coltman
Ned Coltman
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.