gpuwm-hex 0.2.0__tar.gz → 0.2.2__tar.gz

{gpuwm_hex-0.2.0/src/gpuwm_hex.egg-info → gpuwm_hex-0.2.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: gpuwm-hex
-Version: 0.2.0
+Version: 0.2.2
 Summary: GPU global atmospheric model on unstructured Voronoi meshes: a CUDA port of the MPAS-A v8.4.1 dycore with ArWen physics, arbitrary mesh generation, and single-card mesh streaming for 12-16 GB GPUs.
 License-Expression: Apache-2.0
 Project-URL: Homepage, https://github.com/FahrenheitResearch/gpuwm-hex
@@ -24,7 +24,7 @@ License-File: NOTICE
 Requires-Dist: numpy>=2.0
 Requires-Dist: netCDF4>=1.6
 Requires-Dist: scipy>=1.11
-Requires-Dist: gpuwm<2.5.9,>=2.5.8
+Requires-Dist: gpuwm<2.6.2,>=2.6.1
 Provides-Extra: gpu-cu12
 Requires-Dist: cupy-cuda12x[ctk]>=14.0; extra == "gpu-cu12"
 Provides-Extra: gpu-cu13
@@ -182,7 +182,7 @@ verdict for each divergence is in
 | Python | 3.11 or newer |
 | GPU | A CUDA device. Memory is set by mesh size *and* by the card, and not by a line through the two: the footprint is a per-card core, plus the Grell-Freitas and YSU column workspaces charged at `min(cells, tile)`, plus a per-cell term, all in `hexcore.device_admission`. Measured 2026-08-26 on an RTX 5090 at the merged tip: the published 40,962-cell global mesh (x1.40962, about 120 km) peaked at **8,874 MiB — inside a 12 GiB card's budget**; the 163,842-cell mesh (x4.163842, about 24 km) peaked at **20,446 MiB**, and every free-memory gate admits at the measured floor — the prediction plus that card's own margin, **about 21.7 GiB free at x4** — so x4 remains in practice a 32 GiB-card configuration. The core is a property of the card, not the mesh, and the door reads the card's multiprocessor count at the decision rather than assuming a 5090: the 16 GiB and 10 GiB parts each carry their own measured row, and a card nobody has measured gets a derived row that is labelled derived. A card with its own #264 ledger can still supply it with `--device-fixed-mib` / `--device-bytes-per-cell`. Receipts: `evidence/memory-row-refit-20260826/node2/`, `evidence/l6-capacity-20260825/` and `evidence/memory-shape-20260827/`. |
 | CUDA | CuPy matching your driver's CUDA major — there is no way for pip to detect it, so you choose (below). |
-| Engine | The `gpuwm` distribution, `>=2.5.8,<2.5.9` — a bounded range, and pip resolves it for you: the physics seam, and the bundle that carries the MPAS bridge binaries the doors drive. **Plus a `gpuwm` source checkout at `v2.5.8` for the forecast lane** — see *The engine pin*. |
+| Engine | The `gpuwm` distribution, `>=2.6.1,<2.6.2` — a bounded range, and pip resolves it for you: the physics seam, and the bundle that carries the MPAS bridge binaries the doors drive. **Plus a `gpuwm` source checkout at `v2.6.1` for the forecast lane** — see *The engine pin*. |
 | Assets | A mesh grid file, a matching static file, and (for the init door) a vertical-grid declaration — normally a `--vertical-spec` JSON; a native-minted init file as a capsule is the compatibility mode. **gpuwm-hex ships none of these and has no fetch path for them.** See *Assets you must supply*. |
 | Rust binaries | `rw_mpas_init` for the init door; `rw_mpas_convert` and `rw_wrfbatch` for the render door. They are built from the `gpuwm` source tree — see *Building the Rust engines*. |
 
@@ -242,40 +242,43 @@ unchanged.
 
 ### The engine pin
 
-gpuwm-hex depends on `gpuwm>=2.5.8,<2.5.9` — a **bounded range**, and the
+gpuwm-hex depends on `gpuwm>=2.6.1,<2.6.2` — a **bounded range**, and the
 bound is the point. The port pins the engine's physics seam by the SHA-256 of
 **sixteen individual gpuwm source files**, and the gap between a published
-stamp and the pinned bytes has recurred at every cut. Re-measured 2026-08-28
-against the real published bytes of every 2.5.x release, plus the `v2.5.5` tag
-that has no release at all — JSON at
-`evidence/repin-258-20260828/engine-verdicts.json`, instrument beside it:
+stamp and the pinned bytes has recurred at every cut. Re-measured 2026-09-01
+against the real published bytes of every 2.5.x and 2.6.x release, plus the
+`v2.5.5` tag that has no release at all — JSON at
+`evidence/repin-261-20260901/engine-verdicts.json`, instrument at
+`evidence/standalone-20260827/measure_engine_verdicts.py`:
 
 | gpuwm | on PyPI | seam pin | `--offline` build road |
 | --- | --- | --- | --- |
-| 2.5.0 | yes | 10 of 16 moved | complete |
-| 2.5.1 | yes | 10 of 16 moved | complete |
-| 2.5.2 | yes | 9 of 16 moved | complete |
-| 2.5.3 | yes | 6 of 16 moved | complete |
-| 2.5.4 | yes | 6 of 16 moved | complete |
-| 2.5.5 | **no — a git tag with no release** | 4 of 16 moved | **broken** |
-| 2.5.6 | yes | 4 of 16 moved | complete |
-| 2.5.7 | yes | 3 of 16 moved | complete |
-| **2.5.8** | yes | **matches** | complete |
-
-**2.5.8 is the only published engine whose bytes match the pin**, so it is the
+| 2.5.0 | yes | 11 of 16 moved | complete |
+| 2.5.1 | yes | 11 of 16 moved | complete |
+| 2.5.2 | yes | 10 of 16 moved | complete |
+| 2.5.3 | yes | 7 of 16 moved | complete |
+| 2.5.4 | yes | 7 of 16 moved | complete |
+| 2.5.5 | **no — a git tag with no release** | 7 of 16 moved | **broken** |
+| 2.5.6 | yes | 7 of 16 moved | complete |
+| 2.5.7 | yes | 6 of 16 moved | complete |
+| 2.5.8 | yes | 5 of 16 moved | complete |
+| 2.6.0 | yes | 3 of 16 moved | complete |
+| **2.6.1** | yes | **matches** | complete |
+
+**2.6.1 is the only published engine whose bytes match the pin**, so it is the
 floor, and with the exclusive ceiling one patch above it, it is the whole
 range.
 
-That is a narrower claim than this page carried before 2026-08-28, and the
+That is the same narrow claim this page has carried since 2026-08-28, and the
 reason is not that an engine regressed. The `moved` column is measured against
 **this port's** seam manifest, so re-pinning that manifest moves every row at
-once, including rows for engines cut long before it: 2.5.6 read `matches`
-under the previous manifest and reads `4 of 16 moved` under this one. A row
+once, including rows for engines cut long before it: 2.6.0 read `matches`
+under the previous manifest and reads `3 of 16 moved` under this one. A row
 from the old table is not comparable with a row from this one, and neither is
 a row anyone patches by hand.
 
 The consequence is worth stating rather than discovering: **this port has no
-fallback engine.** If 2.5.8 were withdrawn, the answer would be to publish a
+fallback engine.** If 2.6.1 were withdrawn, the answer would be to publish a
 new engine and re-measure, not to widen the range.
 
 Two facts about 2.5.5 that this page used to give as floor reasons are still
@@ -296,7 +299,7 @@ stops there with `failed to open file .../cc/src/target/generated.rs`.
 > reported the estate healthy and exited 0. A green install and a dead run.
 >
 > The ceiling is exclusive and sits at the first engine that is not measured
-> usable, so a future 2.5.9 is excluded exactly as 2.5.7 is today. Admitting a
+> usable, so a future 2.6.2 is excluded exactly as 2.6.0 is today. Admitting a
 > new engine is a deliberate act: re-run
 > `evidence/standalone-20260827/measure_engine_verdicts.py`, splice its JSON
 > into the table in `hexcore.engine_pin` with
@@ -316,22 +319,22 @@ rows landed the day after the 2.5.2 upload, so published 2.5.2 stages none of
 them through `gpuwm fetch-bridges`. Both front doors drive those binaries, so
 a user who resolved onto a 2.5.2 engine could open **neither door**. That is a
 stranded install rather than a degraded one, and a dependency floor is the
-only place pip can refuse it. Measured 2026-08-28 on the pinned engine:
+only place pip can refuse it. Measured 2026-08-28 on the then-pinned engine:
 `gpuwm fetch-bridges` from a published 2.5.8 install downloads
 `gpuwm-bridges-v2.5.8-win-x86_64.zip` and stages **26 of 26 artifacts, each
 verified against the packaged pin** — the four above, plus `rw_wrfbatch` and
 the `rw_mpas_lbc` the limited-area lane needs.
 
 *(The gpuwm source tree publishes too: `github.com/FahrenheitResearch/arwen`
-carries tags `v2.5.0` through `v2.5.8` with the full tree, `docs/mpas-seam.md`
+carries tags `v2.5.0` through `v2.6.1` with the full tree, `docs/mpas-seam.md`
 and `gpuwm/core/mpas_column_batch.py` included. The table above was taken by
-cloning all nine of those tags and hashing the pinned files, so the build road
-below is open to anyone, subject to the 2.5.5 vendor gap noted above.)*
+hashing the pinned files at all eleven of those tags, so the build road below
+is open to anyone, subject to the 2.5.5 vendor gap noted above.)*
 
 **Installing `gpuwm` is necessary but not sufficient for the forecast lane.**
 The `forecast` door refuses without `--gpuwm-checkout`: a gpuwm **git
 checkout** at the pinned commit (`--arwen-checkout` on the driver beneath it),
