tri2quad + smoothing: do output edge lengths diverge from underlying size function?

[domattioli]

Question

Downstream consumers (MADMESHR, ADMESH) drive mesh generation off a continuous size function h(x, y): every input triangle is sized so its edge lengths approximate h at the local centroid. After tri_to_quad, and especially after a post-processing smoothing pass (angle_based_smoother or direct_smoother — src/chilmesh/CHILmesh.py:1505-2000), the vertex positions move and the new quad edge lengths may no longer reflect h.

Does the tri2quad + smooth pipeline measurably degrade the agreement between mesh edge lengths and the underlying size function?

Why this matters

• Size functions are the contract between the meshing toolchain and the application: they encode bathymetry-driven refinement, feature-distance refinement, CFL limits, etc.
• If quads come out with edges 1.5× or 0.5× of the local h, the downstream solver inherits a mesh that violates the design intent. Convergence, CFL stability, and feature resolution all suffer silently.
• Smoothing is the obvious culprit (vertices move toward angle-quality optima, not toward size-function targets), but the merge step itself can also distort: merging two tris with different local h produces a quad with one diagonal that bridges two size regimes.

Proposed investigation

1. Pick a fixture with a known/recoverable size function. Candidates:
   • Synthetic: annulus, donut, structured — uniform h by construction.
   • Real-world: Delaware Bay (refined-100-20000-v1), LakeErie/refined, WNAT variants — h recoverable from input edge-length distribution.
2. For input mesh, compute per-edge length distribution and a local h(x, y) field (centroid edge-length average over a small neighborhood, or read from ADMESH if available).
3. Run tri_to_quad → measure quad edge-length distribution. Compare per-region against h.
4. Run smooth_mesh(method='direct'|'angle_based') → re-measure. Compare delta vs (3).
5. Report:
   • Ratio histogram |edge| / h_local for input tris vs output quads (pre-smooth and post-smooth).
   • Worst-case per-region drift (e.g., 95th-percentile ratio in each skeleton layer).
   • Whether smoothing helps or hurts the ratio.

Acceptance / outcome

Either:

• (a) Confirm the pipeline is benign: |edge|/h distributions stay within an acceptable tolerance (e.g., [0.5, 2.0] at p95) after tri2quad + smooth. Document the bound.
• (b) Identify a measurable drift. File follow-ups to:
  • Cap smoother displacement against the local h (constrain each vertex move by α·h_local).
  • Bias the tri2quad merge selection to prefer pairs of tris with similar local h.
  • Expose a "size-aware" smoothing mode.

Context

• tri2quad just had a 11.5% area-loss bug fixed on annulus (commit b383dd1, PR spec(007): mesh element validity test suite CHILmesh#141). The fix exposed the next-layer question: now that the mesh is geometrically faithful by area, is it faithful by size?
• Test coverage added in 9794078 for Delaware Bay validates topology only — does not measure edge-length vs size function.

Related: domattioli/CHILmesh#51-#54 (Phase 4 release), domattioli/CHILmesh#74 (skeletonization parity), spec 007 (mesh element validity).

[domattioli]

absolutely zero tri2quading in chilmesh. it is exclusively out of scope for this repo and belongs in the QuADMESH repo

[domattioli]

how can we quantify this while controlling for meshes with a large number of elements drowning out the signal