🚨 Orphan cells in ANSYS Fluent Overset Mesh?

 Your simulation works perfectly at initialization… then suddenly fluid starts leaking through the solid when the mesh moves. 😱

Is the solution to kill the orphan cells? ❌
Or is the real problem donor search, hole cutting, insufficient overlap, or multiple overset connectivity? 🧩

I break down what’s really happening — and what to test first.

#ANSYSFluent #CFD #OversetMesh #DynamicMesh #FSI #Simulation #CAE #Engineering

This is a classic overset-connectivity problem, and the fact that it appears only at certain transient positions is a very important clue.

The key point is: I would not try to convert the orphan cells into dead cells manually. In Fluent, orphan and dead have fundamentally different meanings. Dead cells are intentionally excluded from the solution because they are inside a body/outside the flow region or redundant overlap cells. An orphan is a receptor cell that failed to find a valid donor. (Ansys Help)

What is probably happening

Your situation sounds like:

initial position → valid connectivity → mesh moves → local overlap becomes insufficient → donor search fails → orphan cells → possible leakage

Fluent specifically identifies insufficient overlap and/or mismatched mesh resolution as common causes of orphan cells. (Ansys Help)

And there's an especially interesting detail in your description:

the orphan cells seem to be situated in the solid that is surrounded by the overset mesh

That makes me suspect the hole-cutting/connectivity topology is changing incorrectly during the motion, rather than simply having a few random bad donor cells.

---

🔴 Don't solve it by "killing" the orphan cells

Fluent already has an orphan-cell treatment. If orphan cells remain, Fluent can apply a numerical treatment to them, but Ansys explicitly warns that this does not guarantee solution quality or robustness and recommends eliminating the orphans where possible. (Ansys Help)

So I would not implement a UDF that simply deactivates those cells.

More importantly, if the cells are actually supposed to be inside your solid, the correct operation is:

hole cutting → DEAD

not:

failed donor search → ORPHAN → DEAD

Those are different mechanisms.

---

🟢 What I would try first

1. Visualize the orphan cells at the exact bad timestep

This is critical.

Fluent has a specific command:

define/overset-interfaces/mark-cells orphan no

This creates the register:

overset-orphan-cells-r0

which you can display. (Ansys Help)

Don't just look at the number of orphans.

Look at their geometrical relationship to:

• overset wall

• background mesh

• neighboring component mesh

• solid boundary

• other overset interfaces

If the orphan cells form a thin layer along the solid surface, that's a huge clue.

---

🔥 2. Check whether you actually have enough overlap during motion

This is probably the first thing I'd investigate.

An overset interface requires sufficient donor/receptor overlap.

Ansys currently recommends approximately 4 cells across gaps for overset configurations because inadequate gap resolution can generate orphan cells. (Ansys Help)

With moving meshes, you have an additional problem:

The mesh that works at t = 0 doesn't necessarily work at t = 2 s.

For example:

             t = 0

Background
──────────────────────────────

       ┌──────────────┐
       │ OVERS ET     │
       │              │
       └──────────────┘


             ↓ motion


             t = Δt

Background
──────────────────────────────

             ┌──────────────┐
             │ OVERS ET     │
             │              │
             └──────────────┘
                  ↑
            donor coverage
            may now be poor

Your initial static test therefore doesn't prove that the overset topology remains valid throughout the trajectory.

---

🟠 3. Your "solid surrounded by overset mesh" is particularly suspicious

Suppose you have:

        Overset mesh

    ┌───────────────────┐
    │                   │
    │    ┌─────────┐    │
    │    │ SOLID   │    │
    │    │         │    │
    │    └─────────┘    │
    │                   │
    └───────────────────┘

The cells inside the solid should normally be removed through hole cutting.

Fluent's hole-cutting process explicitly marks cells inside bodies/outside the computational flow as dead cells and then flood-fills the region. (Ansys Help)

If the moving geometry causes the hole-cutting topology to become marginal, you can potentially end up with cells that are no longer correctly classified.

