[h0ffmann]

Before. After L1 (#197), the batched W3SRCE could take up to eight sea points per team, but only when WW_KOKKOS_SRCE_LANES was set; the default of 1 was one point per team. Each point still ran W3SIN4 alone on one thread. The stress scan of W3SIN4 (w3src4md.F90:696-797) has ordered sums and per-bin branches that g++ leaves scalar inside one point. By the S0 profile, W3SIN4's own code was 12.9 % of one thread's batch time.

After.

• The scalar routine is split, verbatim. w3sin4_point is now sin4_prep, sin4_scan and sin4_tail, with its lines moved without a change.
• sin4_scan_lanes<8> runs the scan for eight points at once, one point per lane, on GCC vector types of eight REAL.
  • Each vector operation is the scalar statement's, lane by lane, with its operands in the same order.
  • A branch becomes a select of the value its taken side computes.
  • expf and powf are called per lane, only where the branch calls them.
  • Each lane keeps its own stress sums, added in ITH order.
• Where it runs. w3srce_lanes calls it at both W3SIN4 sites of the integration step.
• Eight points per team is now the default on host backends, as you asked. Small launches fall back to one point per team: below 8 lanes × threads points, every thread still gets a team (ww3_ts1, with one sea point, takes one per team). A device keeps one point per team.
• Gain. On full, the one-thread W3SRCE kernel takes 5.1 % less time, and the 32-thread ww3_shel run 2.6 % less. Every output stays byte-identical to the Fortran.
• The session's handover is docs/log/2026-10-18-goal-c3e7eecf-handover.md, merged here with main after docs: ADR-0019 (Proposed) and plan 006 #198.

Goal c3e7eecf-6142, Claude Code session ec4548a3-46a8-46e2-be0a-2d74c3e7eecf. Plan: docs/compound/plans/2026-10-18-005-srce-points-in-lanes-plan.md, unit L2. Record: docs/log/2026-10-18-srce-lanes-sin4.md.

Evidence

Intel Core i9-14900, switch_lab_ompg, OpenMP backend, WW3@50a10730.

Check	Result
just regtest-selected at 919c5cf (the default of 8, strict, 6 threads per run)	ww3_tp2.15 x4 and ww3_ts2 ST4_PR3_UQ: test.comp 0/23, 0/23, 0/23, 0/25, 0/22, nccmp-tol PASS; smoke byte-identical; the verdicts of main's run. The four ww3_tp2.15 entries ran the lane path (276 and 5 480 points per launch, at least 48); ww3_ts2 (24 points per launch) ran one point per team
smoke, full with no variable set, WW_KOKKOS_STRICT=1 WW_KOKKOS_VA_POISON=1	every model file byte-identical to the Fortran of the same executable; every file but the NetCDF to --ww3's
srce.batch.kernel, full, one thread pinned to a performance core, 3 alternated runs each	105.17 s with 1 point per team, 99.77 s with 8: 5.1 % less
ww3_shel, full, 32 threads, 3 alternated runs each	15.88 s with 1, 15.47 s with the default: 2.6 % less; every out_grd.ww3 identical
bash scripts/ww3-gpu.sh --ww3-gpu smoke --gpu --kokkos resident --build-only	compiles and links, no warning; nothing run on a device
just kokkos-test serial-debug, openmp-release	11/11 each, no warning
port_score.py --write then --check; scripts/vale.sh, lychee --offline	pass

⚠ Some figures are not as clean as the table suggests:

• The one-thread timing ran before vload took a reference, a change made only to remove a -Wpsabi warning, and was not timed again.
• The 32-thread loads (22 to 38) are those back-to-back runs themselves, inferred from their spread.
• The regtest entries took about twice main's time. That's machine load: ww3_ts2, which did not take the lane path, slowed the same.

Needs your review

• Loop nesting (AGENTS.md, "Porting"). The scan's lane loop is innermost, and every lane's arithmetic is the scalar statement's.
• Explicit vector types in a ported routine. Written as plain loops, g++ left the scan scalar under its default -ftrapping-math. Changing that flag would affect every kernel, so this PR uses explicit vectors in this one loop.
• The new default. Resident runs on host backends now take the lane path with no variable set. WW_KOKKOS_SRCE_LANES=1 restores one point per team.

🤖 Generated with Claude Code