View Issue Details

IDProjectCategoryView StatusLast Update
0001685OpenFOAM[All Projects] Bugpublic2015-05-30 12:03
ReporterandrasAssigned Tohenry 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version12.04
Product Version 
Fixed in Version 
Summary0001685: multiphaseInterFoam + fvOptions.MRF does not conserve mass
DescriptionMass conservation for multiphaseInterFoam + MRF works for 2D tutorial case, but not in more complex 3D geometries. Mass change depends on decompositon method and the number of processor meshes. Change in mass becomes evident only after a few hundred to a few thousand iterations (depending on the case). See plot in attachment.
Steps To ReproduceUse multiphaseInterFoam + fvOptions.MRF in combination with 3D geometries. Run in parallel.

Densities for 3 phases used in test case were: 1.1, 1000, 1060 kg/m^3. Sigma was 0.07 for all phase combinations.

Lowering the global CFL number and increasing nAlphaCorr, nAlphaSubCycles gives better stability without solving the problem concerning mass conservation.

Numerical schemes are the same as in the tutorial case.
Additional InformationTest case can be supplied on demand.
TagsNo tags attached.

Activities

andras

2015-05-07 11:33

reporter  

henry

2015-05-07 12:17

manager   ~0004723

Can you supply a small test case which reproduces the problem?

andras

2015-05-08 10:55

reporter   ~0004733

The test case I have uses 800000 cells and three phases with an average deltaT=0.000671s at Co=0.3. So it takes some time to solve.

I will try to construct a _small_ case that shows the same problems in the solver and get back to you...

andras

2015-05-13 14:54

reporter   ~0004737

Henry,
I am still working on a small test case to reproduce the problem.