-in addition to the installed distribution. Clone `v2.5.8`. This is stated
+in addition to the installed distribution. Clone `v2.6.1`. This is stated
 plainly because the alternative — discovering it as a `FileNotFoundError` deep
 in a launch — is the trap; the `forecast` door refuses by name instead, and so
 does `gpuwm-hex doctor`.
@@ -469,7 +472,7 @@ bundle carries `rw_wrfbatch` and **not** `rw_mpas_init` or `rw_mpas_convert`.
 On that engine `gpuwm fetch-bridges` gives you the renderer and nothing that
 opens either MPAS door. That measurement is why the dependency floor cleared
 2.5.3 and never fell back: 2.5.3 is where the four MPAS bridge binaries
-enter the bundle, and the current `gpuwm>=2.5.8,<2.5.9` range keeps that
+enter the bundle, and the current `gpuwm>=2.6.1,<2.6.2` range keeps that
 guarantee, so pip cannot resolve you onto an engine that strands both doors. A
 conforming install therefore never sees the 2.5.2 shortfall; it is recorded
 here because it is the reason the floor first moved.
@@ -574,7 +577,7 @@ bytes can be named by commit, and an install has no commit — and a **gpuwm-hex
 source checkout** for the drivers under `tools/`, which verify their own
 executing modules by SHA-256 and therefore cannot live inside the wheel.
 `gpuwm-hex doctor` reports the same two gaps. The gpuwm one is no longer about
