Flawed behaviour of cAlphas in icoReactingMultiphaseInterFoam
Summary
The cAlphas values between two interacting phases seem to get overwritten by a third phase, which is specified, but not actually involved in the calculation.
Steps to reproduce
2 minimal examples are attached. The correct one shows the correct behavior and the wrong one shows the wrong behavior. The difference between the two cases is the following representation of the linear solvers for alpha in fvSolution.
For the wrong example:
"alpha.*"
{
nAlphaCorr 2;
nAlphaSubCycles 1;
cAlphas (
(solid and water) 0
(air and solid) 0
(air and water) 1
);
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-6;
relTol 0;
}
For the correct example:
"alpha.*"
{
nAlphaCorr 2;
nAlphaSubCycles 1;
cAlphas (
(solid and water) 1
(air and solid) 1
(air and water) 1
);
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-6;
relTol 0;
}
Example case
A small case with a single sphere in a cube is provided in the correct and wrong version. Both cases are attached as described above. cAlphasBugCases.tar.gz
What is the current bug behaviour?
The bug occurred in the solver icoReactingMultiphaseInterFoam when 3 or more phases are present (e.g. water, air and solid), even when only 2 are involved in the calculation (water and air). If the interface compression value cAlphas between the third phase (solid) and the calculated two phases (water and air) is set to 0, the interface compression between the calculated two phases (water and air) seems to become 0 as well. This results in incorrect blurring of the interface.
What is the expected correct behavior?
Since cAlphas for (air and water) is 1 in both cases, the interface should behave equal and stay sharp. But it does not. The cAlphas between (air and solid) or (water and solid) changes the behavior of the interface between (air and water).
Relevant logs and/or images
Environment information
- OpenFOAM version : v1906
- Operating system : ubuntu
- Hardware info :
- Compiler : gcc
Possible fixes
I think, the cAlphas value of the two calculated phases gets overwritten by the third phase. If this is the case, it should be prevented. But I could not find where that happens in the code and I am not sure if this is the actual problem either.