Repository navigation
docs: the NOAA record after #191 with a 10-run median; plan 005, W3SRCE points in lanes - #197
Merged
Merged
Conversation
…main The record for NOAA's wave modellers still described the fork at 80644ba9 and a six-part preset, and quoted speed-ups measured before #191. It now gives the pin 50a10730, the seven parts with CPRT, the preset variable, strict mode, the NaN fill of a stale host VA, the one copy to the device on full, and the 22 regtest entries of the U3 log with the four kept FAIL rows and their reasons. A status table up front answers what such a reader asks first, with a link to the gap list. The speed lines now carry the median of three on the merged code (29.83 s NOAA WW3, 19.99 s Kokkos, 1.49) and the loaded run where Kokkos was slower, both marked as measured on a shared machine. The gap list marks rows 6, 7 and 13 as at the pin. The READMEs link the record and give the patch footprint at the new pin. Goal c3e7eecf-3917, Claude Code session ec4548a3-46a8-46e2-be0a-2d74c3e7eecf. Tested: bash scripts/ww3-gpu.sh --ww3-gpu full --cpu --kokkos resident --repeat 3 at 5cd0140 (every output byte-identical, medians 29.83 s / 19.99 s, load 1.8 to 24.9); scripts/vale.sh on the three English files, 0 errors; lychee --offline on the four files, 0 errors; python3 -m unittest discover tests, 88 OK in a clean worktree (test_results fails in this checkout only on the untracked .claude/worktrees copy); git -C WW3 diff --stat 03adda91 50a10730 -- model and a script over its -U0 hunks for the patch claims Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
h0ffmann
changed the title
The owner fast-forwarded the fork's ww3-gpu/kokkos-pnt from 80644ba9 to 50a10730, so the integration branch again holds the pin and the README rows name it, as before #191. Tested: git -C WW3 ls-remote origin shows ww3-gpu/kokkos-pnt and ww3-gpu/integ-fixes both at 50a10730 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The owner asked for item 1 of the opportunity ranking in this PR: the batched W3SRCE runs W sea points at once, one per vector lane. The plan gives the parity argument (per-lane arithmetic in the Fortran's order, no cross-lane sum, masks for branches, libm scalar per lane) and seven units. Unit S0, a one-thread gdb-sampled profile of today's batch on full, finds 51.1 % of its samples in the scalar per-point routines lanes can vectorise (W3SDS4, W3SIN4, w3srce_team, W3SPR4), 39.0 % in the DIA, which #193's halo already vectorises over directions, and only 8.9 % in libm and libmvec. So the plan goes on to its lane layer. Tested: the S0 profile of docs/log/2026-10-18-srce-lanes-s0-profile.md (1 602 samples, out_grd.ww3 byte-identical to the timing run's Kokkos output); scripts/vale.sh on the plan and the log, 0 errors; lychee --offline on the plan, the log and docs/log/README.md, 0 errors; python3 scripts/figures.py check, current Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…lan 005 L1) Unit L1 of plan 005, the lane layer. The batched kernel's sections become member functions of SrcePoint (init, step_a, dia, step_c, finish) whose bodies are the one-point kernel's statements, moved without a change; w3srce_team composes them as before. w3srce_lanes runs them for up to eight points per team, each section for every point still in the integration loop in turn, and each point's DIA on the whole team. A point reads and writes only its own arrays, so the points' turns cannot change a bit. WW_KOKKOS_SRCE_LANES (1 to 8, default 1, host backends only) sets the number and the exit counters print it. Nothing is vectorised across points yet; L2 does that on the layer. Tested: just kokkos-test openmp-release and serial-debug, 11/11 each, no warning; bash scripts/ww3-gpu.sh --ww3-gpu smoke and full --cpu --kokkos resident with WW_KOKKOS_STRICT=1 WW_KOKKOS_VA_POISON=1, WW_KOKKOS_SRCE_LANES unset (1) and 8: every model file byte-identical to the Fortran of the same executable, every file but the NetCDF to --ww3, nccmp-tol PASS, counter shows 1 and 8 points per team; the four moved bodies found verbatim in order (a line comparison); python3 scripts/port_score.py --write then --check; scripts/vale.sh and lychee --offline on the changed Markdown, 0 errors Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The owner asked for ten runs once the other worker was idle. On the merged code (5cd0140, WW3 50a10730), full case, 32 threads, ten alternated runs each: NOAA WW3 median 26.18 s, the Kokkos resident runtime 15.84 s, 1.65 times less wall time, every output byte-identical to the first run's. The machine was idle at the start (load 2.3). This replaces the shared-machine median of three as the record's figure; the speed still says regtest pending, since 22 entries and not the whole matrix have passed on that commit. Tested: bash scripts/ww3-gpu.sh --ww3-gpu full --cpu --kokkos resident --repeat 10 with the code tree identical to 5cd0140 (git diff --stat empty for kokkos scripts regtests switches), 2026-10-18 21:21-21:32 UTC; scripts/vale.sh on the record, 0 errors Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
h0ffmann
changed the title
h0ffmann
added a commit
that referenced
this pull request
Oct 18, 2026
Brings in #197 (the NOAA record, plan 005, the S0 log and L1). One conflict, in the dated table of docs/log/README.md: both sides appended a 2026-10-18 row; the log is append-only, so both rows are kept, main's first. Tested: scripts/vale.sh and lychee --offline on docs/log/README.md and the PR's four files, 0 errors; python3 scripts/figures.py check, current Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
h0ffmann
added a commit
that referenced
this pull request
Oct 18, 2026
What this session finished (#197: the NOAA record and its ten-run median, plan 005, S0, L1; the merge that unblocked #198), what is open (#199's regtest run and review, plan 005 L3 to L7, the uncommitted opportunity and GFS-Wave analysis), what waits on the owner, and the traps met: unpinned one-thread timings on a hybrid CPU, the load average counting the job itself, g++'s -ftrapping-math and lane loops, -Wpsabi without -march, pkill -f killing its own shell. Tested: scripts/vale.sh on the entry and docs/log/README.md, exit 0, 0 errors; lychee --offline on both, 0 errors Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Before.
docs/NOAA_PROGRESS_RECORD_202610.mddescribed the fork at80644ba9and a six-part preset, and quoted speed-ups measured before #191 (1.5 to 2.4). One loaded run after #191 had Kokkos slower than the Fortran (46.4 s against 31.8 s). The batchedW3SRCEran one sea point per team, with everything but the DIA on one thread, and the per-point sums g++ cannot vectorise.After.
50a10730and the seven-part preset withCPRT. It describes strict mode, the NaN fill of a stale hostVAand the one copy of the spectrum to the device onfull. It lists 22 regtest entries with 0 files different and the four FAIL rows you keep. A status table opens it.main: NOAA WW3 26.18 s, Kokkos resident 15.84 s, 1.65 times less wall time, every output byte-identical to the first run's. Regtest pending ⚠: 22 entries, not the whole matrix.docs/compound/plans/2026-10-18-005-srce-points-in-lanes-plan.md): sea points in the vector lanes of the batchedW3SRCE. It gives the per-lane parity argument and seven units.docs/log/2026-10-18-srce-lanes-s0-profile.md). It puts 51 % of the samples in the scalar per-point routines lanes can vectorise, 39 % in the DIA and 9 % in libm.W3SRCE's sections are member functions ofSrcePoint, with bodies moved verbatim.w3srce_lanesruns up to eight points per team in turns, set byWW_KOKKOS_SRCE_LANES(default 1).smokeandfullare byte-identical to the Fortran with 1 and 8.Goal
c3e7eecf-3917, Claude Code sessionec4548a3-46a8-46e2-be0a-2d74c3e7eecf. Follows the "After merge" list of #191.Evidence
Machine: Intel Core i9-14900, 32 threads,
switch_lab_ompg, OpenMP backend,WW3@50a10730.bash scripts/ww3-gpu.sh --ww3-gpu full --cpu --kokkos resident --repeat 10, code tree identical to5cd0140just regtest-selectedon5cd0140(ww3-gpu-3)ww3_tp2.15x4 andww3_ts2ST4_PR3_UQ:test.comp0/23, 0/23, 0/23, 0/25, 0/22,nccmp-tolPASS,SRCEspectra 6 900 to 137 000;smokebyte-identicalsmoke,fullwithWW_KOKKOS_STRICT=1 WW_KOKKOS_VA_POISON=1,WW_KOKKOS_SRCE_LANES1 and 8just kokkos-test serial-debug,openmp-releasescripts/vale.sh,lychee --offline,port_score.py --check,figures.py check,python3 -m unittest discover tests(clean worktree)Needs your review
WW_KOKKOS_SRCE_LANESis a new run-time variable. Its default of 1 is today's path, and a device always uses 1.Still in this PR
W3SIN4's stress scan on 8-wide vectors, one point per lane. It is bit-identical onsmokeandfull, but not committed until a pinned one-thread timing shows its gain.--build-onlycheck of the lane code, and the regtest selection with 8 points per team.scripts/restart_pair.sh) has not run.🤖 Generated with Claude Code