-a pinned file the wheel cannot reach: at 2.5.8 all sixteen resolve from an
+a pinned file the wheel cannot reach: since 2.5.8 all sixteen resolve from an
 install (*The engine pin*).
 
 Its inputs are a mesh, a static file and an init. The registry makes the first
@@ -794,15 +797,25 @@ Measured over 24 h, two independent weather cases, two mixing regimes,
 They entered this repository already finished on 2026-08-20, and there is no
 receipt directory, no card and no run commit for them anywhere in the tree.
 What can be established is a ceiling: the commit that introduced them pinned
-engine `629ddb6f0`, so they were measured at or before that pin. Three engine
+engine `629ddb6f0`, so they were measured at or before that pin. Five engine
 pin moves have landed since — `0d04db712` (2026-08-24), `26daaab7e`
-(2026-08-25) and `659962929` (2026-08-28). The **last** of the three is
-measured to change nothing: a four-arm byte A/B on one card found the old and
-new pins identical on the atmosphere half of the per-step fingerprint at all
-31 steps and on 0 of 138 history variables
-(`evidence/seam-258-ab-20260828/`) — one mesh, one case, one hour. The two
-earlier moves have no such arm, and none of the three magnitudes has been
-re-measured over 24 h since. Whether any of them moved is **NOT MEASURED**.
+(2026-08-25), `659962929` (2026-08-28), `7e34a48` (2026-08-31, gpuwm
+2.6.0) and `df5f34c5c` (2026-09-01, gpuwm 2.6.1). The **2.5.8** move is measured to change nothing: a four-arm byte A/B
+on one card found the old and new pins identical on the atmosphere half of
+the per-step fingerprint at all 31 steps and on 0 of 138 history variables
+(`evidence/seam-258-ab-20260828/`) — one mesh, one case, one hour. The
+**2.6.0** move also crosses the executed seam (`gpuwm/core/rrtmg_legacy.py`
+among its three moved files) and is measured the same way at the same
+scope: the x4 proof re-run at that pin wrote an F001 history byte-identical
+to the 2.5.8 proof's (`evidence/repin-260-20260831/x4-proof/`). The
+**2.6.1** move crosses it a third time, at its centre — the seam's own batch
+driver `gpuwm/core/mpas_column_batch.py` gains restart schema v2 and the P3
+eight-species transport — and is measured the same way at the same scope:
+the x4 proof re-run at that pin wrote all four snapshots (F000, F030, F001
+and the restarted F001) byte-identical to the 2.6.0 proof's, so one F001
+SHA-256 now spans three engines (`evidence/repin-261-20260901/x4-proof/`).
+The two earliest moves have no such arm, and none of the three magnitudes
+has been re-measured over 24 h since. Whether any of them moved is **NOT MEASURED**.
 Read them as the numbers from the pre-2026-08-20 engine, not as today's.
 
 1. **Upper-level warm drift.** Above level 45 the port warms relative to native
@@ -859,7 +872,8 @@ case-independent, which chaos cannot be, and each names a lane to fix.
 > `--cull-parent`, and `rw_mpas_lbc` was in no bundle and no published source
 > (measured 2026-08-27, `evidence/userwalk-20260827/RECEIPT.md` — that receipt
 > is a record of 2.5.7 and is not restated here as current fact). The engine
-> then published 2.5.8, which this distribution requires.
+> then published 2.5.8, which this distribution required until it re-pinned
+> onto 2.6.0 and then 2.6.1.
 >
 > Measured 2026-08-28 against the real published artefacts: `gpuwm
 > fetch-bridges` on a 2.5.8 install downloads

{gpuwm_hex-0.2.0 → gpuwm_hex-0.2.2}/README.md

@@ -144,7 +144,7 @@ verdict for each divergence is in
 | Python | 3.11 or newer |
 | GPU | A CUDA device. Memory is set by mesh size *and* by the card, and not by a line through the two: the footprint is a per-card core, plus the Grell-Freitas and YSU column workspaces charged at `min(cells, tile)`, plus a per-cell term, all in `hexcore.device_admission`. Measured 2026-08-26 on an RTX 5090 at the merged tip: the published 40,962-cell global mesh (x1.40962, about 120 km) peaked at **8,874 MiB — inside a 12 GiB card's budget**; the 163,842-cell mesh (x4.163842, about 24 km) peaked at **20,446 MiB**, and every free-memory gate admits at the measured floor — the prediction plus that card's own margin, **about 21.7 GiB free at x4** — so x4 remains in practice a 32 GiB-card configuration. The core is a property of the card, not the mesh, and the door reads the card's multiprocessor count at the decision rather than assuming a 5090: the 16 GiB and 10 GiB parts each carry their own measured row, and a card nobody has measured gets a derived row that is labelled derived. A card with its own #264 ledger can still supply it with `--device-fixed-mib` / `--device-bytes-per-cell`. Receipts: `evidence/memory-row-refit-20260826/node2/`, `evidence/l6-capacity-20260825/` and `evidence/memory-shape-20260827/`. |
 | CUDA | CuPy matching your driver's CUDA major — there is no way for pip to detect it, so you choose (below). |
