interfoam performance
 

Hi to all,
I have a similar problem whit the performance of inteFoam. My problem concern a circular pipe filled with liquid and closed to both extremity. At initial time the right wall of the pipe is opened and gas allowing gas to go inside and liquid outside. My aim is to validate OpenFOAM for this kind of problem so I compared its performance with Fluent.
The comparison seems very good but there is a strange difference.
In my simulations I use a fixed Courant number and adaptive time step. The difference between is that Fluent give me a deltaT around 10e-04 while OpenFOAM give me a deltaT around 10e-6.So the simulation run very slow with OpenFOAM...Why this different behavior?There i a way to speed simulation?
I obtain a little accelerate through decreasing tolerance but I would obtain i larger time step if possibile and kwon why there is this difference between two code.

thanks to all

If you are using the solver settings from the tutorials, you may have the maxCo and maxAlphaCo both set to 0.5. I typically will push these to 2.0 and 1.0 (at least) and then set nAlphaSubCycles to 5 in fvSolutions. Depending on how you have configured the BCs what is likely happening is that you are getting high velocities in the gas phase (probably inflow on a pressure outlet) that are driving down the dt. Setting maxCo to a higher value than maxAlphaCo will let the time step be controlled more by the velocities near the interface.

Thanks for your reply
I increase my Courant number to 0.8 in order to obtained a faster solution but with this Co I obtained a fluctuating solution. In fact, for this kind of problem the Courant number must not be more than 0.5, other experience says that courant number must not be more than 0.35 so I set its to 0.25. Regarding the velocity fields it seems ok. With the calculated velocity the courant number should be about 10e-04 but is 10e-06

This precisely why you use sub-time stepping on alpha. So if you set maxAlphaCo to 0.5 and nAlphaSubCycles is 3 then you have a Co per alpha step of 0.5/3 = 0.167. This is why I say use 1.0/5 = 0.2. You could push it to 1.5/5 = 0.3 and still probably be OK.

I set nAlphaSubCycles=2.
Two questions about you reply.
1)There is a way to verify if the real Courant numeber is Co/nAlphaSubCycles? Beacause in the output file the max Courant number remain fixed to 0.25 and not to 0,1225
2)I know that nAlphaSubCycles are the subcycle inside alpha equation. Through subcycle we have a more stable solution without incresing time step. Why nAlphaSubCycles should have to change Courant number?

So when you say Courant number are you meaning maxCo or maxAlphaCo? interFoam should print out both values.

...
Courant Number mean: 0.0785872 max: 0.47472
Interface Courant Number mean: 0.0125036 max: 0.36383
deltaT = 0.00105904
Time = 0.228819
...

Here, "Courant Number" is limited by the maxCo setting in controlDict and "Interface Courant Number" is limited by maxAlphaCo.

In the VOF-style algorithm, only the Co at the interface is the problem. The Co has to be small enough that it takes ~4 time 'steps' for the interface to travel through a cell. So it comes from the local mesh size and local velocity--not sure if you are taking that into account when calculating by hand. Since the solution of the volume fraction transport will be the limiting thing on time step size AND since all the computational time is spent in the pressure solve with the alpha solve being relatively cheap, you solve the alpha eqn multiple times with smaller time-steps for every one pressure solve. This is nAlphaSubCycles. Anyway, if you have nAlphaSubCycles set to 2 and you put the maxAlphaCo to 0.8 then you are having and effective max Co on each alpha solve of 0.4 which is unstable as you have seen. In any case, the value printed at each timestep is the OVERALL Co so to get the Co on a given sub-time step of alpha you divide this by nAlphaSubCycles. It changes Co because the time step size on each sub-cycle step is dt/nAlphaSubCycles.

If you really want to check what the Co field looks like at any point in time, you would have to tweak the solver or add in a functionObject.

One other thing to keep in mind is that things get crazy (interface oscillations and parasitic currents) if cAlpha is greater than 1.0 (it may be 2.0 in some of the old tutorial cases).

Hope this helps.
-Kent

when I talking about Courant number I mean maxCo.
So you suggest to set maxCo=0.9 (explicit solver) and maxAlphaCo=2 with nAlphaSubCycles=10?
thanks you very much for your replies

No, I suggest:
maxCo=2.0
maxAlphaCo=1.0
nAlphaSubCycles=5

I understand why I must set maxAlphaCo=1.0 and nAlphaSubCycles=5.
last question:
interFoam is an explicit solver so maxCo have to set <1,why you suggest maxCo=2.0? the nAlphaSubCycles acts also in p and U equations?I thinked no

Hi all,

Could anyone please explain why we use MULES in alpha equation and not solve method?

Thanks,

Hrushi

The volume fraction equation has special requirements with regard to boundedness, conservation and diffusivity. Thus we use a special algorithm to solve it.

Hi Anton,

Thank you for a quick reply. I have couple of follow up questions:

1. Do you know any reference that discusses these special requirements? I have read Rusche's thesis but did not find anything for this.
2. Will these requirements hold true when we change the range of fraction from 0:1 to -1:1?

Thanks

Hrushi

Rusche's thesis does contain a brief section on how to deal with the issues - 3.2.6. Any paper dealing with the VoF method or how to improve it likely has information on the subject. In short:
1. Conservation - As an example if you have a bubble, you do not want the bubble volume to grow or shrink. It may significantly change the outcome of your simulation.
2. Boundedness - since all material properties are interpolated between the two phases, unboundedness can very quickly lead to divergence (e.g. due to negative density)
3. Diffusivity - Numerical diffusivity will eventually get rid of your fluid interface if not dealt with properly. Of course that's not acceptable for immiscible fluids.

Well, solve with the proper advection TVD schemes should also do the work. In fact TVD schemes were designed to do exactly that. The problem is that, in practice, this is only true in 1D not in multi-dimensions, in this case FCT based schemes behave better. I discuss the topic in my PhD. thesis, that is provided in my user page at openfoamwiki.net: http://openfoamwiki.net/index.php/User:Santiagomarquezd

Regards.

Hi Anton and Santiago,

Thank you for your quick reply. Really appreciate it.

I am trying to solve a modified alpha equation with interfoam solver. I have no compression velocity and a chemical potential term in my alpha equation. I could not get any results with solve method, which is why I posted the question. Yesterday, I tried solving the alpha equation using mules.


for (int aCorr=0; aCorr<nAlphaCorr; aCorr++)
{
surfaceScalarField phiAlpha (fvc::flux(phi,alpha1,alphaScheme));
/* solve
(
fvm::ddt(alpha1)+ (fvc::div(phiAlpha)) - fvc::div(diffflx)
);*/

MULES::implicitSolve(geometricOneField(), alpha1, phi, phiAlpha, volScalarField("Sp",mobility*fvc::laplacian(G)), zeroField(), 1, 0);


rhoPhi = phiAlpha*(rho1 - rho2) + phi*rho2;
}


But my output says that I have maximum of alpha1 more than 1 at the start, which gradually reaches one but still stays more than 1 at equilibrium.

Due to this, my results are really weird, and I do not know how to proceed. Any ideas?

Thanks,

Hrushi

Hi Andrea :-
Now, as we have the fifth version of OpenFOAM, do you think we overcame that problem? I am trying to simulate the water flow in a 20-micron capillary tube but admirably, I shocked when running the capilaryRise example on OF5 and have the interface oscillations ( and it is just a simple case of 20 mm channel 2D flow!).
When I run mine 20-micron case with very fine mesh, I have overly increased
or decreased alpha values. what are your recommendations?
my best!