View Issue Details
ID  Project  Category  View Status  Date Submitted  Last Update 

0001685  OpenFOAM  [All Projects] Bug  public  20150507 11:33  20150530 12:03 
Reporter  andras  Assigned To  henry  
Priority  normal  Severity  major  Reproducibility  always 
Status  resolved  Resolution  fixed  
Platform  GNU/Linux  OS  Ubuntu  OS Version  12.04 
Product Version  
Fixed in Version  
Summary  0001685: multiphaseInterFoam + fvOptions.MRF does not conserve mass  
Description  Mass 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 Reproduce  Use 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 Information  Test case can be supplied on demand.  
Tags  No tags attached.  



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

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... 

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 

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. 

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 1e9; 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 1e6; 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 

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



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 

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

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.53332e13, No Iterations 2 smoothSolver: Solving for e.water, Initial residual = 1, Final residual = 4.50922e11, 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.95221e10, No Iterations 2 smoothSolver: Solving for e.water, Initial residual = 1, Final residual = 2.10297e09, 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.00175e10, No Iterations 2 smoothSolver: Solving for e.water, Initial residual = 0.711878, Final residual = 8.23037e09, No Iterations 2 min T.air 325.674 min T.water 499.986 GAMG: Solving for p, Initial residual = 0.710718, Final residual = 1.6303e08, No Iterations 4 ExecutionTime = 0.11 s we can see alpha is changing in one timestep. I run it in serial. 

The issue being discussed here relates to MRF not AMI. The nonconservation 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 facetransformation consistency in parallel to resolve the issue. 

I have added a call to synchronize the faceType across processor patches which should resolve the conservation and boundedness issues relating to nonaligned MRF zone outer faces. I have pushed the fix to OpenFOAMdev,2.4.x and 2.3.x. I have your case running and so far it looks better. 

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 nonaligned 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 

You can snap to a nonaligned 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 blockmesher or one with more general morphing functionality. In principle foamyHexMesh would be appropriate for your case but the current betarelease version is not very reliable so you would need to spend some time tuning the parameters. 

Thanks a lot for the clarification! 
Date Modified  Username  Field  Change 

20150507 11:33  andras  New Issue  
20150507 11:33  andras  File Added: mass_conservation_multiphaseInterFoam+fvOptions::MRF.png  
20150507 12:17  henry  Note Added: 0004723  
20150508 10:55  andras  Note Added: 0004733  
20150513 14:54  andras  Note Added: 0004737  
20150514 12:07  henry  Note Added: 0004738  
20150515 10:25  andras  Note Added: 0004743  
20150515 11:03  henry  Note Added: 0004744  
20150519 09:36  andras  File Added: mIF_testcase.png  
20150519 09:42  andras  Note Added: 0004775  
20150524 23:38  henry  Note Added: 0004797  
20150525 09:40  sharonyue  Note Added: 0004798  
20150525 09:47  sharonyue  Note Edited: 0004798  View Revisions 
20150525 09:47  henry  Note Added: 0004799  
20150525 09:47  sharonyue  Note Edited: 0004798  View Revisions 
20150525 11:37  henry  Note Added: 0004803  
20150525 12:14  andras  Note Added: 0004804  
20150525 12:49  henry  Note Added: 0004805  
20150525 13:21  andras  Note Added: 0004807  
20150530 12:03  henry  Status  new => resolved 
20150530 12:03  henry  Resolution  open => fixed 
20150530 12:03  henry  Assigned To  => henry 