That is why I'd investigate hole cutting before touching the solver settings.

---

🟡 4. Test debug-hole-cut

This is one of the most useful things for your particular problem.

Fluent provides:

define/overset-interfaces/debug-hole-cut

for diagnosing hole-cutting problems. (Ansys Help)

Run the case at the problematic position and inspect what Fluent considers:

• dead

• solve

• receptor

• donor

If you discover that the cells inside the solid are classified as receptor/orphan instead of dead, you've found the real problem.

---

🟣 5. Try automatic overset adaption

This is actually designed for moving overset meshes.

Fluent can automatically adapt the mesh after the mesh motion and try to eliminate orphan cells. Ansys specifically recommends automatic overset adaption for moving/dynamic mesh cases where the mesh requirements change during the simulation. (Ansys Help)

The TUI command is:

define/overset-interfaces/adapt/set/automatic?

and manual adaptation can be invoked through:

define/overset-interfaces/adapt/adapt-mesh

(Ansys Help)

This is worth testing before doing anything exotic with a UDF.

---

🔵 6. Don't assume grid priority will fix this

You've already tried grid priorities, and that's reasonable.

But grid priority primarily controls which overlapping mesh is preferred during overlap minimization. It does not magically create a donor where there isn't sufficient geometric overlap.

Fluent allows donor priority to be based on either:

• cell volume

• distance to the nearest boundary

and grid priorities can influence which overset mesh is favored. (Ansys Help)

So I'd think of it like this:

Grid priority = choose the better donor region

whereas

mesh overlap = actually provide a donor

If the latter fails, changing priority often won't solve the underlying problem.

---

🔥 One thing I'd test very carefully

You mentioned:

multiple overlapping (but not intersecting!) overset meshes

This is important.

Imagine:

           OV-1
       ┌───────────┐
       │           │
       │     ┌────────────┐
       │     │    OV-2    │
       └─────│            │
             └────────────┘

Now add a third overset mesh.

You can get situations where:

OV1 → OV2 → OV3

connectivity changes as the bodies move.

At one timestep:

OV1 → donor → OV2

At another:

OV1 → donor → OV3

And at a marginal location:

OV1 → receptor
       ❌ no valid donor

That's why I would examine the overset connectivity at the exact timestep where the leak starts, rather than only at initialization.

---

🧪 A very useful diagnostic experiment

I would run four cases:

Test	Motion	Overset meshes	Purpose
A	Static	All	Baseline
B	Dynamic	All	Your current problem
C	Dynamic	Only problematic overset mesh	Identify interaction
D	Dynamic	All + finer overlap mesh	Determine whether resolution is cause

If C works but B fails, you almost certainly have a multi-overset connectivity interaction.

If D eliminates the orphans, you've identified an overlap/resolution problem.

If D doesn't help, I'd focus much more heavily on hole cutting and geometry topology during motion.

---

⚠️ And I would NOT use solve-island-removal as the primary fix

That function addresses disconnected fluid regions/islands. Your description sounds more like a donor-search/hole-cutting problem.

Fluent's documentation explicitly separates:

hole cutting problems

from

donor search failures due to orphan cells. (Ansys Help)

So the fact that solve-island-removal didn't fix it doesn't surprise me.

---

My suspicion ranking

Based on what you've described, I'd investigate in this order:

1. 🥇 Insufficient overlap at a particular position

2. 🥈 Hole-cutting failure around the solid during motion

3. 🥉 Interaction between multiple overset meshes

4. Mesh-size mismatch between donor and receptor

5. Grid-priority/donor-priority selection

And only after those would I consider trying to manipulate orphan cells through a UDF.

The most important thing is that the orphan cells are probably a symptom, not the actual problem. Turning them into dead cells could hide the symptom while allowing the underlying overset topology to remain wrong.

If you can upload one screenshot of the mesh at the bad timestep showing the solid + overset meshes + the orphan cells, I can help you identify whether this looks like a hole-cutting problem, insufficient overlap, or donor-priority problem.