Skip to content

Add includeZipper option to mphys_get_triangulated_surface - #406

Open
JavierAlbaM wants to merge 1 commit into
mdolab:mainfrom
JavierAlbaM:mphys-trisurf-includezipper
Open

Add includeZipper option to mphys_get_triangulated_surface#406
JavierAlbaM wants to merge 1 commit into
mdolab:mainfrom
JavierAlbaM:mphys-trisurf-includezipper

Conversation

@JavierAlbaM

Copy link
Copy Markdown

Purpose

I started having issues with the thickness constraint projection with a geometry that was working before when running on a specific number of processors, but not with others (for example, the code worked for 24 cores but not for 20). I saw that the triangulated mesh surface returned by ADFlow when using for example 20 cores had a big gap that caused the constraint projection to fail there.

The mphys triangulated-surface helper always returned the zippered wall surface (includeZipper=True). For overset meshes that surface depends on the overset hole-cut/zipper, which is partition-dependent: at some MPI rank counts wall faces near overset overlaps are blanked and not recovered for a single-family request, leaving holes in the gathered surface.

When the surface is used as a geometry reference (e.g. DVConstraints thickness/volume constraint projections) this caused projection failures that appeared or disappeared depending only on the processor count.

Expose includeZipper (default True, so no behaviour change) on mphys_get_triangulated_surface / _getTriangulatedMeshSurface and the ADflowMeshGroup pass-through, forwarding it to both getSurfaceCoordinates and getSurfaceConnectivity so callers can request the raw, processor-count independent wall surface with includeZipper=False.

Expected time until merged

Not urgent, 2 weeks

Type of change

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (non-backwards-compatible fix or feature)
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes, no API changes)
  • Documentation update
  • Maintenance update
  • Other (please describe)

Testing

Checklist

  • I have run ruff check and ruff format to make sure the Python code adheres to PEP-8 and is consistently formatted
  • I have formatted the Fortran code with fprettify or C/C++ code with clang-format as applicable
  • I have run unit and regression tests which pass locally with my changes
  • I have added new tests that prove my fix is effective or that my feature works
  • I have added necessary documentation

The mphys triangulated-surface helper always returned the zippered wall
surface (includeZipper=True). For overset meshes that surface depends on
the overset hole-cut/zipper, which is partition-dependent: at some MPI
rank counts wall faces near overset overlaps are blanked and not recovered
for a single-family request, leaving holes in the gathered surface.

When the surface is used as a geometry reference (e.g. DVConstraints
thickness/volume constraint projections) this caused projection failures
that appeared or disappeared depending only on the processor count.

Expose includeZipper (default True, so no behaviour change) on
mphys_get_triangulated_surface / _getTriangulatedMeshSurface and the
ADflowMeshGroup pass-through, forwarding it to both getSurfaceCoordinates
and getSurfaceConnectivity so callers can request the raw, processor-count
independent wall surface with includeZipper=False.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@JavierAlbaM
JavierAlbaM requested a review from a team as a code owner June 23, 2026 19:09
@JavierAlbaM
JavierAlbaM requested review from A-CGray, ArshSaja, anilyil and sanjan98 and removed request for ArshSaja and anilyil June 23, 2026 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants