community_fault_model.py: nodal_plane_2_votes is weighted by nodal_plane_1's strike

[lispandfound]

Location: source_modelling/community_fault_model.py:483

What happens: In nodal_plane_from_neighbours, the two vote sums are near-identical, but the weight inside nodal_plane_2_votes still references nodal_plane_1.strike:

469: nodal_plane_1_votes = sum(
473:     * abs(line_segments[segment] - nodal_plane_1.strike + 1e-5)   # correct
476:     if abs(... - nodal_plane_1.strike) <  abs(... - nodal_plane_2.strike)

479: nodal_plane_2_votes = sum(
483:     * abs(line_segments[segment] - nodal_plane_1.strike + 1e-5)   # <-- should be nodal_plane_2
486:     if abs(... - nodal_plane_1.strike) >= abs(... - nodal_plane_2.strike)

The filter at :486-487 is correct — it selects segments closer to plane 2 — but the weight at :483 measures those segments against plane 1's strike.

Why that's wrong: The weight is 1 / (distance * strike_misfit), so it is meant to reward segments whose strike closely matches the plane being voted for. By construction, every segment counted at :486 has a larger misfit to plane 1 than to plane 2, so using plane 1's misfit in the denominator systematically shrinks plane 2's weights. The bias always runs one way: nodal_plane_1 wins ties and near-ties it should lose. The symmetry with :473 makes the intent unambiguous.

How to reproduce: Take a point near trace segments whose strikes sit just closer to nodal_plane_2.strike than to nodal_plane_1.strike. Each such segment contributes 1/(d * |seg - np1|) instead of the intended 1/(d * |seg - np2|); since |seg - np1| > |seg - np2|, the contribution is too small and nodal_plane_1_votes >= nodal_plane_2_votes at :490 returns nodal_plane_1.

Suggested direction: Change nodal_plane_1.strike to nodal_plane_2.strike at :483. Factoring the weight into a small helper taking the plane as an argument would prevent the two branches drifting again.

Confidence: high

[lispandfound]

Attempted the one-line fix and it is not safe to merge on its own. Posting the measurements rather than a PR.

The one-line change breaks the only test

Changing nodal_plane_1.strike to nodal_plane_2.strike at :483 makes test_most_likely_nodal_plane fail. Scored on that test's metric — how often most_likely_nodal_plane returns nodal_plane_1, out of 98 GeoNet solutions, threshold > 75:

variant	score
current main (weight = np1, raw abs)	81
weight fixed (weight = np2, raw abs)	68
weight fixed + angular distance mod 180	72
weight fixed + angular distance mod 360	64
weight buggy + angular distance mod 180	81
trivial "always return plane 1"	98

No principled variant clears the threshold.

Why: the benchmark rewards the bias

tests/data/GeoNet_Test_Solutions.csv has no column saying which nodal plane is correct — the columns are strike1/dip1/rake1, strike2/dip2/rake2 and moment-tensor fields. test_most_likely_nodal_plane simply counts how often the function returns nodal_plane_1 and asserts correct > 75, i.e. it assumes GeoNet's first-listed plane is right in the large majority of cases.

That metric is maximised by always returning plane 1 (98/98). So it does not measure discrimination — it measures plane-1 bias. The bug at :483 supplies exactly that bias: every segment counted in nodal_plane_2_votes is by construction closer to plane 2, so weighting by the plane-1 misfit shrinks plane 2's weights and tilts the result toward plane 1. Removing the bug removes the tilt, and the score drops.

What this means

The copy-paste is still a real defect — the code does not compute what the surrounding code plainly intends, and the symmetry with :473 is unambiguous. But it cannot be fixed in isolation, and the current 81/98 should not be read as evidence the algorithm works.

Two things need a maintainer decision before a fix can land, which is why I am not attaching a PR:

1. What is the ground truth? The test needs a real per-event label for which plane was correct (from the mapped rupture, or an independent catalogue) before any change to the voting can be evaluated. As written, a regression in the test cannot be distinguished from a removal of an accidental bias.
2. Should the bias be replaced by something deliberate? If plane 1 genuinely is more often correct — a reasonable prior, given GeoNet's listing convention — that belongs in the code as an explicit prior, not as an arithmetic slip. The tie-break at :490 (>= favours plane 1) is already an implicit half-step in that direction.

Also relevant: this interacts with #96. Proper angular distance changes which segments vote for which plane, so the two should be evaluated together, not sequentially. I verified a targeted unit case where the weight bug alone flips the result (three neighbours at strikes 10/80/85 against planes striking 0 and 90: correct weighting returns plane 2, current code returns plane 1), so a regression test is available once the ground-truth question is settled.

[lispandfound]

Deprecating this nodal plane classification module anyway.