[markc]

Sorry to dig in. As far as I can see in e.g. interFoam there is only 1 U. The statement in the presentation is not implemented. And reading chpter 4 of PhD thesis of Rusche, this formulation is also not used. However, Rusche also describes a two-fluid approach, which more resembles the U statement.
Maybe another addition: it has also be proposed (e.g. by Jasak, Paterson) to damp the "air" side velocity by implementing a extra line in the U eqn: UEqn += gamma*fvm::div(rhoPhi, U);

Is this equivalent...? Im afraid not.

Interesting thread though.

Brgds,

Mark

[pbohorquez]

Hi Sebastian:

if you are interested in a formal deduction of the VOF method from the point of view of the two-fluid model, and its connection with the OF implementation, my thesis (pp 12-14, ...) might help you.

http://infoscience.epfl.ch/record/130534

[egp]

@Patricio: Nice job on the thesis! Looks very complete and of high quality. Thank you for posting it. I've already forwarded it to colleagues who are working on sediment transport.

@Everyone: Threads like this one would completely disappear if each of the distributed solvers had either a "theory paper" or a link to a published document. Since OpenCFD is not able, or interested, to do this, I would suggest that the community, and especially the Special Interest Groups (SIGs), take this on for the solvers in their interest areas.

"If you would not be forgotten as soon as you are dead and rotten, either write something worth reading or do things worth the writing"

-Benjamin Franklin

[ngj]

Hi

@Patricio: I would like to take Eric's lead and say that it looks like interesting reading. I am going to consider sediment transport and morphology as well, so it is nice to see people succeeding in applying OF to such problems. Especially I am looking forward to be reading about your VOF approach on the sediment bed. Especially on how you managed to get the correct bed shear stress and details like that. (Though it is not directly related to this thread, thus not a question)

Have a good weekend,

Niels

[isabel]

After reading this discussion, I still have some doubts about VOF in interFoam solver:

Wich equation gammaEqn.H solves? Perhaps this

d(gamma)dt+grad(gamma*U)=0

Where can I download the thesis "Computational Fluid Dynamics of dispersed Two-Phase Flows at High Phase Fractions"?

[isabel]

In the interFoam solver, what these lines in the file gamma.Eqn.H mean?

surfaceScalarField phiGamma =
fvc::flux
(
phi,
gamma,
gammaScheme
)
+ fvc::flux
(
-fvc::flux(-phir, scalar(1) - gamma, gammarScheme),
gamma,
gammarScheme
);

[isabel]

In the interFoam solver, where is defined the mass conservation equation? I am refering to:

divergence(U)=0

[tian]

Hi Marc,

did you find a solution to damp the "air" side velocity? I tried the extra line also but without success. The velocity increase and to hold my courant numer the time step decrease to very small and make my simulation time very slow...

Thanks.

Bye
Thomas

[Dinocrack]

Originally Posted by isabel

Where can I download the thesis "Computational Fluid Dynamics of dispersed Two-Phase Flows at High Phase Fractions"?

if you dont have it, here
http://powerlab.fsb.hr/ped/kturbo/Op...chePhD2002.pdf

[suraj]

