Self-intersections after meshing on clean geometry - HyperMesh CFD 2026, pylon and V-tail stitched j

Pavitra

Setup: HyperMesh CFD 2026.0.0.27 (AcuSolve), MKS units. External aircraft geometry - fuselage, wing, two pylons, V-tail. Around 132 surfaces.

What happened:

What I'm trying to do

Clean up an imported aircraft surface geometry and generate a surface mesh for an external CFD run.

Steps taken so far

1. Imported the geometry and ran the SurfaceChecks / Validate tool.
2. Initial result: Free edges (4), located at the pylon-to-wing junctions and the V-tail root.
3. Tried Stitch All with the default tolerance of 0.0001 m. Nothing happened, free edge count stayed at 4.
4. Increased stitch tolerance progressively, up to 1 m. Stitch All still did nothing. Status bar showed locks=e222, s0, b375/44, if that is relevant.
5. Tried the patch / fill hole option instead. This removed the free edges but produced Closed shells (4), meaning the pylons and V-tail became sealed as four separate closed bodies rather than merging into the main aircraft skin.
6. Reverted that, and instead stitched each of the 4 edges individually, selecting the edge pairs manually rather than using Stitch All. This worked. Geometry then validated clean: Free edges (0), Non-manifold edges (0), Self intersections (0), Slivers (0).
7. Ran the surface mesh.
8. Re-validated after meshing. Now showing Self intersections (7) at various locations.

My questions

1. Why does Stitch All silently fail while individual stitching works? Even at a 1 m tolerance, Stitch All produced no change on those 4 edges, but manually pairing the same edges stitched them fine. Is Stitch All scoped per-part (my geometry is split into several sub-parts under one part), or is it skipping edges it cannot auto-pair by proximity or length? Are locked edges excluded from Stitch All but not from manual stitch?
2. Why does patch / fill hole create separate closed shells instead of merging into the parent shell? Is this expected behaviour, meaning fill-hole is always self-bounded and never merged with the adjacent surface network, or is there a setting to have it stitch into the surrounding topology?
3. Main question - why do self-intersections appear only after meshing, when the geometry validated clean beforehand?
   • Is the post-mesh check reporting geometry self-intersections (NURBS surfaces overlapping) or discrete mesh self-intersections (crossed elements)? The count appears in the same SurfaceChecks panel, which is why I am unsure which level it is flagging.
   • If it is mesh level, is this a case of the global element size being too coarse for the local curvature at the stitched pylon and V-tail junctions, causing elements to fold?
   • If it is geometry level, can the meshing operation itself modify or heal the underlying geometry in a way that introduces overlaps that were not there before?
4. Recommended fix workflow: should I be applying local mesh size controls or size boxes at the stitched junctions before remeshing, or is the correct approach to go back and improve the surface quality at those joints first, for example re-trimming the pylon root into the wing rather than stitching edge to edge?
5. Best practice question: for an intersecting-body case like pylons and a V-tail meeting a wing or fuselage, is edge stitching even the right approach? Would a Boolean or trim operation at the intersection produce a more robust, mesh-friendly topology than stitching coincident edges?

TLDR: HyperMesh CFD 2026, aircraft external geometry. Had 4 free edges at the pylon and V-tail junctions. Stitch All did nothing even at 1 m tolerance, fill hole just sealed them into 4 separate closed shells, but stitching each edge pair manually worked and the geometry validated 100% clean. Then I meshed it, re-validated, and now I have 7 self-intersections. Why do they show up only after meshing when the geometry was clean, and is the fix local mesh refinement at those junctions or better surface topology there?

Thanks!