CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Running, Solving & CFD (
-   -   interTrackFoam and axisymmetric computations (

diego_angeli January 10, 2013 10:59

interTrackFoam and axisymmetric computations
Dear all,

I am experiencing problems in setting up an axisymmetric case with interTrackFoam. It is not very clear how the "centerline" patch he is searching for should be defined, since the makeFaMesh ignores the axis when it is composed by 0 faces.

I know that the solver is used/developed by few and maybe I am the first trying to do an axisymmetric calculation with interTrackFoam, but if anyone has a clue about it, that could be very welcome.



deepsterblue January 10, 2013 11:40

This is a little tricky - the center line can't be completely degenerate (i.e. just an edge using makeAxialMesh and 0 faces). This is mainly a limitation of the mesh motion solver.

The workaround is to have the center line that is offset from the axis, with very small faces. This works quite well. The trouble is that you'll have to manually make this mesh in a generator, so makeAxialMesh can't help you there.

diego_angeli January 14, 2013 08:00

Dear Sandeep,

thank you for your reply! hope all is fine at UMass!

I tried as you suggested and actually it worked. Unfortunately, though, it appears that the free surface displacement along surface normals does not work well with wedge conditions, and my case is a sort of free-falling jet with a very steep slope, so I would rather need such a feature.
The analogous 3D 180 case is currently working better (albeit enormously slower...)



diego_angeli January 30, 2013 14:04

Some more updates, just in case anyone is interested or has any clue about possible pitfalls:


Originally Posted by diego_angeli (Post 401717)
The analogous 3D 180 case is currently working better (albeit enormously slower...)

..and still very slow it is, so in the meantime I dug out to look for alternative solutions


Originally Posted by diego_angeli (Post 401717)
it appears that the free surface displacement along surface normals does not work well with 2D wedge conditions

I was not very specific about this and I apologize for this, but what I meant is that, if I activate the normalMotionDir switch, the faMesh solver seems not to recognize the wedge condition itself, but instead moves the free surface points out of the plane of the wedge boundaries. I also forced Uz (my neutral direction in the x-y plane) to zero everywhere, but this does not change much.

I also tried to create a (less cumbersome) 3D 90 sector with symmetryPlane conditions. To do this, I used extrudeMesh from the original x-y face. Hence, there are triangular faces on the free surface, connected to the "axis" line, i.e. intersection of the two symmetry planes.
The calculation starts fine and meaningfully, but then it crashes, due to the fact that the the height of the triangular cells adjacent to the free surface collapses to zero at some point. This could be due either to an uneven point redistribution along the "axis", or to a wrong displacement of the common vertex of the triangular cells.

I am aware that this is very specific stuff, but it's always better to ask than to remain silent... ;)

ebaldwin June 11, 2015 16:44

1 Attachment(s)

Did you every find a way to get your axisymmetric case to work properly? I am trying to model the osculations in a levitating liquid droplet. I made my centerline consist of small faces as Sandeep suggested, and am seeing behavior similar to what you are describing; the mesh does not stay smooth near the interface, especially near the centerline and on the regions of the droplet that are deforming the most. Any help would be greatly appreciated!


diego_angeli June 12, 2015 04:11

Dear Eli,

unfortunately I continued with 3D meshes and that's where I made the most progress.

From your image it seems that the main problem is the collapse of cells adjacent to the free surface at the axis.
Are you using normalMotionDir? Do you experience also a displacement of vertices normal to the wedge faces?



diego_angeli June 12, 2015 04:16

sorry, double post

ebaldwin June 12, 2015 08:59


The collapse of the cells adjacent to the freeSurface at the axis is a problem, but the other cells adjacent to the freeSurface also have trouble. If you look closely at my attached image you will see that the volume of the low pressure cells has collapsed down to zero. This cells ends up getting a negative volume, and in this particular run that is the source of the crash.

I was experiencing the same problem of displacement in the direction normal to the wedge. Switching the BC to symmetry plane fixed this problem for me. I'm not sure what normalMotionDir does, but I have tried running with and without it and seen little influence on the result.

I will revolve the case and try running in 3D. Were you able to successfully run this solver in parallel?


All times are GMT -4. The time now is 11:10.