-| Engine | The `gpuwm` distribution, `>=2.5.8,<2.5.9` — a bounded range, and pip resolves it for you: the physics seam, and the bundle that carries the MPAS bridge binaries the doors drive. **Plus a `gpuwm` source checkout at `v2.5.8` for the forecast lane** — see *The engine pin*. |
+| Engine | The `gpuwm` distribution, `>=2.6.1,<2.6.2` — a bounded range, and pip resolves it for you: the physics seam, and the bundle that carries the MPAS bridge binaries the doors drive. **Plus a `gpuwm` source checkout at `v2.6.1` for the forecast lane** — see *The engine pin*. |
 | Assets | A mesh grid file, a matching static file, and (for the init door) a vertical-grid declaration — normally a `--vertical-spec` JSON; a native-minted init file as a capsule is the compatibility mode. **gpuwm-hex ships none of these and has no fetch path for them.** See *Assets you must supply*. |
 | Rust binaries | `rw_mpas_init` for the init door; `rw_mpas_convert` and `rw_wrfbatch` for the render door. They are built from the `gpuwm` source tree — see *Building the Rust engines*. |
 
@@ -204,40 +204,43 @@ unchanged.
 
 ### The engine pin
 
-gpuwm-hex depends on `gpuwm>=2.5.8,<2.5.9` — a **bounded range**, and the
+gpuwm-hex depends on `gpuwm>=2.6.1,<2.6.2` — a **bounded range**, and the
 bound is the point. The port pins the engine's physics seam by the SHA-256 of
 **sixteen individual gpuwm source files**, and the gap between a published
-stamp and the pinned bytes has recurred at every cut. Re-measured 2026-08-28
-against the real published bytes of every 2.5.x release, plus the `v2.5.5` tag
-that has no release at all — JSON at
-`evidence/repin-258-20260828/engine-verdicts.json`, instrument beside it:
+stamp and the pinned bytes has recurred at every cut. Re-measured 2026-09-01
+against the real published bytes of every 2.5.x and 2.6.x release, plus the
+`v2.5.5` tag that has no release at all — JSON at
+`evidence/repin-261-20260901/engine-verdicts.json`, instrument at
+`evidence/standalone-20260827/measure_engine_verdicts.py`:
 
 | gpuwm | on PyPI | seam pin | `--offline` build road |
 | --- | --- | --- | --- |
-| 2.5.0 | yes | 10 of 16 moved | complete |
-| 2.5.1 | yes | 10 of 16 moved | complete |
-| 2.5.2 | yes | 9 of 16 moved | complete |
-| 2.5.3 | yes | 6 of 16 moved | complete |
-| 2.5.4 | yes | 6 of 16 moved | complete |
-| 2.5.5 | **no — a git tag with no release** | 4 of 16 moved | **broken** |
-| 2.5.6 | yes | 4 of 16 moved | complete |
-| 2.5.7 | yes | 3 of 16 moved | complete |
-| **2.5.8** | yes | **matches** | complete |
-
-**2.5.8 is the only published engine whose bytes match the pin**, so it is the
+| 2.5.0 | yes | 11 of 16 moved | complete |
+| 2.5.1 | yes | 11 of 16 moved | complete |
+| 2.5.2 | yes | 10 of 16 moved | complete |
+| 2.5.3 | yes | 7 of 16 moved | complete |
+| 2.5.4 | yes | 7 of 16 moved | complete |
+| 2.5.5 | **no — a git tag with no release** | 7 of 16 moved | **broken** |
+| 2.5.6 | yes | 7 of 16 moved | complete |
+| 2.5.7 | yes | 6 of 16 moved | complete |
+| 2.5.8 | yes | 5 of 16 moved | complete |
+| 2.6.0 | yes | 3 of 16 moved | complete |
+| **2.6.1** | yes | **matches** | complete |
+
+**2.6.1 is the only published engine whose bytes match the pin**, so it is the
 floor, and with the exclusive ceiling one patch above it, it is the whole
 range.
 
-That is a narrower claim than this page carried before 2026-08-28, and the
+That is the same narrow claim this page has carried since 2026-08-28, and the
 reason is not that an engine regressed. The `moved` column is measured against
 **this port's** seam manifest, so re-pinning that manifest moves every row at
-once, including rows for engines cut long before it: 2.5.6 read `matches`
-under the previous manifest and reads `4 of 16 moved` under this one. A row
+once, including rows for engines cut long before it: 2.6.0 read `matches`
+under the previous manifest and reads `3 of 16 moved` under this one. A row
 from the old table is not comparable with a row from this one, and neither is
 a row anyone patches by hand.
 
 The consequence is worth stating rather than discovering: **this port has no
-fallback engine.** If 2.5.8 were withdrawn, the answer would be to publish a
+fallback engine.** If 2.6.1 were withdrawn, the answer would be to publish a
 new engine and re-measure, not to widen the range.
 
 Two facts about 2.5.5 that this page used to give as floor reasons are still
@@ -258,7 +261,7 @@ stops there with `failed to open file .../cc/src/target/generated.rs`.
 > reported the estate healthy and exited 0. A green install and a dead run.
 >
 > The ceiling is exclusive and sits at the first engine that is not measured
-> usable, so a future 2.5.9 is excluded exactly as 2.5.7 is today. Admitting a
+> usable, so a future 2.6.2 is excluded exactly as 2.6.0 is today. Admitting a
 > new engine is a deliberate act: re-run
 > `evidence/standalone-20260827/measure_engine_verdicts.py`, splice its JSON
 > into the table in `hexcore.engine_pin` with
@@ -278,22 +281,22 @@ rows landed the day after the 2.5.2 upload, so published 2.5.2 stages none of
 them through `gpuwm fetch-bridges`. Both front doors drive those binaries, so
 a user who resolved onto a 2.5.2 engine could open **neither door**. That is a
 stranded install rather than a degraded one, and a dependency floor is the
