Tracer/VOF advection issue in axisymmetry
86 views
Skip to first unread message
Giannis Bagkeris
Oct 8, 2025, 8:32:02 AMOct 8
to basilisk-fr
Dear all,
I am working on capillary-driven flows in channels and pipes. When extending from channels to pipes using axi.h, I have noticed an unexpected behaviour: the interface becomes nearly pinned on the axis of symmetry.
After excluding potential culprits (basically contact-embed.h, which appears to work correctly with axi.h), I have narrowed the issue down to the advection of a VOF (or tracer) field when using axi.h.
To test advection in a similar but known flow, I have ran two minimal examples: channel flow and pipe flow with a flat initial tracer profile within the domain. The examples are pretty much based on http://basilisk.fr/src/examples/karman.c and http://basilisk.fr/sandbox/lopez/poiseuille-embed.c.
In both cases the (fully-developed) velocity matches the analytical solution. For the channel, the tracer is advected as expected, following the velocity profile. For the pipe, however, the tracer near the axis of symmetry moves much more slowly than the local velocity would suggest, even though the velocity itself is correct.
It seems the issue may be related to the face metric factors and how tracer fluxes are computed in axisymmetry, but I don't know how to fix it.
Please note that I got the same behaviour
Cheers,
Ioannis
ux for channel flow
ux for pipe flow
--------------------------------------------
Tracer evolution for channel flow
t=0
t=1
t=2
t=3
t=10
-------------------------------------------------------------------
Tracer evolution for pipe flow
t=0
t=1
t=2
t=3
t=10
I am working on capillary-driven flows in channels and pipes. When extending from channels to pipes using axi.h, I have noticed an unexpected behaviour: the interface becomes nearly pinned on the axis of symmetry.
After excluding potential culprits (basically contact-embed.h, which appears to work correctly with axi.h), I have narrowed the issue down to the advection of a VOF (or tracer) field when using axi.h.
To test advection in a similar but known flow, I have ran two minimal examples: channel flow and pipe flow with a flat initial tracer profile within the domain. The examples are pretty much based on http://basilisk.fr/src/examples/karman.c and http://basilisk.fr/sandbox/lopez/poiseuille-embed.c.
In both cases the (fully-developed) velocity matches the analytical solution. For the channel, the tracer is advected as expected, following the velocity profile. For the pipe, however, the tracer near the axis of symmetry moves much more slowly than the local velocity would suggest, even though the velocity itself is correct.
It seems the issue may be related to the face metric factors and how tracer fluxes are computed in axisymmetry, but I don't know how to fix it.
Please note that I got the same behaviour
- with VOF, no surface tension, and the two phases having the same density and viscosity
- without embed (in a square domain)
which suggest that the issue is purely related to axi.h and tracer/VOF advection. Has anyone encountered anything similar?
Cheers,
Ioannis
ux for channel flow
ux for pipe flow
--------------------------------------------
Tracer evolution for channel flow
t=0
t=1
t=2
t=3
t=10
-------------------------------------------------------------------
Tracer evolution for pipe flow
t=0
t=1
t=2
t=3
t=10
Giannis Bagkeris
Oct 18, 2025, 12:29:40 PMOct 18
to basilisk-fr
Update: Upon further investigation, tracer advection with axisymmetry works as expected in a default domain.
The issue in my previous test was that I had included the embed.h header even though no solid boundaries were defined in the script. After replacing embed.h with fractions.h, the simulation produced the expected result.
In summary, the issue persists only when embedded boundaries are used.
The issue in my previous test was that I had included the embed.h header even though no solid boundaries were defined in the script. After replacing embed.h with fractions.h, the simulation produced the expected result.
In summary, the issue persists only when embedded boundaries are used.
Reply all
Reply to author
Forward
0 new messages