Fix Warp mesh Poisson residual conflicts

[loliverhennigh]

Prune residual accepted-point conflicts before returning Warp mesh Poisson samples.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[greptile-apps]

Greptile Summary

This PR adds a post-pass conflict-pruning step to the Warp mesh Poisson disk sampler: after dart throwing completes, it rebuilds the hash grid over all accepted points and launches _mark_accepted_conflicts, which deterministically kills any accepted sample whose lower-indexed accepted neighbor is too close, then filters the result with index_select.

• New kernel _mark_accepted_conflicts (_kernels.py): marks accepted samples dead if any lower-indexed accepted sample is within the minimum radius; designed to clear residual parallel-race conflicts without priority ambiguity.
• Integration in op.py: skips the pruning step when final_count <= 1, rebuilds accepted_grid over the full final set, launches the kernel, and returns only the surviving points via torch.nonzero + index_select.

Important Files Changed

Filename	Overview
physicsnemo/nn/functional/geometry/mesh_poisson_disk_sample/_warp_impl/_kernels.py	Adds new _mark_accepted_conflicts Warp kernel for post-pass conflict pruning; kernel has a logical over-pruning issue — it kills samples that are only close to already-dead neighbors because alive flags of neighbors are never checked during the parallel pass.
physicsnemo/nn/functional/geometry/mesh_poisson_disk_sample/_warp_impl/op.py	Integrates the new conflict-pruning kernel into the dart-throwing return path; the hash-grid rebuild, kernel launch, and index-select filter are well-structured and use the correct search radius and Warp/PyTorch interop patterns consistent with the rest of the file.

_{Reviews (1): Last reviewed commit: "Fix Warp mesh Poisson residual conflicts" | Re-trigger Greptile}

[greptile-apps]

Transitive over-pruning due to missing alive check on neighbors

The kernel never checks accepted_alive[neighbor_idx] before deciding to kill sample_idx. Every thread starts with all entries equal to 1 (from torch.ones), so in a chain A (idx=3) → B (idx=5) → C (idx=7) where A–B and B–C are both too close but A–C are not: thread 5 kills itself (conflict with 3), and thread 7 also kills itself (conflict with 5) — even though 5 will be removed and C is actually valid. The fix would be to add if accepted_alive[neighbor_idx] == 0: continue before the _points_too_close call, but a single parallel pass cannot see writes from sibling threads; correcting this correctly requires iterating the kernel until no more kills occur, or performing the pruning serially.

[ktangsali]

@loliverhennigh is this a valid concern?

[loliverhennigh]

/blossom-ci

[loliverhennigh]

@ktangsali could you take a quick look at this RC bug fix? It hardens the Warp mesh Poisson sampler against residual pair-distance conflicts.

[ktangsali]

@loliverhennigh is this a valid concern?

[loliverhennigh]

/blossom-ci