-only place pip can refuse it. Measured 2026-08-28 on the pinned engine:
+only place pip can refuse it. Measured 2026-08-28 on the then-pinned engine:
 `gpuwm fetch-bridges` from a published 2.5.8 install downloads
 `gpuwm-bridges-v2.5.8-win-x86_64.zip` and stages **26 of 26 artifacts, each
 verified against the packaged pin** — the four above, plus `rw_wrfbatch` and
 the `rw_mpas_lbc` the limited-area lane needs.
 
 *(The gpuwm source tree publishes too: `github.com/FahrenheitResearch/arwen`
-carries tags `v2.5.0` through `v2.5.8` with the full tree, `docs/mpas-seam.md`
+carries tags `v2.5.0` through `v2.6.1` with the full tree, `docs/mpas-seam.md`
 and `gpuwm/core/mpas_column_batch.py` included. The table above was taken by
-cloning all nine of those tags and hashing the pinned files, so the build road
-below is open to anyone, subject to the 2.5.5 vendor gap noted above.)*
+hashing the pinned files at all eleven of those tags, so the build road below
+is open to anyone, subject to the 2.5.5 vendor gap noted above.)*
 
 **Installing `gpuwm` is necessary but not sufficient for the forecast lane.**
 The `forecast` door refuses without `--gpuwm-checkout`: a gpuwm **git
 checkout** at the pinned commit (`--arwen-checkout` on the driver beneath it),
-in addition to the installed distribution. Clone `v2.5.8`. This is stated
+in addition to the installed distribution. Clone `v2.6.1`. This is stated
 plainly because the alternative — discovering it as a `FileNotFoundError` deep
 in a launch — is the trap; the `forecast` door refuses by name instead, and so
 does `gpuwm-hex doctor`.
@@ -431,7 +434,7 @@ bundle carries `rw_wrfbatch` and **not** `rw_mpas_init` or `rw_mpas_convert`.
 On that engine `gpuwm fetch-bridges` gives you the renderer and nothing that
 opens either MPAS door. That measurement is why the dependency floor cleared
 2.5.3 and never fell back: 2.5.3 is where the four MPAS bridge binaries
-enter the bundle, and the current `gpuwm>=2.5.8,<2.5.9` range keeps that
+enter the bundle, and the current `gpuwm>=2.6.1,<2.6.2` range keeps that
 guarantee, so pip cannot resolve you onto an engine that strands both doors. A
 conforming install therefore never sees the 2.5.2 shortfall; it is recorded
 here because it is the reason the floor first moved.
@@ -536,7 +539,7 @@ bytes can be named by commit, and an install has no commit — and a **gpuwm-hex
 source checkout** for the drivers under `tools/`, which verify their own
 executing modules by SHA-256 and therefore cannot live inside the wheel.
 `gpuwm-hex doctor` reports the same two gaps. The gpuwm one is no longer about
-a pinned file the wheel cannot reach: at 2.5.8 all sixteen resolve from an
+a pinned file the wheel cannot reach: since 2.5.8 all sixteen resolve from an
 install (*The engine pin*).
 
 Its inputs are a mesh, a static file and an init. The registry makes the first
@@ -756,15 +759,25 @@ Measured over 24 h, two independent weather cases, two mixing regimes,
 They entered this repository already finished on 2026-08-20, and there is no
 receipt directory, no card and no run commit for them anywhere in the tree.
 What can be established is a ceiling: the commit that introduced them pinned
-engine `629ddb6f0`, so they were measured at or before that pin. Three engine
+engine `629ddb6f0`, so they were measured at or before that pin. Five engine
 pin moves have landed since — `0d04db712` (2026-08-24), `26daaab7e`
-(2026-08-25) and `659962929` (2026-08-28). The **last** of the three is
-measured to change nothing: a four-arm byte A/B on one card found the old and
-new pins identical on the atmosphere half of the per-step fingerprint at all
-31 steps and on 0 of 138 history variables
-(`evidence/seam-258-ab-20260828/`) — one mesh, one case, one hour. The two
-earlier moves have no such arm, and none of the three magnitudes has been
-re-measured over 24 h since. Whether any of them moved is **NOT MEASURED**.
+(2026-08-25), `659962929` (2026-08-28), `7e34a48` (2026-08-31, gpuwm
+2.6.0) and `df5f34c5c` (2026-09-01, gpuwm 2.6.1). The **2.5.8** move is measured to change nothing: a four-arm byte A/B
+on one card found the old and new pins identical on the atmosphere half of
+the per-step fingerprint at all 31 steps and on 0 of 138 history variables
+(`evidence/seam-258-ab-20260828/`) — one mesh, one case, one hour. The
+**2.6.0** move also crosses the executed seam (`gpuwm/core/rrtmg_legacy.py`
+among its three moved files) and is measured the same way at the same
+scope: the x4 proof re-run at that pin wrote an F001 history byte-identical
+to the 2.5.8 proof's (`evidence/repin-260-20260831/x4-proof/`). The
+**2.6.1** move crosses it a third time, at its centre — the seam's own batch
+driver `gpuwm/core/mpas_column_batch.py` gains restart schema v2 and the P3
+eight-species transport — and is measured the same way at the same scope:
+the x4 proof re-run at that pin wrote all four snapshots (F000, F030, F001
+and the restarted F001) byte-identical to the 2.6.0 proof's, so one F001
+SHA-256 now spans three engines (`evidence/repin-261-20260901/x4-proof/`).
+The two earliest moves have no such arm, and none of the three magnitudes
+has been re-measured over 24 h since. Whether any of them moved is **NOT MEASURED**.
 Read them as the numbers from the pre-2026-08-20 engine, not as today's.
 
 1. **Upper-level warm drift.** Above level 45 the port warms relative to native
