EMBED and assertion of the fm[] metric, potential bug?

[Youssef Saadeh]

Dear all,

I have noticed that some of the simulations break due failure to assert the metric fm[], a condition required with embedded boundaries in timestep.h. I've also noticed that the error is only present when using AMR. So if I comment out the assertion condition and perform a foreach loop to check, there is usually only one cell with cm[] = 0 (inside fluid domain), which should not be the case of course. So I suspect this has something to do with the refinement of either cs[], fs[], cm[] or fm[].

I wanted to ask if somebody has an idea as to why this might happen, and things to look for. I believe Stéphane put this condition in timestep specifically because of this thing. I will try to produce a minimal example, but I wanted to understand a bit more so that I can do so.

Best,

Youssef

[Stephane Popinet]

Hi Youssef,

In timestep.h, the u field is weighted by fm (as indicated in the
comment at the top of the file). So if u.x is different from zero (line
7), then fm.x cannot be zero (line 10).

The inconsistency can be due, for example, to incorrectly defined volume
(cm) and face fraction (fm). But needs to be tracked down in your
specific example.

The fractions_cleanup() function, applied judiciously, may help.

Stephane

[Youssef Saadeh]

Hello Stéphane,

 

Thanks for the additional insight. I will look more into it and provide observations or a minimal code that reproduces such an inconsistency.

 

To understand a bit more, what is it specifically about EMBED that might cause this, because uf is weighted by fm regardless, and yet that condition is only there for embedded boundaries. I believe it’s something with the refinement of cs and fs. Do you have an idea that can help me narrow the search down and pinpoint the problem?

 

Best,

Youssef

--

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/8430e394-43c2-a2bb-8e97-336c1425c2c3%40basilisk.fr.

 

[jmlopez...@gmail.com]

Hi Youssef,

It is axi, Rigth?

[Youssef Saadeh]

Hi Pepe,

Indeed, it is now. Although I checked the refinement of cm and fm in axi.h, and all seems to be in order. I suspect the problem arises from the multiplication with cs and fs. But I’m not sure yet. Have you encountered the same problem?

Best,

Youssef

To view this discussion on the web visit https://groups.google.com/d/msgid/basilisk-fr/dd37ec5e-383d-4cfd-84ac-08566b187a33n%40googlegroups.com.

[josé López-Herrera]

Hi youssef,

I have not seen the bug you comment on my side. Do you change the cs field along the simulation or it is computed once in a init event?

Cheers

Pepe 

[Youssef Saadeh]

Hi Pepe,

No, it’s only computed once. I attach a minimal example of it. I was further testing contact (SP’s sandbox) on embedded boundaries, this time in an AXI framework and with VOF (I attach a modified vof.h to be included in two-phase.h). If you use a timestep.h like the one I attach, it’ll print the coordinates of this inconsistency, and will dump a file with cm[]. A screenshot shows that cm[] is indeed zero at places where it should not be!

I am doubting the restriction where we try to compute the values of cm and fm on all levels, or otherwise the refinement of these metrics!

I hope this helps.

Cheers,

Youssef

[Youssef Saadeh]

Forgot the minimal code!

<cm.png>

<vof.h>

<timestep.h>

[Amin Soltani]

Hi everyone.

I am working on a bubble rising simulation using axi.h with embedded walls. I know there can be issues when using axi.h and embed together, especially since adaptive mesh cannot be used. However, in my case, I am using a fixed mesh and not an adaptive one.

The problem I am facing is that my results seem incorrect. When I compare the results of my simulations with and without embed, they are very different. I have attached both versions of the code (with embed and without embed) and the result animations for both.

Could someone please suggest how I can fix this? Is it possible to use axi.h with embedded walls for bubble rising simulations?

Thank you very much for your time.

Best regards,
Amin

[jose.lopez...@gmail.com]

Hi Amin,

There is a bug in the metric factor within vof advection when bug is present. I reported once:

https://groups.google.com/g/basilisk-fr/c/bW58CoGdpgs/m/AxScRNDJAwAJ

The solution is very easy (I gave a patch to solve when I reported it) .  Also we add a simple example to the bug list.   I think it is maybe the source of your problem.

Cheers

[jmlopez...@gmail.com]

Hi Amin,

As I suspected fixing the metric factor in vof.h with solve your problem.

Cheers

[Amin Soltani]

Hi Pepe,

Thank you so much for your help, it worked using your patch.
I would really appreciate it.

Best regards,
Amin

[Stephane Popinet]

Hi Pepe and Amin,

I have just made a new release which includes the patch. Thanks Pepe for
fixing this!

Stephane

[jmlopez...@gmail.com]

happy to contribute, Stephane!

[Amin Soltani]

Hi everyone,

I have a quick question.

In my simulation, I want to update the cs field dynamically (along the simulation). However, when I try to do this, the simulation crashes and I get the following error:

".../timestep.h:10: Assertion `fm.x[]' failed."

I tried several approaches to resolve this. After looking into the source code in "navier-stokes/centered.h", I noticed that when using embedded boundaries, the fluid fractions and face fluxes need to be checked for inconsistencies using this check:
"
foreach_face()
  if (uf.x[] && !fs.x[])
    uf.x[] = 0.;
"

So, I added this check after calling "fractions_cleanup(cs, fs)" when updating cs during the simulation. Here's the snippet:
"
vertex scalar phi[];
foreach_vertex() {
  phi[] = HUGE;
  phi[] = /* defining my phi */;
}

fractions(phi, cs, fs);
fractions_cleanup(cs, fs);

foreach_face()
  if (uf.x[] && !fs.x[])
    uf.x[] = 0.;
"

With this addition, the simulation no longer crashes and seems to work. However, I noticed that sometimes it significantly reduces the time step, which makes me not sure if this is the right approach.

I would really appreciate any guidance or suggestions on the correct way to handle this issue. Has anyone encountered something similar, or is there a more stable way to update cs during a simulation?

Thanks in advance for your help!

Best regards,
Amin

[Theo Witkamp]

Hi Youssef, 

I encountered the same problem when using axi + embed + two-phase + contact angle on embed. I once "accidentally" commented out the surface tension f.sigma and saw that the code run without errors. 

I then tested you minimal example code and noticed the same. If f.sigma is set to 0, the code runs but as soon as f.sigma is not 0, I get the same assertion fm.x[] error. 

I am not sure however how f.sigma and fm.x are connected so if you have any idea, I would be happy to hear them.

Best,

Theo