Abnormal droplet during atomization simulation

[lixin shen]

Dear all，

I have simulated the atomization process of the rotating liquid film on the basis of the example "Atomisation of a pulsed liquid jet". 

However, when the initial axial velocity is high, some abnormal droplets are often generated. 

These droplets are moving at tremendous speeds, so they reach the edge of the calculation domain in a very short time, while the main part of atomization is still very small.

By the time these abnormal droplets reach the edge of the computing field (which I suspect is why), the computation slows to a crawl, essentially stopping.

The spray field before basic stagnation is calculated as shown in the figure below, and the abnormal droplets are shown in the red circle.

I have tried to remove small droplets by the following method,

http://basilisk.fr/sandbox/lopez/src/droplet_stat.h

http://basilisk.fr/src/tag.h

http://basilisk.fr/sandbox/aberny/bubble/drop_stat.h

This removes some small droplets, but over time these abnormal droplets will still form, making the calculations extremely slow.

Thanks!

[Wojciech Aniszewski]

Dear Lixin,
this is a very well known problem in two-phase numerical simulations, wherein there takes place a decoupling/inconsistency between the mass and momentum transfer. You can read more about the problem e.g. in (http://dx.doi.org/10.1016/j.compfluid.2017.04.023). The "solver slows to a crawl" situation is the proper behaviour, as Basilisk (based on the CFL condition) limits the timestep to such that corresponds to the droplet's gigantic velocity.

Basilisk includes techniques to limit that (conserving.h), but for a flow such as yours, there is a good chance you still may see these "comet" droplets. Even if that chance is way smaller than without conserving.h. In a perfect world, this problem will one day be completely eliminated when this and other codes include a wide range of mitigation techniques, while retaining the flow physics intact.

To get a quick fix, you can write flux removers with varying degree of realism. In other words, you can create an event which will search the entire grid for any occurences of non-physical velocities, and limit them. (It should be checking for momentum fluxes, but that's too sophisticated for a "quick" fix). So just use a foreach_dimension(), check the value of u.x[], and if it is higher than something sensible, limit it. For example, if you inject the liquid at 100m/s, there is a good chance that the cells with u.x=1000000 have some issues. "Brutally" modifying their u.x value is what I propose. This will not remove the comet droplet(s), but will fix the "slowing to a crawl" problem.


The reason why this is a "dirty trick" is that such a u.x modification has nothing to do with physics. I.e. the velocity that you would enforce through the limiter is a value "taken from the ceiling", and the resultant velocity field is not divergence-free, and so on. One can defend it, by saying that the comet itself is already a problem, as the "momentum pulse" that created it was nonphysical in the first place. And that is true as well.



Good luck
w

> --
> You received this message because you are subscribed to the Google Groups "basilisk-fr" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to basilisk-fr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/basilisk-fr/188455bc-ddbf-4541-be95-fa997c1b5082n%40googlegroups.com.



--
/^..^\
( (••) ) Wojciech (Wojtek) ANISZEWSKI
(|)_._(|)~
OrcId : https://orcid.org/0000-0002-4248-1194
Scholar: https://tinyurl.com/y28b8gfp
RG : https://www.researchgate.net/profile/Wojciech_Aniszewski
Twitter: @echo_dancers3
GPG ID : AC66485E

[lixin shen]

Dear Wojciech,

Thank you very much for your explanation of the slow computation speed and the solution you provided, which is very useful to me.

In fact, I tried a solution similar to the one you provided earlier and added in the code:

event cleasing (i++){

       foreach (){

         if (u.x[] > 20);

            f[] = 0;

                       }

                              }

It works.

But the strange thing is that in my initial setting, u.x=19.6,

 I think u.x gradually gets smaller during the subsequent atomization process, 

So I set u.x >20. I thought that such a threshold would satisfy the requirement of removing only the "comet" droplets, 

But in fact, my calculation results are shown in the figure.

There was a large amount of fluid missing from the calculation and I later had to change the threshold to u.x>30.

 The subsequent calculation results and the calculation speed look normal.

But in fact, there is no basis for the selection of threshold value of u.x, and I'm not sure if setting a large U.X threshold would have a bad effect on the simulation results.

And I am curious that u.x actually increases in the atomization process.

I was just wondering if there were any problems with my approach or are there any similar examples of how to deal with "comet" droplets.

Thanks again!

[Stephane Popinet]

Hi Lixin,

Are you using navier-stokes/conserving.h ?

Stephane

[Wojciech Aniszewski]

Dear Lixin,

1. Make sure you use conserving.h
2. Do NOT remove f[] here, just put u.x[] = something.
3. use foreach_dimension to make sure your u.x condition checks all component.
4. use a far higher value than 20 for "something", 20 is very restrictive.

best
w

> To view this discussion on the web visit https://groups.google.com/d/msgid/basilisk-fr/66abc968-0989-4392-9dcf-0b662d07893en%40googlegroups.com.

[lixin shen]

Dear Stephane,

I didn't use  "navier-stokes/conserving.h" before, and after I added it, no "comet" droplets were regenerated.

However, the simulated atomization process is very strange, with very few small droplets generated (as shown in Figure 1). 

On the contrary, the atomization process without "navier-stokes/conserving.h" looks more reasonable (as shown in Figure 2).

So from the simulation results, it's better not to use "navier-stokes/conserving.h".

best

w

[lixin shen]

Dear Wojciech,

I think I fully understand what you mean. 

Thank you very much for your help and suggestions, but the problem mentioned in reply Stephane still bothers me. 

What do you think about that?

best

w

[Stephane Popinet]

Hi Lixin,

> So from the simulation results, it's better not to use
> "navier-stokes/conserving.h".

Generally speaking, you are not "allowed" to just choose which results
you like best... navier-stokes/conserving.h is generally more consistent
than the non-conserving version. Apart from this consideration, the
difference between the results you get is probably due to a lack of
spatial resolution in both cases. To build confidence that your results
are correct, you need to study their convergence with spatial
resolution. See for example:

Cesar I Pairetti, Santiago Marquez Damian, Norberto M Nigro, Stéphane
Popinet, and Stéphane Zaleski. Mesh resolution effects on VOF
simulations of primary atomization. Atomization and Sprays,
30(12):913–935, 2020.

Bo Zhang, Stéphane Popinet, and Yue Ling. Modeling and Detailed
Numerical Simulation of the Primary Breakup of a Gasoline Surrogate Jet
under Non-Evaporative Operating Conditions. International Journal of
Multiphase Flow, 130:103362, May 2020.

cheers,

Stephane

[lixin shen]

Dear Stephane,

I understand what you mean.

 I will read these two papers carefully.

 Thank you for your help!

best 

w

[Stephane Zaleski]

Dear Lixi,

Could you please share your source code with us ?

Best

Stephane

[H LIU]

Hi Professor Stephane Zaleski, 

I have made a similar simulation and the following is my source code,  wish it will help. ^-^

Best

Hu LIU