@@ -821,7 +834,8 @@ case-independent, which chaos cannot be, and each names a lane to fix.
 > `--cull-parent`, and `rw_mpas_lbc` was in no bundle and no published source
 > (measured 2026-08-27, `evidence/userwalk-20260827/RECEIPT.md` — that receipt
 > is a record of 2.5.7 and is not restated here as current fact). The engine
-> then published 2.5.8, which this distribution requires.
+> then published 2.5.8, which this distribution required until it re-pinned
+> onto 2.6.0 and then 2.6.1.
 >
 > Measured 2026-08-28 against the real published artefacts: `gpuwm
 > fetch-bridges` on a 2.5.8 install downloads

{gpuwm_hex-0.2.0 → gpuwm_hex-0.2.2}/docs/declared-divergences.md

@@ -56,11 +56,12 @@ is no receipt directory, no card and no run commit for them anywhere in the
 tree -- which is the opposite of how the obs-referee numbers below are
 recorded, and the gap is worth naming rather than papering over. What can be
 established is a ceiling: the commit that introduced them pinned engine
-`629ddb6f0`, so the run happened at or before that pin. Three engine pin moves
-have landed since -- `0d04db712` (2026-08-24), `26daaab7e` (2026-08-25) and
-`659962929` (2026-08-28, gpuwm 2.5.8).
+`629ddb6f0`, so the run happened at or before that pin. Five engine pin moves
+have landed since -- `0d04db712` (2026-08-24), `26daaab7e` (2026-08-25),
+`659962929` (2026-08-28, gpuwm 2.5.8), `7e34a48` (2026-08-31, gpuwm
+2.6.0) and `df5f34c5c` (2026-09-01, gpuwm 2.6.1).
 
-The last of those crosses the executed seam and **has now been measured**, in
+The 2.5.8 move crosses the executed seam and **has been measured**, in
 the strongest form available short of a re-run: a four-arm byte A/B on one
 RTX 5090, old pin against new pin, x4.163842, 30 composite steps, no tolerance
 anywhere. The atmosphere half of the per-step fingerprint is identical at all
@@ -71,10 +72,27 @@ digest rolled up over them
 That is one mesh, one case and one hour, and it is a byte comparison rather
 than a physics claim.
 
-The two EARLIER pin moves have no such arm, and no magnitude above has been
-re-measured over 24 h since the original run. **Whether any of the three moved
-across those pins is NOT MEASURED.** Read them as pre-2026-08-20 numbers until
-somebody re-runs them.
+The 2026-08-31 move crosses the executed seam too
+(`gpuwm/core/rrtmg_legacy.py` is one of its three moved files, and legacy
+RRTMG is the prime suspect for the drift below), and it carries its own
+one-hour byte arm: the x4 frozen-source proof re-run at that pin wrote an
+F001 history byte-identical to the 2.5.8 proof's -- one SHA-256, two
+engines (receipt `evidence/repin-260-20260831/x4-proof/`).  One mesh, one
+case, one hour, same caveat as above.
+
+The 2026-09-01 move crosses the executed seam a third time, and at its
+centre: `gpuwm/core/mpas_column_batch.py`, the seam's own batch driver,
+gains restart schema v2 and the P3 eight-species transport (the engine's
+default WSM6 path declared byte-unchanged), with `gpuwm/config.py` and
+`docs/mpas-seam.md` moving beside it.  Its arm is the same one-hour byte
+arm: the x4 proof re-run at that pin wrote all four snapshots -- F000,
+F030, F001 and the restarted F001 -- byte-identical to the 2.6.0 proof's,
+so one F001 SHA-256 now spans three engines (receipt
+`evidence/repin-261-20260901/x4-proof/`).  Same scope, same caveat.  The
+two EARLIEST pin moves have no arm at all, and no magnitude above has been
+re-measured over 24 h since the original run. **Whether any of the three moved across those pins is
+NOT MEASURED.** Read them as pre-2026-08-20 numbers until somebody re-runs
+them.
 
 ---
 

{gpuwm_hex-0.2.0 → gpuwm_hex-0.2.2}/docs/manual/02-quickstart.md

@@ -33,23 +33,24 @@ individual gpuwm source files by SHA-256. A bare install reached an engine the
 pin refused, and the forecast door refused at launch with a digest mismatch
 that named neither the version that works nor the fact that pip chose it.
 
-The declaration now carries a bounded range — `gpuwm>=2.5.8,<2.5.9` — so pip
+The declaration now carries a bounded range — `gpuwm>=2.6.1,<2.6.2` — so pip
 resolves the engine that works and refuses the one that does not. Three things
 follow that are worth knowing rather than discovering:
 
-- **2.5.8 is the only published engine that matches**, re-measured 2026-08-28
-  against every published 2.5.x release. So there is no fallback: the range is
-  one version wide because only one version qualifies.
+- **2.6.1 is the only published engine that matches**, re-measured 2026-09-01
+  against every published 2.5.x and 2.6.x release. So there is no fallback:
+  the range is one version wide because only one version qualifies.
 - **A newer gpuwm will not be resolved either.** The ceiling sits at the
   first engine this port has not measured against the manifest, so a future
