[darai]

Hello Foamers,

I am trying to explore the performance of the new multiphaseEulerFoam (OF 2.1.0), but in the beginning I found a mystery behaviour in the basic damBreak4phase tutorial case.

The problem is in time 5.75s, until that time the flow is stable, the column colapses and the mixture is trying to stabilize (loose kinetic energy) and separate by density.
(T = 0.00s, T = 0.15s, T = 5.70s)


But in time 5.75s the nearly stabilized mixture vanishes into thin air.


I don't suppose that I am the only one who knows this problem. I faced it from time to time in the last year when I was exploring the bubbleFoam and interFoam but I never found an example this ilustrative to solve.

So does somebody know what is wrong in such case? What can I try to correct?

Thanks in advance, for any hint.
Martin.

[darai]

Hello,

First attempt to break this problem was through the nOuterCorrectors PIMPLE parameter. I know that this parameter controls the pimple.loop() cycle and I found a notice that it is used to control the number of iterations of the Reynolds-Averaged, Navier-Stokes equations. (I guess that for my laminar case we talk only about N-S equations, but the meaning is similar)

So I tried a second calculation, where I used nOuterCorrectors 5 and I compared the results. The dissipation is gone now, but... The behaviour is now chaotic. It behaves like a boiling pot, not loosing the kinetic energy and it "breakes (first acceleration of the water column)" much faster than with nOuterCorrectors 1:

(T = 0.00s)

(T = 0.05s)

(T = 0.10s)


So these results gives more questions than answers. Why is pimple behaving this way? Is it because the nOuterCorrectors parameter isn't created for transient applications, only steady state?

Thanks in advance for all the help,
Martin.

[danvica]

Unfortunately I don't have any clue about this problem. I reply because, beeing a newbie in CFD, this kind of thing worry me.

In general, is it possible for a not-expert use OpenFoam to get trustable results ?

Mine is not a critic to the package, I think it's an impressive work still improving. Just a clear question.

I understand that CFD field requires deep understanding in what's behind the tool your using (probably more than any computer-aided-field)... but sometimes our job force us to be less academic.

I hope someone could solve your problem, sorry for the OT.

Daniele

[darai]

Hello Danielle,

There are several indices that the solution you have is not close enough to the reality. First is, when the error is getting close to 1, the error estimates (in log, maximum of final error estimate for each field, for each time step)

Another is phase fraction, when you calculates multiphase problem. The phase fraction should be between 0 and 1. All above and below means stability problem and possible error.

The main problem is to understand that CFD is for verification, it has error which is calculable... without real experiment verification, it simply isn't possible to use any results.

When the calculation is problematic, you can decompose the problem and try to run simpler calculations to isolate it and deal with it. When you don't know, what next, google, read wiki, read the forum here and believe in the start, there are only few problems, nobody solved and posted before you.

And of course post your problems and tested solutions (succesfull or not) and sooner or later, you will get the answer.

Martin.

[kwardle]

Martin,
You should probably try the most recent version of multiphaseEulerFoam in the 2.1.x git repo. This solver was still 'in development' at the time of the 2.1.0 release and some important changes have been made subsequently which are reflected in the most recent version in the repo. I would be very curious to hear if you see the same problems in the updated solver.
-Kent

[darai]

Thanks Kent for your post,
We tried newer version and the solution is much better. It still isn't perfect, but well... better is better.
So thanks again,
- Martin

[kwardle]

FYI, there have been more updates to multiphaseEulerFoam which are currently in 2.1.x. The phase conservation should be much improved. Also there was an issue with virtual mass which seems to have been solved.

[petr.f.]

Hi all,

I've taken over Martins work and I'm doing more experiments with multiphaseEulerFoam. The damBreak4Phase_fine works with the default settings (i.e. first order Euler in time, endTime 6 sec). However, as we've previously ran into the problems in nearly stabilised state, I've tried to carry out the computation til 20 sec (with 2nd order backward in time) and discovered a problem totaly opposite to the one mentioned in Martin's first post. The mass is not vanishing any more, but there seems to be some strange "rain" boundary condition on the top boundary of the tank. See the attached figures - the effect begins to appear around the 8th second of the computation and by the 19th second the tank is almost full... Any idea what could be wrong?

Petr.

[kwardle]

Petr,
Yes, very strange indeed, but I have seen this before. Are you using the standard BC setup in the damBreak tutorial? As I recall, I only saw this when I had been simulating a closed domain and had mistakenly set the phase velocities U* as zeroGradient on one of the walls rather than slip. Assuming you are not doing that, but are using the standard 'atmosphere' top boundary, then I think this can be helped by adding the 'phi' argument to the inletOutlet types for each of the alphas, e.g. add 'phi phiwater;' to alphawater, and so on for the other phases. Give this a try and let me know if it helps.
Regards,
Kent

[petr.f.]

Thanks for the reply. I will try your recomendations and let you know. However, the puzzling thing is that this behaviour appears only when using the 2nd order implicit backward scheme for time derivatives (this was the only change I made to the original files). With 1st order explicit Euler everything works perfectly.

[vonboett]

Originally Posted by petr.f.

Thanks for the reply. I will try your recomendations and let you know. However, the puzzling thing is that this behaviour appears only when using the 2nd order implicit backward scheme for time derivatives (this was the only change I made to the original files). With 1st order explicit Euler everything works perfectly.

I know this question is old here but people always run again in this problem. it is caused by the zeroGradient boundary condition for the phase fractions, typically atmosphere. That is, when a drop of your fluid splashes up to the say atmospheric boundary condition, and instead of leaving the domain completeley part of it may fall back, it has changed the alpha value at the atmospheric boundary condition where it contacted it from say air to water and it will pour in a stripe of rain as a consequence. I solved this by switching to inletOutlet in alphaair, alphaoil etc. But then you may get a pressure instability when you have a position where your denser phase touches the atmospheric boundary condition permanenteley. However, for single splashes and drops its OK.