Agent:claude-fastfields-to-teeny
Found during fastfields-cpu-impl#49's review (kernels#50 phase 4), confirmed as pre-existing in reg_field.h.
The bug
relax_bending_rls_ and relax_bending_jrls_ both use patch3 (a 3^ndim-colour scheme — bending needs reach-2 separation, so 3 colours per axis), but their outer loop is for (offset_t n = 0; n < 2*niter; ++n), where every otherpatch3 site (relax_bending_, and flow's relax_bending_/relax_all_) loops n < pow<ndim>(3)*niter. This looks like a copy/paste of the neighbouring patch1 (membrane) loop bound.
Effect: with niter=1 in 3-D, this visits colours 0 and 1 of 27 and leaves 25/27 of the volume never relaxed — i.e. the RLS/JRLS bending relaxer is doing almost nothing.
Confirmed, preserved exactly by cpu-impl#50 (not fixed there — out of that PR's scope)
cpu-impl#50's subsample-based rewrite keeps the identical 2*niter bound and takes the colour as n % 3^ndim, faithfully reproducing this bug rather than silently fixing it (per this project's "one branch, one concern" convention — a correctness fix here would be a separate, deliberate behaviour change). Its exhaustive partition-equivalence check (§1 of that PR) covers both sites at their real (buggy) pass range and confirms the new code visits exactly the same colours the old code did, no more and no fewer.
Scope
Fixing this (loop bound 2*niter → pow<ndim>(3)*niter) is a real behaviour change to field_relax's numerics for RLS/JRLS bending — worth its own issue/PR/decision, not bundled into the colouring-mechanism refactor. Note also fastfields-cpu-lib#66 — field_relax isn't exported by cpu-lib at all today, which is presumably why this was never caught by a test.
Generated by Claude Code
Agent:
claude-fastfields-to-teenyFound during fastfields-cpu-impl#49's review (kernels#50 phase 4), confirmed as pre-existing in
reg_field.h.The bug
relax_bending_rls_andrelax_bending_jrls_both usepatch3(a3^ndim-colour scheme — bending needs reach-2 separation, so 3 colours per axis), but their outer loop isfor (offset_t n = 0; n < 2*niter; ++n), where every otherpatch3site (relax_bending_, and flow'srelax_bending_/relax_all_) loopsn < pow<ndim>(3)*niter. This looks like a copy/paste of the neighbouringpatch1(membrane) loop bound.Effect: with
niter=1in 3-D, this visits colours0and1of27and leaves 25/27 of the volume never relaxed — i.e. the RLS/JRLS bending relaxer is doing almost nothing.Confirmed, preserved exactly by cpu-impl#50 (not fixed there — out of that PR's scope)
cpu-impl#50's subsample-based rewrite keeps the identical
2*niterbound and takes the colour asn % 3^ndim, faithfully reproducing this bug rather than silently fixing it (per this project's "one branch, one concern" convention — a correctness fix here would be a separate, deliberate behaviour change). Its exhaustive partition-equivalence check (§1 of that PR) covers both sites at their real (buggy) pass range and confirms the new code visits exactly the same colours the old code did, no more and no fewer.Scope
Fixing this (loop bound
2*niter→pow<ndim>(3)*niter) is a real behaviour change tofield_relax's numerics for RLS/JRLS bending — worth its own issue/PR/decision, not bundled into the colouring-mechanism refactor. Note also fastfields-cpu-lib#66 —field_relaxisn't exported by cpu-lib at all today, which is presumably why this was never caught by a test.Generated by Claude Code