-  2.5.9 is excluded exactly as 2.5.7 is. That is deliberate: an unmeasured
+  2.6.2 is excluded exactly as 2.6.0 is. That is deliberate: an unmeasured
   engine is what produced the defect.
 - **If you already have a different gpuwm in the environment**, `gpuwm-hex
   doctor` compares the installed engine's bytes against the pin and names
   both the version it found and the version to install. It is a byte check,
   not a version check, and it runs by default. On a conforming install it
-  reads `gpuwm 2.5.8: 16 of 16 pinned files are in this install and all 16
-  match`.
+  reads `gpuwm 2.6.1: 16 of 16 pinned files are in this install and all 16
+  match` (measured 2026-09-01 against the published 2.6.1 wheel, in a fresh
+  virtualenv holding only the published wheels).
 
 Then add the CUDA lane:
 
@@ -150,7 +151,7 @@ gpuwm you have: the transcript above was taken against the published gpuwm
 2.5.2 wheel, whose bundle carries `rw_wrfbatch` and **not** `rw_mpas_init`
 or `rw_mpas_convert` — which is exactly the shortfall the doctor reports
 there. The four MPAS bridge binaries enter the bundle at gpuwm 2.5.3, and
-this distribution's declared range is `gpuwm>=2.5.8,<2.5.9` (the floor is
+this distribution's declared range is `gpuwm>=2.6.1,<2.6.2` (the floor is
 far past 2.5.3, for the seam bytes the port pins): a conforming install cannot
 land on the engine that transcript was taken from. Doctor
 asks the gpuwm you actually have what its bundle declares, so it never sends
@@ -301,7 +302,7 @@ about a minute.
 The forecast lane is the one step whose answer depends on your hardware, so
 ask before you spend anything on it. **Both checkouts below are required and
 neither is optional**: `--repo` is your gpuwm-hex checkout (the drivers are
-not in the wheel) and `--gpuwm-checkout` is a gpuwm checkout at **`v2.5.8`**,
+not in the wheel) and `--gpuwm-checkout` is a gpuwm checkout at **`v2.6.1`**,
 the tag whose bytes the seam pin matches (2.1). Leave `--repo` off and the
 door refuses before it reads anything else.
 
@@ -315,7 +316,7 @@ gpuwm-hex forecast --preflight \
   --hours 1.0 --history-every-minutes 30 \
   --out work/fc-01 \
   --repo <gpuwm-hex-checkout>/tree \
-  --gpuwm-checkout <gpuwm-checkout-at-v2.5.8>
+  --gpuwm-checkout <gpuwm-checkout-at-v2.6.1>
 ```
 
 `--gpuwm-checkout` must be a **git clone**, not an unpacked release tarball
@@ -397,7 +398,7 @@ gpuwm-hex forecast \
   --hours 1.0 --history-every-minutes 30 \
   --out work/fc-01 \
   --repo <gpuwm-hex-checkout>/tree \
-  --gpuwm-checkout <gpuwm-checkout-at-v2.5.8> \
+  --gpuwm-checkout <gpuwm-checkout-at-v2.6.1> \
   --case-label quickstart
 ```
 

{gpuwm_hex-0.2.0 → gpuwm_hex-0.2.2}/docs/manual/04-meshes-and-static.md

@@ -113,7 +113,7 @@ icosahedral Goldberg grid at the resolution you ask for and builds the
 matching static in the same run, with no native toolchain anywhere in the
 loop. (This door was not present on the published gpuwm 2.5.2 wheel; it
 arrives with the 2.5.3 bundle, well below the floor this distribution's
-declared `gpuwm>=2.5.8,<2.5.9` range requires. The commands below were proven from a `gpuwm` checkout.)
+declared `gpuwm>=2.6.1,<2.6.2` range requires. The commands below were proven from a `gpuwm` checkout.)
 
 **See what a card can hold:**
 
