adapt fem smooth and the iterative smoother to have optional inputs for optimizing for size function

[domattioli]

Problem

mesh is smoothed but at the expense of the originally computed admesh-truss-solved element sizes

Proposed solution

brainstorm how to create high quality elements that also respect the size function, and whether this just means you keep (or further iterate/improve on the admesh truss sovler) without running additional smoothing

Alternatives considered

No response

Priority

normal

[domattioli]

Where code stands on development: smooth_mesh(method='sdf', sdf=…, size_fn=…) (CHILmesh.py:1639/1656 → admesh_warmstart.optimize_with_admesh_truss) now ships the alternative floated in the body — iterate the ADMESH truss solve against the size function instead of running a size-blind smoother afterward. FEM (direct_smoother, :2015) and angle-based (:1728) remain size-blind — the Balendran stiffness targets uniform equilateral with zero size-field input, now documented in the docstring (:2034, per #168). Remaining scope = either add size-aware targets to those two smoothers, or ratify method='sdf' as the sanctioned size-respecting path and close this. Note: keyword passthrough from smooth_mesh to those two smoothers is currently broken (*kwargs single-star defect, filed separately in this triage) — any size-aware kwargs added to direct_smoother/angle_based_smoother also need that fix to be reachable from smooth_mesh.

[model: claude-fable-5, repo: CHILmesh, session: meshing-repos-issues-ry4hin]

---

Generated by Claude Code

[domattioli]

Research note — the size-blindness is method-specific; only the sdf truss path is size-aware today

Traced the current smooth_mesh dispatch (src/chilmesh/CHILmesh.py:1656) to pin down where the size function is lost. It is not "smoothing ignores size" globally — it is exactly two of the three methods.

• Current state (verified in source)

  ▸ method='sdf' — size-aware ✅

    ↪ `smooth_mesh` threads `size_fn` into `optimize_with_admesh_truss(self, sdf, size_fn=size_fn)` (`:1673`), which forwards it through `optimize_with_admesh_truss_arrays(..., sdf, size_fn, ...)` (`admesh_warmstart.py:509,618`) — the truss equilibrium length uses the element size field, so this path *is* the size-respecting smoother.
  

  ▸ method='fem' — size-blind ❌

    ↪ dispatches to `direct_smoother(**kwargs)` (`:1682`), whose signature is `(kinf, freeze_quad_nodes, solver, tol, maxiter)` — no size parameter, and `size_fn`/`sdf` are keyword-only on `smooth_mesh` so they are **not** in `**kwargs`; the FEM Laplacian relaxes every interior node toward its neighbor centroid regardless of target size.
  

  ▸ method='angle-based' — size-blind ❌

    ↪ dispatches to `angle_based_smoother(**kwargs)` (`:1683`), signature `(n_iter, omega, tol)`; it drives each sector angle toward the equiangular target `2π/m`, again with no size term.
  

• Why this is the OP's exact symptom

  ↪ the truss solver grades element size per the size field, then a subsequent method='fem' or 'angle-based' pass — both pure-geometry smoothers pulling toward equilateral/equiangular — actively erases that grading, which is precisely "mesh is smoothed but at the expense of the originally computed admesh-truss-solved element sizes."

• Design decision needed (the fork this issue should resolve)

  ▸ Option A — size-weighted geometry smoothers

    ↪ add an optional `size_fn` term to `direct_smoother`/`angle_based_smoother` so the FEM Laplacian target / angle relaxation is weighted by desired edge length (spring rest-length ∝ `size_fn`), keeping them usable but size-respecting.
  

  ▸ Option B — recommend the truss path, gate the geometry smoothers

    ↪ document that size-respecting smoothing = `method='sdf'` (the truss re-solve), and warn/skip the geometry smoothers when a size field must be preserved — no new numerics, just lifecycle guidance + a guard.
  

  ▸ Option C — truss-only iteration

    ↪ per the OP's alternative ("keep/further-iterate the truss solver without additional smoothing"), expose a "re-run truss N more iters" convenience and stop recommending a geometry-smoother finishing pass at all.
  

• Recommendation

  ↪ B first (cheap, immediate, un-blocks the lifecycle-benchmark story in Benchmarking should detail all steps of potential chilmesh lifecycle (not including the generation). #155 where FEM/angle stages currently degrade the truss result), with A tracked as the real feature if a size-respecting geometry smoother is genuinely wanted; C is a subset of the truss path already reachable via truss-iters.

Advance-only note — no label change proposed; the A/B/C fork is an operator/author call before implementation.

[model: claude-opus-4-8, repo: CHILmesh, session: 01JDVAmPYKnmykK6MnNKtyGs]

---

Generated by Claude Code