In the meantime I uploaded a video ( https://www.dropbox.com/s/blq0fqhc4y8jncp/mFI_bug.mp4?dl=1 ) to clarify that the problem depends on the decompose algorithm! There is no change in volume fraction in multiphaseInterFoam when running single core.

It's interesting that the global rate of change (dalpha/dt) seems to be constant when using scotch.

FYI: the case from which the video was produced is found here:
https://www.dropbox.com/s/0ikxljohxngbwf1/spout_MRF_no_baffles_3phase_tilted_32x_simple.tar.gz


Cheers
Andras

henry

2015-05-14 12:07

manager   ~0004738

If the conservation error you see is dependent on the decomposition it is likely to relate to solver convergence, in particular the pressure equation, the convergence of which directly relates to mass conservation. Try tightening the pressure convergence tolerance.

andras

2015-05-15 10:25

reporter   ~0004743

Henry,
I did a run using the above case with lower solver tolerances and compared the results.



*** Solver settings ***

*** system/fvSolution."tight" ***


    p_rgh
    {
        solver GAMG;
        tolerance 1e-9;
        relTol 0.01;
        smoother GaussSeidel;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 10;
        agglomerator faceAreaPair;
        nPreSweeps 0;
        nPostSweeps 2;
        mergeLevels 1;
    }

    "pcorr.*"
    {
        $p_rgh;
        tolerance 0.1;
        relTol 0;
    }

    p_rghFinal
    {
        $p_rgh;
        relTol 0;
    }





*** system/fvSolution."standard" ***


    p_rgh
    {
        solver GAMG;
        tolerance 1e-6;
        relTol 0.02;
        smoother GaussSeidel;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 10;
        agglomerator faceAreaPair;
        nPreSweeps 0;
        nPostSweeps 2;
        mergeLevels 1;
    }

    "pcorr.*"
    {
        $p_rgh;
        tolerance 0.1;
        relTol 0;
    }

    p_rghFinal
    {
        $p_rgh;
        relTol 0;
    }






*** Results :: phase fraction of water ***


decomposer: scotch, solver settings: tight
  Time = 0.000: water volume fraction = 0.600016918
  Time = 3.830: water volume fraction = 0.565784888


decomposer: scotch, solver settings: standard
  Time = 0.000: water volume fraction = 0.600016918
  Time = 3.830: water volume fraction = 0.565831361


decomposer simple, solver settings: standard
  Time = 0.000: water volume fraction = 0.600016918
  Time = 3.830: water volume fraction = 0.602931215





Cheers
Andras

henry

2015-05-15 11:03

manager   ~0004744

OK, I will look into this on the small test case when you have it ready.

andras

2015-05-19 09:36

reporter  

mIF_testcase.png (21,089 bytes)
mIF_testcase.png (21,089 bytes)

andras

2015-05-19 09:42

reporter   ~0004775

Henry,
I created a small test case (with 45k cells) for multiphaseInterFoam showing the problems with parallel runs described above (see also the plot "mIF_testcase.png"):


https://www.dropbox.com/s/4tdyd3peu97m6vd/mIF_testcase.tar.gz?dl=0


Just tell me if/how I can support you to resolve this.


Cheers
Andras

henry

2015-05-24 23:38

manager   ~0004797

Thanks for the small test-case, it has proved very helpful. I believe I have found the problem and will work on it tomorrow.

sharonyue

2015-05-25 09:40

reporter   ~0004798

Last edited: 2015-05-25 09:47

View 3 revisions

Hello Henry!

this problem(exactly the same with andras reported) also happened with twoPhaseEulerFoam22x and compressibleTwoPhaseEulerFoam22x. twoPhaseEulerFoam23x behaves better, but after a long run it also have this problem. And I also see a big difference when running in parallel or serial. Serial running behaves better.

This is the log from the 23x's tutorial of mixer2D:

Starting time loop

Courant Number mean: 0 max: 0
Max Ur Courant Number = 0
deltaT = 0.000119904
Time = 0.000119904

PIMPLE: iteration 1
MULES: Solving for alpha.air
MULES: Solving for alpha.air
alpha.air volume fraction = 0.2 Min(alpha1) = 0.2 Max(alpha1) = 0.2
smoothSolver: Solving for e.air, Initial residual = 1, Final residual = 9.53332e-13, No Iterations 2
smoothSolver: Solving for e.water, Initial residual = 1, Final residual = 4.50922e-11, No Iterations 1
min T.air 322.718
min T.water 499.999
GAMG: Solving for p, Initial residual = 1, Final residual = 0.000287157, No Iterations 1
PIMPLE: iteration 2
MULES: Solving for alpha.air
MULES: Solving for alpha.air
alpha.air volume fraction = 0.200006 Min(alpha1) = 0.191234 Max(alpha1) = 0.209036
smoothSolver: Solving for e.air, Initial residual = 1, Final residual = 2.95221e-10, No Iterations 2
smoothSolver: Solving for e.water, Initial residual = 1, Final residual = 2.10297e-09, No Iterations 2
min T.air 323.721
min T.water 499.985
GAMG: Solving for p, Initial residual = 0.96264, Final residual = 0.00521211, No Iterations 1
PIMPLE: iteration 3
MULES: Solving for alpha.air
MULES: Solving for alpha.air
alpha.air volume fraction = 0.200009 Min(alpha1) = 0.194854 Max(alpha1) = 0.213568
smoothSolver: Solving for e.air, Initial residual = 0.63604, Final residual = 2.00175e-10, No Iterations 2
smoothSolver: Solving for e.water, Initial residual = 0.711878, Final residual = 8.23037e-09, No Iterations 2
min T.air 325.674
min T.water 499.986
GAMG: Solving for p, Initial residual = 0.710718, Final residual = 1.6303e-08, No Iterations 4
ExecutionTime = 0.11 s

we can see alpha is changing in one timestep. I run it in serial.

henry

2015-05-25 09:47

manager   ~0004799

The issue being discussed here relates to MRF not AMI. The non-conservation and boundedness issues of the current AMI implementation are well known and have been reported here several times.

The MRF issue reported here relates to the outer faces of MRF region not being parallel to the motion, i.e. not the surface of a cylinder. This is not seen in the MRF tutorials because the MRF region is better constructed. I would say that the mesh provided for this case is not really suitable for MRF but the code should maintain boundedness anyway and I will work on the face-transformation consistency in parallel to resolve the issue.

henry

2015-05-25 11:37

manager   ~0004803

I have added a call to synchronize the faceType across processor patches which should resolve the conservation and boundedness issues relating to non-aligned MRF zone outer faces.

I have pushed the fix to OpenFOAM-dev,2.4.x and 2.3.x.

I have your case running and so far it looks better.

andras

2015-05-25 12:14

reporter   ~0004804

Henry,
thanks a lot!

I will recompile 2.3.x with your changes, run my bigger case and keep you updated if/how the syncing of the faceTypes worked out with both scotch and simple decomposers.



Slightly off topic -- I know, I know -- but out of curiosity:

How would you construct a suitable mesh (using snappyHexMesh and other available OpenFOAM tools) of a tilted cylinder with complex internals inside another cylinder, i.e. a tilted stirrer in a tank, avoiding non-aligned cells at the MRF boundary?

Is this possible? Is it possible without using mergeMeshes and the side effect of having polyhedral cells with low quality at the MRF boundary?

Non aligned nodes with AMI+fvOptions.MRF seems to be no viable option for (multiphase)InterFoam... :[



Cheers,
Andras

henry

2015-05-25 12:49

manager   ~0004805

You can snap to a non-aligned internal cylinder which will ensure the surface faces of the MRF/AMI region are correctly oriented but of course the cells will not be aligned.

To get cells aligned in different regions you will need a complex block-mesher or one with more general morphing functionality. In principle foamyHexMesh would be appropriate for your case but the current beta-release version is not very reliable so you would need to spend some time tuning the parameters.

andras

2015-05-25 13:21

reporter   ~0004807

Thanks a lot for the clarification!

Issue History

Date Modified Username Field Change
2015-05-07 11:33 andras New Issue
2015-05-07 11:33 andras File Added: mass_conservation_multiphaseInterFoam+fvOptions::MRF.png
2015-05-07 12:17 henry Note Added: 0004723
2015-05-08 10:55 andras Note Added: 0004733
2015-05-13 14:54 andras Note Added: 0004737
2015-05-14 12:07 henry Note Added: 0004738
2015-05-15 10:25 andras Note Added: 0004743
2015-05-15 11:03 henry Note Added: 0004744
2015-05-19 09:36 andras File Added: mIF_testcase.png
2015-05-19 09:42 andras Note Added: 0004775
2015-05-24 23:38 henry Note Added: 0004797
2015-05-25 09:40 sharonyue Note Added: 0004798
2015-05-25 09:47 sharonyue Note Edited: 0004798 View Revisions
2015-05-25 09:47 henry Note Added: 0004799
2015-05-25 09:47 sharonyue Note Edited: 0004798 View Revisions
2015-05-25 11:37 henry Note Added: 0004803
2015-05-25 12:14 andras Note Added: 0004804
2015-05-25 12:49 henry Note Added: 0004805
2015-05-25 13:21 andras Note Added: 0004807
2015-05-30 12:03 henry Status new => resolved
2015-05-30 12:03 henry Resolution open => fixed
2015-05-30 12:03 henry Assigned To => henry