@@ -199,6 +199,41 @@ fifth of a second:
 gpuwm-hex mesh-plan --spec my-case.json --card rtx-5070-ti
 ```
 
+#### Where that gradient is measured (changed 2026-08-29)
+
+The transition-band gate is arithmetic on one number, and until 2026-08-29
+the generator sampled that number on a lattice spread evenly over the whole
+globe. At the 50,000 points it used, those sit about 101 km apart, so a
+refinement transition narrower than that was stepped over entirely and the
+receipt reported the flat background the lattice happened to land on. On an
+eight-rung 51.2 km to 200 m ladder it printed 12.12 %/cell for a field that
+reads 37.04, and the build admitted a design its own gate exists to refuse.
+Nothing in the reading said so, because a maximum over points that missed the
+ramp looks exactly like a gentle ramp.
+
+The generator now probes where a spec says its regions are — a shell a few
+transition widths wide around each region boundary, resolved across the ramp
+rather than along it — and prints two more fields beside the number:
+`gradient_probe_points`, what the reading cost, and
+`gradient_probe_coverage`, which reads `complete` when every locus where the
+field varies was covered. `gpuwm-hex` refuses to judge a spec on a receipt
+that does not say `complete`, including a receipt from an older engine that
+does not say anything, because a number that is not a measurement is not
+something to gate on.
+
+Two consequences worth stating plainly. Specs with ramps hundreds of
+kilometres wide — every swath the threat metrics emit, and the two examples
+above — do not move: the old lattice already resolved them, and their
+readings shift in the fourth decimal. Specs with sub-kilometre cores and
+short ramps do move, sharply, and some designs that used to build now refuse
+before anything is seeded. That is the gate working, not a new restriction:
+the band was always that narrow.
+
+And what still is not measured this way: `predicted_cells` and
+`region_attainment` on the same receipt are still integrals over the global
+lattice, with the resolution limit that implies. Only the gradient follows
+the regions.
+
 It prices the spec through the generator's own sizing integral, applies the
 transition-band gate here (so a spec the build would refuse is refused
 before the build, with the ramp widening that clears it quoted in the spec's

{gpuwm_hex-0.2.0 → gpuwm_hex-0.2.2}/docs/manual/08-troubleshooting.md

@@ -193,8 +193,8 @@ from an install. What is missing is the commit — the run writes the
 checkout's HEAD, tree and dirty paths into every receipt so the executed seam
 source can be named — so clone the tag instead of copying the files.
 
-**`--gpuwm-checkout ... is gpuwm 2.5.7, and this port's physics seam is
-pinned to gpuwm 2.5.8`** — the checkout is a real gpuwm tree at the wrong
+**`--gpuwm-checkout ... is gpuwm 2.5.8, and this port's physics seam is
+pinned to gpuwm 2.6.1`** — the checkout is a real gpuwm tree at the wrong
 version. The refusal names both versions, lists which of the sixteen pinned
 files moved, and prints the two commands that close it: the bounded `pip
 install` and the `git clone --depth 1 --branch v<version>` for the checkout

{gpuwm_hex-0.2.0 → gpuwm_hex-0.2.2}/docs/manual/09-reference.md

@@ -147,12 +147,12 @@ by omission.
 - Distribution and command: `gpuwm-hex`. Import namespace: `hexcore`,
   renamed from `mpas_port` at 0.2.0 and settled there (README, *The import
   namespace*). There is no alias shim.
-- Engine range: `gpuwm>=2.5.8,<2.5.9` is what pip enforces — a bounded
+- Engine range: `gpuwm>=2.6.1,<2.6.2` is what pip enforces — a bounded
   range, derived from a measured table in `hexcore.engine_pin` rather than
   typed. The floor is where it is for one reason and it is the strictest
-  one: 2.5.8 is the only published engine whose bytes match the sixteen-file
-  Arwen seam manifest, re-measured 2026-08-28 against every published 2.5.x
-  release. It clears, incidentally, the bundle rows that put the MPAS bridge
+  one: 2.6.1 is the only published engine whose bytes match the sixteen-file
+  Arwen seam manifest, re-measured 2026-09-01 against every published 2.5.x
+  and 2.6.x release. It clears, incidentally, the bundle rows that put the MPAS bridge
   binaries (`rw_mpas_init`, `rw_mpas_convert`, `rw_mpas_mesh`,
   `rw_mpas_static`, `rw_mpas_lbc`) within reach of `gpuwm fetch-bridges`;
   published 2.5.2 carries none of them and would strand every door that
@@ -162,7 +162,7 @@ by omission.
   forecast lane's real wall is stricter still: the sixteen-file seam
   manifest, plus a *git* checkout at the pinned commit for receipt
   provenance (chapter 6.1). `gpuwm-hex doctor` compares the installed
-  engine's bytes against the manifest and names the version it found; at
+  engine's bytes against the manifest and names the version it found; since
   2.5.8 all sixteen pinned paths resolve from the install, so the checkout
   is owed for the commit rather than for a file.
 - Licence: Apache-2.0, with the MPAS-Atmosphere BSD-3-Clause notice

{gpuwm_hex-0.2.0 → gpuwm_hex-0.2.2}/docs/manual/index.md

@@ -43,14 +43,14 @@ independent port and is not affiliated with or endorsed by them.)*
 
 **Every command was run before it was printed.** Each command block in this
 manual was executed against the real artifact it documents — the installed
-0.2.0 wheel for the doors, the repository tools for the forecast lane, a CUDA
+0.2.1 wheel for the doors, the repository tools for the forecast lane, a CUDA
 node for anything that needs a card — before it was written down. Where a
 command's output is shown, it is the output that run produced, with machine
 home directories shortened to `~`.
 
 **What a walk of this manual actually reaches.** On 2026-08-27 the printed
 commands were executed in printed order, from an empty environment, against
-the built 0.2.0 wheel and the *published* engine, by somebody following the
+the built 0.2.1 wheel and the *published* engine, by somebody following the
 page rather than remembering the code. Install, `doctor`, `mesh-check`, the
 init door, the forecast door and the render door all reach real output —
 16 min 46 s from an empty machine to the first rendered products. Three
@@ -60,7 +60,7 @@ re-measured 2026-08-28 against the published bundle: the **limited-area lane**
 of chapter 6.8 and the `cull` door of chapter 9 have the engine capabilities
 they need, and the render door's **default window** is understood by the
 published converter. The third stands, with a narrower reason than it had: the forecast lane needs
-a `gpuwm` **git** checkout at **v2.5.8**, not just whatever pip installs — not
+a `gpuwm` **git** checkout at **v2.6.1**, not just whatever pip installs — not
 because a pinned file is missing from the wheel (at 2.5.8 all sixteen resolve
 from `site-packages`, measured 2026-08-28) but because the run records the
 checkout's HEAD, tree and dirty paths into every receipt. Each is written
@@ -77,7 +77,7 @@ three measured, physics-shaped ways. They are stated in chapter 3, quantified
 in [`docs/declared-divergences.md`](../declared-divergences.md), and never
 hidden behind an option. Read them before trusting a number.
 
-**Version.** This manual describes gpuwm-hex 0.2.0 with the gpuwm 2.5.x
+**Version.** This manual describes gpuwm-hex 0.2.2 with the gpuwm 2.6.x
 engine line. Where a measurement was taken on specific hardware, the card is
 named beside the number.