Brainstorm: parallelization strategy for QuADMESH+

[domattioli]

Ask

Background brainstorm (no implementation expected yet): where can QuADMESH+ exploit parallelism, and what is the cleanest decomposition? Deliverable is a short options memo, not code.

Why now (low priority)

Pure correctness work (faithful tri2quad sweep, PR #37) takes precedence. File this so the parallelization design space is captured while it is fresh; pick up when the queue thins.

Seed questions

• Layer sweep is sequential by construction. faithful_sweep mutates the working Domain innermost→outward; edgeBisection splits iLayer-1 while still triangular, so layer k depends on layer k+1. Is that dependency fundamental, or only between adjacent layers (i.e. can non-adjacent layers run concurrently)?
• Independent connected components / submeshes. A disconnected (or weakly-coupled) domain could tri2quad each component in parallel. Worth a component-split front-end?
• Embarrassingly-parallel stages. Post-process smoothing (angle-based, FEM), elem_quality, per-element checks — which are already data-parallel and just need vectorization vs process/thread fan-out?
• Within-layer matching. The tri-pair matcher (_match_tris_to_quads) over one layer — graph matching; is a parallel/blocked matcher worth it, or is per-layer work too small?
• Batch axis. Many independent meshes (test fixtures, sweeps) → trivial multiprocessing at the driver level. Lowest-effort win?
• Tooling. numpy vectorization vs multiprocessing vs numba/Cython vs leaving it to chilmesh. GIL implications. Determinism (we already have a run-to-run nondeterminism bug — parallelism must not worsen it).

Out of scope

Not asking for an implementation or a benchmark harness here — just the decomposition options + a recommended first target with rough effort/payoff.

---

Labeling note: no canonical scope: label covers core package/algorithm code (canon scopes are infra-flavored: automation/ci/docs/git/plugin/skill/sync/testing). Tagged by type + request + priority only. Candidate follow-up for git-issue-label-manager canon (e.g. a scope: core / scope: algorithm).

[domattioli]

distributed computing ideas?

[domattioli]

also, even in a fully connected mesh a single layer may have orphaned/disconnected regions, especially the layers closer to Layer N. Could tackle those in parallel but would need to make sure the operations that pass remaining triangles to the next layer and or other things like retriangulations dont affect parallelized regions. could get messy figuring all that out

[domattioli]

Options memo delivered → docs/parallelization-strategy-memo.md (commit 8d3e2f1, on daily-maintenance / rolling PR #59). Grounded in the current src/quadmesh/ tree, file:line cited.

Answers to the seed questions:

• Layer sweep — serial by construction. sweep_layers re-derives all layers each pass and consumes the outermost triangular ring in place (_faithful_sweep.py:37-45). The current impl re-derives the whole domain every iteration, so there's no per-ring dependency graph to schedule against — non-adjacent concurrency is foreclosed without an algorithm-core rewrite.
• Within-layer matching — greedy, order-dependent path-walk (identify_edges.py, _match_faithful.py). Not a parallel target.
• Connected components — none in src/quadmesh; only layer rings. A component split would have to live upstream in chilmesh.
• Embarrassingly-parallel — only the measurement stages (compute_quality, validation predicates) are per-element/data-parallel → vectorize with numpy. The mutation stages (quad_vertex_merge, doublet_collapse, cleanup_boundary_quads) are greedy-sequential.
• Batch axis — run_pipeline() (pipeline.py:14) is a clean per-mesh entrypoint, no module state → trivially process-pooled across fixtures. Lowest-effort/highest-payoff.

Recommended first target: batch-level multiprocessing at the driver, gated on a determinism fix first.

Honesty flags:

• The "known nondeterminism bug" is real per this issue but not annotated anywhere in code — grep determin|fixme|todo|random|seed over src/quadmesh/ returns nothing. Candidate roots are the set() accumulators in _match_faithful.py:54,88 / identify_edges.py:140 / repair.py:71, but I did not confirm which one actually drives nondeterministic merge order. Needs a repro (same fixture × N runs → connectivity diff) before any parallel work.
• No multiprocessing/numba/cython/joblib in the tree today; numpy is used throughout, so vectorization is the natural lever.

Open questions for you (in the memo §"Open questions"): (1) green-light a determinism repro, (2) how common are multi-component inputs (decides the chilmesh request), (3) appetite for a numba/cython build dep later.

No implementation / no benchmark harness, per the issue's stated scope.

[model: other, repo: QuADMesh, session: 2026-05-29T20Z-daily-maintenance]

---

Generated by Claude Code

[domattioli]

Options memo delivered → docs/parallelization-strategy-memo.md (commit 8d3e2f1, on daily-maintenance / rolling PR #59). Grounded in the current src/quadmesh/ tree, file:line cited.

Answers to the seed questions:

• Layer sweep — serial by construction. sweep_layers re-derives all layers each pass and consumes the outermost triangular ring in place (_faithful_sweep.py:37-45). The current impl re-derives the whole domain every iteration, so there's no per-ring dependency graph to schedule against — non-adjacent concurrency is foreclosed without an algorithm-core rewrite.
• Within-layer matching — greedy, order-dependent path-walk (identify_edges.py, _match_faithful.py). Not a parallel target.
• Connected components — none in src/quadmesh; only layer rings. A component split would have to live upstream in chilmesh.
• Embarrassingly-parallel — only the measurement stages (compute_quality, validation predicates) are per-element/data-parallel → vectorize with numpy. The mutation stages (quad_vertex_merge, doublet_collapse, cleanup_boundary_quads) are greedy-sequential.
• Batch axis — run_pipeline() (pipeline.py:14) is a clean per-mesh entrypoint, no module state → trivially process-pooled across fixtures. Lowest-effort/highest-payoff.

Recommended first target: batch-level multiprocessing at the driver, gated on a determinism fix first.

Honesty flags:

• The "known nondeterminism bug" is real per this issue but not annotated anywhere in code — grep determin|fixme|todo|random|seed over src/quadmesh/ returns nothing. Candidate roots are the set() accumulators in _match_faithful.py:54,88 / identify_edges.py:140 / repair.py:71, but I did not confirm which one actually drives nondeterministic merge order. Needs a repro (same fixture × N runs → connectivity diff) before any parallel work.
• No multiprocessing/numba/cython/joblib in the tree today; numpy is used throughout, so vectorization is the natural lever.

Open questions for you (in the memo): (1) green-light a determinism repro, (2) how common are multi-component inputs (decides the chilmesh request), (3) appetite for a numba/cython build dep later.

No implementation / no benchmark harness, per the issue's stated scope.

[model: other, repo: QuADMesh, session: 2026-05-29T20Z-daily-maintenance]

---

Generated by Claude Code