Hello All,
I was looking at the way deltaN is defined. I did not understand the reason behind keeping deltaN a function of average mesh size (average(gamma.mesh().V()). I always thought that deltaN was a fixed small number required to keep nHatfv bounded, but as it turns out, it is not.

Thanks,
Suraj

[idrama]

Hey Seaga,

I read your post. Did you get any references about MULES?

Cheers,

Claus

[santiagomarquezd]

Originally Posted by eberberovic

The time derivative is accounted for within the MULES solver. In the gammaEqn.H only explicit fluxes are calculated, which are needed in MULES.

The interface.nHatf() represents a cell face unit interface normal flux. It is evaluated from the dot product of the cell face surface vector and the interface unit normal calculated at the cell face:

nHatf_ = nHatfv & Sf,

where

nHatfv = gradGammaf/(mag(gradGammaf) + deltaN_).

and deltaN is a stabilization factor for the case of gradGammaf = 0.

For the full implementation look in src/transportModels/interfaceProperties/interfaceProperties.C

Regards.

Edin, I'm studying the interFoam solver now, based on the code cfd-online posts and particularly on your paper: "Drop impact onto a liquid layer of finite thickness: Dynamics of the cavity evolution". Actually I'm focused in time marching, MULES, etc.
I understood Eq. 30 as a time subdivision in order to improve convergence and stability. I had hoped to use this small step in an explicit time marching loop actualizing VOF field in every substep. Although a different thing is done, calculating flux subdivisions and finally summing all of them to recover the whole timestep flux (Eq. 31). I recognize you are right here, that's in the code, but I can't understand this step at all. Could you explain a bit this topic to me? Do you hava any external reference in books, papers, about this method?

Regards. Santiago.

[sega]

Originally Posted by idrama

Hey Seaga,

I read your post. Did you get any references about MULES?

Cheers,

Claus

No, I have still no reference about MULES.

[kumar]

Hello Edin Berberovic and santiago,
I have been following this post closely to understand the MULES and VOF methodology implemented in OpenFOAM.
I just got the paper Drop impact onto a liquid layer of finite thicknessynamics of the cavity evolution. Thanks santiago for mentioning it, since i have been looking for a paper which explains the MULES.
I want to confirm that the MULES concept explained in that paper is the one implemented in OF-1.5, in the interFoam solver
What about OF-1.6.x, in which the pressure difference is handled in a different way. So could anybody tell me what is the major difference between the MULES explained in the paper and the one currently in OF-1.6.x, interFoam solver.

regards
K.Suresh kumar

[santiagomarquezd]

Kumar, Edin's paper is one of the most comprehensive papers about interFoam that I have found. It's true, it explains interFoam version 1.5 but the part about MULES is valid in 1.6.x also.
Changes in pressure treatment from pd to p are not affecting the MULES part, I've been studying MULES and it's important only in solving the non-linear advection equation (Eq. 15), in fact it is not mentioned in Edin's paper. Changes in pd affects only in mommentum equation formulation (Eq. 20).
Calling MULES is a strategy to solve Eq. 15, taking a look of alphaEqn.H we have,

00009     for (int aCorr=0; aCorr<nAlphaCorr; aCorr++)
00010     {
00011         surfaceScalarField phiAlpha =
00012             fvc::flux
00013             (
00014                 phi,
00015                 alpha1,
00016                 alphaScheme
00017             )
00018           + fvc::flux
00019             (
00020                 -fvc::flux(-phir, scalar(1) - alpha1, alpharScheme),
00021                 alpha1,
00022                 alpharScheme
00023             );
00024 
00025         MULES::explicitSolve(alpha1, phi, phiAlpha, 1, 0);
00026 
00027         rhoPhi = phiAlpha*(rho1 - rho2) + phi*rho2;
00028     }

by means of this solving and Eq. 31 a new flux is assembled in order
to solve the mommentum equation.
Hope these insights can be helpful, and will be valuable if other
foamers correct me and add more info. Please share your findings.

Regards

[eberberovic]

Hi.

Sorry for not answering, I was far too busy in the previous months.

Regarding the sub-cycling in gammaEqn, I have no references on that, but it indeed does what you are writing, i.e. the gamma field is being updates in every sub-cycle time step (in MULES, explicitly or implicitly) and the total face-flux is accumulated for the momentum equation.

There are also no references on MULES, but it is basically an additional limiter, which is used to clip or cut off the superfluous fluxes. The face-flux calculated using any limited scheme is represented as a sum of the upwind-flux and the corresponding flux correction. Then the limiter lambda is calculated, according to the worst (limiting) cases of gamma being equal to the maximum/minimum from the cells surrounding the cell of interest. Its value is between 1 and 0, which means that the flux corrections are either left unchanged, or the superfluous flux corrections are partially clipped, or the flux corrections are completely cut off reducing the scheme to upwind.

Hope this helps,
Edin.

[isabel]

Hello everybody,

Can anybody send me the paper "Drop impact onto a liquid layer of finite thickness: Dynamics of the cavity evolution"?

Mi mail is lamasgaldo@yahoo.es

[eberberovic]

Hi Isabel,

I've just sent you the paper PRE 2009. There is one typo in it, namely Eq. (24) represents the face flux rather than velocity at the cell-face. Sorry for this, it went also unnoticed by the reviewers.

Edin.

[eberberovic]

Hi Isabel,

I've just sent you the paper PRE 2009. There is one typo in it, namely Eq. (24) represents the face flux rather than velocity at the cell-face. Sorry for this, it went also unnoticed by the reviewers.

Edin.

[santiagomarquezd]

Edin,

Originally Posted by eberberovic

Hi.

Sorry for not answering, I was far too busy in the previous months.

Regarding the sub-cycling in gammaEqn, I have no references on that, but it indeed does what you are writing, i.e. the gamma field is being updates in every sub-cycle time step (in MULES, explicitly or implicitly) and the total face-flux is accumulated for the momentum equation.

There are also no references on MULES, but it is basically an additional limiter, which is used to clip or cut off the superfluous fluxes. The face-flux calculated using any limited scheme is represented as a sum of the upwind-flux and the corresponding flux correction. Then the limiter lambda is calculated, according to the worst (limiting) cases of gamma being equal to the maximum/minimum from the cells surrounding the cell of interest. Its value is between 1 and 0, which means that the flux corrections are either left unchanged, or the superfluous flux corrections are partially clipped, or the flux corrections are completely cut off reducing the scheme to upwind.

Hope this helps,
Edin.

thanks for your answer, I've been working in this solver for the last two months, lately Nisi is working with me too. We've found that MULES::limiter is based on Flux-Corrected Transport ideas, particularly this version is quite similar to the job of Zalesak (http://rsmas.miami.edu/personal/misk...FCT-JCPv31.pdf). In Zalesak job, lambdas are calculated once, in MULES::limiter this work is done iteratively. We've arrived to similar conclussions as yours, thanks for this confirmation.

Best.