|
|
mass_conservation_multiphaseInterFoam+fvOptions::MRF.png (10,710 bytes) |
|
|
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 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 |
|
|
OK, I will look into this on the small test case when you have it ready. |
|
|
mIF_testcase.png (21,089 bytes) |
|
|
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 test-case, 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.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. |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
Thanks a lot for the clarification! |
- Anonymous
