custom_mg prolongation builders should use the coarse DMPlex + native point location, not scipy Delaunay over the DOF cloud

[lmoresi]

Problem

The custom-FMG transfer builders (src/underworld3/utilities/custom_mg.py, PR #290) receive bare coordinate arrays and rebuild coarse-grid connectivity from scratch:

• barycentric_prolongation re-triangulates the coarse DOF cloud with scipy.spatial.Delaunay, then runs a per-fine-DOF Python loop for simplex location and weights.
• rbf_prolongation assembles a dense coarse–coarse kernel matrix and does an O(n³) dense solve — fine for small clouds, infeasible at 3D velocity-block sizes.

This is redundant and, on curved domains, wrong-shaped: each coarse level is already a simplicial DMPlex — the triangulation exists, with UW3's optimised kd-tree cell location built on top, and FE basis evaluation available. On a 3D spherical shell the scipy Delaunay additionally fills the convex hull, so the shell cavity acquires phantom simplices and near-surface fine points fall out of the hull into nearest-neighbour fallbacks.

Measured impact

Rotated free-slip + custom FMG on the Zhong (#248) spherical shell, non-nested coarse pair (cellSize 0.19 → 0.125, ~11.5k fine cells): the solve converges in 5 outer iterations (post #306), but the prolongation build takes ~5.9 hours. The same problem with the GAMG velocity block completes in ~53 s end-to-end; a debug-size sphere (0.3/0.45) builds in ~2 min. The build, not the solve, is the bottleneck — and it is all scipy Delaunay + Python-loop location.

Proposed fix

Build P from the coarse mesh rather than the coarse point cloud:

1. Locate fine-level DOF coordinates in coarse cells via the existing optimised point-location path (kd-tree cell hints + DMPlex location — the same machinery uw.function.evaluate uses).
2. Evaluate the coarse element's actual FE basis at each located point for the row weights — giving FE-exact transfers (including P2-exact for the velocity block, vs the current P1-over-an-artificial-triangulation).
3. Keep a nearest-DOF fallback only for genuinely exterior points (curved-boundary chord gaps), which becomes rare once location uses the true mesh.

This removes the scipy Delaunay entirely, fixes the shell-cavity topology problem, vectorises the build, and should also simplify the parallel story (location is partition-aware; the current builders are serial-only by construction).

Low priority: non-nested 3D FMG is a rarely travelled path (nested refine() hierarchies and the GAMG fallback cover current use), but the barycentric builder as written will bite anyone who tries a 3D non-nested pair at production resolution.

Context: #248, #290, #306 (~/+Simulations/rotated_schur_pc_study/ holds the timing logs).

Underworld development team with AI support from Claude Code

[lmoresi]

Addendum (L.M.): the RBF builder should be rebuilt on the same mechanism — the only difference from the barycentric path is the support selection. Both builders become:

1. For each fine DOF, query the coarse level's native kd-tree (the same optimised location machinery as above);
2. take the support set —
   • barycentric: the exact containing coarse element (DMPlex location), weights = the element's FE basis at the point;
   • rbf: the local k-nearest node cloud, weights = a small local RBF fit (polyharmonic + affine tail, Shepard-normalised — the kernel already in rbf_prolongation, just solved per-point on ~10-30 nodes instead of one dense global O(n³) system);
3. assemble the sparse row.

Same efficiencies (and the same remaining inefficiencies) roll through both: one kd-tree query per fine DOF, small local solves, no scipy Delaunay, no dense global matrix, and the parallel story is shared since the location step is partition-aware. The RBF variant stays useful as the smoother/forgiving option where exact containment is awkward (chord gaps on curved boundaries, slivers), and becomes viable at 3D velocity-block sizes for the first time.

A neat self-contained fix: both builders reduce to one shared locate-and-weight loop with a pluggable weight rule.

Underworld development team with AI support from Claude Code