Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • openfoam openfoam
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 426
    • Issues 426
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 9
    • Merge requests 9
  • Deployments
    • Deployments
    • Releases
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • openfoamopenfoam
  • Issues
  • #1441
Closed
Open
Issue created Sep 19, 2019 by Admin@OpenFOAM-adminMaintainer

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

Initial: initial

Correct: correct

Wrong: wrong

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.

Reattaching the author to the issue ticket: @Basti

Edited Dec 11, 2019 by Kutalmış Berçin
Assignee
Assign to
Time tracking