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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: gpuwm-hex
-Version: 0.2.2
+Version: 0.2.3
 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.6.2,>=2.6.1
+Requires-Dist: gpuwm<2.6.6,>=2.6.4
 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.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*. |
+| Engine | The `gpuwm` distribution, `>=2.6.4,<2.6.6` — 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.4` 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,44 +242,56 @@ unchanged.
 
 ### The engine pin
 
-gpuwm-hex depends on `gpuwm>=2.6.1,<2.6.2` — a **bounded range**, and the
+gpuwm-hex depends on `gpuwm>=2.6.4,<2.6.6` — 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-09-01
+stamp and the pinned bytes has recurred at every cut. Re-measured 2026-09-02
 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
+`v2.5.5` and `v2.6.2` tags that have no release at all — JSON at
+`evidence/repin-265-20260902/engine-verdicts.json`, instrument at
 `evidence/standalone-20260827/measure_engine_verdicts.py`:
 
 | gpuwm | on PyPI | seam pin | `--offline` build road |
 | --- | --- | --- | --- |
 | 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.
+| 2.5.2 | yes | 11 of 16 moved | complete |
+| 2.5.3 | yes | 10 of 16 moved | complete |
+| 2.5.4 | yes | 10 of 16 moved | complete |
+| 2.5.5 | **no — a git tag with no release** | 10 of 16 moved | **broken** |
+| 2.5.6 | yes | 10 of 16 moved | complete |
+| 2.5.7 | yes | 9 of 16 moved | complete |
+| 2.5.8 | yes | 9 of 16 moved | complete |
+| 2.6.0 | yes | 8 of 16 moved | complete |
+| 2.6.1 | yes | 8 of 16 moved | complete |
+| 2.6.2 | **no — a git tag with no release** | 6 of 16 moved | complete |
+| 2.6.3 | yes | 6 of 16 moved | complete |
+| **2.6.4** | yes | **matches** | complete |
+| **2.6.5** | yes | **matches** | complete |
+
+**2.6.4 and 2.6.5 are the only published engines whose bytes match the pin,
+and they match it with the same bytes**: all sixteen pinned files are
+byte-identical between the two published wheels
+(`evidence/repin-265-20260902/wheel-pair-264-265.txt`), so 2.6.4 is the
+floor, 2.6.5 is admitted, and the exclusive ceiling sits one patch above it at
+2.6.6. 2.6.3, published three hours before 2.6.4 and the floor that morning,
+fails it by 6 files; 2.6.2 fails by the same 6 and its publish job died
+besides, so nothing of it reached PyPI — a floor pip cannot install is not a
+floor, the same finding 2.5.5 forced.
 
 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.6.0 read `matches`
-under the previous manifest and reads `3 of 16 moved` under this one. A row
+once, including rows for engines cut long before it: 2.6.3 read `matches`
+under the previous manifest and reads `6 of 16 moved` under this one, and
+2.6.1, which read `3 of 16 moved` under the previous manifest, reads
+`8 of 16 moved` now. 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.6.1 were withdrawn, the answer would be to publish a
-new engine and re-measure, not to widen the range.
+The consequence is worth stating rather than discovering: **the two admitted
+engines are the whole fallback.** If both 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
 true and are now beside the point, because 2.5.5 fails the re-pinned manifest
@@ -299,7 +311,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.6.2 is excluded exactly as 2.6.0 is today. Admitting a
+> usable, so a future 2.6.6 is excluded exactly as 2.6.3 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
@@ -326,15 +338,17 @@ 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.6.1` with the full tree, `docs/mpas-seam.md`
+carries tags `v2.5.0` through `v2.6.5` with the full tree, `docs/mpas-seam.md`
 and `gpuwm/core/mpas_column_batch.py` included. The table above was taken by
-hashing the pinned files at all eleven of those tags, so the build road below
+hashing the pinned files at every one 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.6.1`. This is stated
+in addition to the installed distribution. Clone `v2.6.4` (the floor, and
+the tag every card proof of record was taken at; `v2.6.5` carries the same
+sixteen pinned files byte for byte). 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`.
@@ -472,7 +486,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.6.1,<2.6.2` range keeps that
+enter the bundle, and the current `gpuwm>=2.6.4,<2.6.6` 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.
@@ -797,10 +811,11 @@ 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. Five engine
+engine `629ddb6f0`, so they were measured at or before that pin. Seven engine
 pin moves have landed since — `0d04db712` (2026-08-24), `26daaab7e`
 (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
+`2.6.0`), `df5f34c5c` (2026-09-01, gpuwm 2.6.1), `636ab1b4b`
+(2026-09-02, gpuwm 2.6.3) and `d60b883e7` (2026-09-02, gpuwm 2.6.4). 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
@@ -814,6 +829,26 @@ 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 **2.6.3** move touches the same batch driver (the aerosol-aware Thompson
+species row) plus a config-relative file key off the physics path; its
+one-hour byte arm was not run separately: the 2.6.4 arm below, taken
+ninety minutes after that pin was superseded, covers it by inclusion
+(`evidence/repin-263-20260902/x4-proof/SKIPPED.md`). The
+**2.6.4** move crosses the executed seam more widely than any since 2.5.8:
+six of the sixteen pinned files moved between the two published wheels,
+among them the phase-one driver `gpuwm/core/physics.py` (the cumulus adapter
+contract grew for a third cumulus scheme), the Grell-Freitas adapter
+`gpuwm/core/gf.py` and its kernel source `gpuwm/core/kernels/gf.cu` (the
+glibc float32 words moved into a header the loader prepends), the kernel
+loader, the config loader and the restart identity table; the column batch
+and the contract document did not move. Its one-hour byte arm is the x4
+frozen-source proof re-run at the 2.6.4 pins
+(`evidence/repin-264-20260902/x4-proof/`): all four snapshots (F000, F030,
+F001 and the restarted F001) byte-identical to the 2.6.1 proof's, so one
+F001 SHA-256 now spans 2.5.8, 2.6.0, 2.6.1 and 2.6.4. The published
+**2.6.5** moved none of the sixteen pinned files
+(`evidence/repin-265-20260902/wheel-pair-264-265.txt`), so it is admitted
+by the range without a pin move and the 2.6.4 arm covers it.
 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.

{gpuwm_hex-0.2.2 → gpuwm_hex-0.2.3}/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.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*. |
+| Engine | The `gpuwm` distribution, `>=2.6.4,<2.6.6` — 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.4` 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,44 +204,56 @@ unchanged.
 
 ### The engine pin
 
-gpuwm-hex depends on `gpuwm>=2.6.1,<2.6.2` — a **bounded range**, and the
+gpuwm-hex depends on `gpuwm>=2.6.4,<2.6.6` — 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-09-01
+stamp and the pinned bytes has recurred at every cut. Re-measured 2026-09-02
 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
+`v2.5.5` and `v2.6.2` tags that have no release at all — JSON at
+`evidence/repin-265-20260902/engine-verdicts.json`, instrument at
 `evidence/standalone-20260827/measure_engine_verdicts.py`:
 
 | gpuwm | on PyPI | seam pin | `--offline` build road |
 | --- | --- | --- | --- |
 | 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.
+| 2.5.2 | yes | 11 of 16 moved | complete |
+| 2.5.3 | yes | 10 of 16 moved | complete |
+| 2.5.4 | yes | 10 of 16 moved | complete |
+| 2.5.5 | **no — a git tag with no release** | 10 of 16 moved | **broken** |
+| 2.5.6 | yes | 10 of 16 moved | complete |
+| 2.5.7 | yes | 9 of 16 moved | complete |
+| 2.5.8 | yes | 9 of 16 moved | complete |
+| 2.6.0 | yes | 8 of 16 moved | complete |
+| 2.6.1 | yes | 8 of 16 moved | complete |
+| 2.6.2 | **no — a git tag with no release** | 6 of 16 moved | complete |
+| 2.6.3 | yes | 6 of 16 moved | complete |
+| **2.6.4** | yes | **matches** | complete |
+| **2.6.5** | yes | **matches** | complete |
+
+**2.6.4 and 2.6.5 are the only published engines whose bytes match the pin,
+and they match it with the same bytes**: all sixteen pinned files are
+byte-identical between the two published wheels
+(`evidence/repin-265-20260902/wheel-pair-264-265.txt`), so 2.6.4 is the
+floor, 2.6.5 is admitted, and the exclusive ceiling sits one patch above it at
+2.6.6. 2.6.3, published three hours before 2.6.4 and the floor that morning,
+fails it by 6 files; 2.6.2 fails by the same 6 and its publish job died
+besides, so nothing of it reached PyPI — a floor pip cannot install is not a
+floor, the same finding 2.5.5 forced.
 
 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.6.0 read `matches`
-under the previous manifest and reads `3 of 16 moved` under this one. A row
+once, including rows for engines cut long before it: 2.6.3 read `matches`
+under the previous manifest and reads `6 of 16 moved` under this one, and
+2.6.1, which read `3 of 16 moved` under the previous manifest, reads
+`8 of 16 moved` now. 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.6.1 were withdrawn, the answer would be to publish a
-new engine and re-measure, not to widen the range.
+The consequence is worth stating rather than discovering: **the two admitted
+engines are the whole fallback.** If both 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
 true and are now beside the point, because 2.5.5 fails the re-pinned manifest
@@ -261,7 +273,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.6.2 is excluded exactly as 2.6.0 is today. Admitting a
+> usable, so a future 2.6.6 is excluded exactly as 2.6.3 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
@@ -288,15 +300,17 @@ 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.6.1` with the full tree, `docs/mpas-seam.md`
+carries tags `v2.5.0` through `v2.6.5` with the full tree, `docs/mpas-seam.md`
 and `gpuwm/core/mpas_column_batch.py` included. The table above was taken by
-hashing the pinned files at all eleven of those tags, so the build road below
+hashing the pinned files at every one 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.6.1`. This is stated
+in addition to the installed distribution. Clone `v2.6.4` (the floor, and
+the tag every card proof of record was taken at; `v2.6.5` carries the same
+sixteen pinned files byte for byte). 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`.
@@ -434,7 +448,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.6.1,<2.6.2` range keeps that
+enter the bundle, and the current `gpuwm>=2.6.4,<2.6.6` 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.
@@ -759,10 +773,11 @@ 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. Five engine
+engine `629ddb6f0`, so they were measured at or before that pin. Seven engine
 pin moves have landed since — `0d04db712` (2026-08-24), `26daaab7e`
 (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
+`2.6.0`), `df5f34c5c` (2026-09-01, gpuwm 2.6.1), `636ab1b4b`
+(2026-09-02, gpuwm 2.6.3) and `d60b883e7` (2026-09-02, gpuwm 2.6.4). 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
@@ -776,6 +791,26 @@ 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 **2.6.3** move touches the same batch driver (the aerosol-aware Thompson
+species row) plus a config-relative file key off the physics path; its
+one-hour byte arm was not run separately: the 2.6.4 arm below, taken
+ninety minutes after that pin was superseded, covers it by inclusion
+(`evidence/repin-263-20260902/x4-proof/SKIPPED.md`). The
+**2.6.4** move crosses the executed seam more widely than any since 2.5.8:
+six of the sixteen pinned files moved between the two published wheels,
+among them the phase-one driver `gpuwm/core/physics.py` (the cumulus adapter
+contract grew for a third cumulus scheme), the Grell-Freitas adapter
+`gpuwm/core/gf.py` and its kernel source `gpuwm/core/kernels/gf.cu` (the
+glibc float32 words moved into a header the loader prepends), the kernel
+loader, the config loader and the restart identity table; the column batch
+and the contract document did not move. Its one-hour byte arm is the x4
+frozen-source proof re-run at the 2.6.4 pins
+(`evidence/repin-264-20260902/x4-proof/`): all four snapshots (F000, F030,
+F001 and the restarted F001) byte-identical to the 2.6.1 proof's, so one
+F001 SHA-256 now spans 2.5.8, 2.6.0, 2.6.1 and 2.6.4. The published
+**2.6.5** moved none of the sixteen pinned files
+(`evidence/repin-265-20260902/wheel-pair-264-265.txt`), so it is admitted
+by the range without a pin move and the 2.6.4 arm covers it.
 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.

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

@@ -56,10 +56,11 @@ 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. Five engine pin moves
+`629ddb6f0`, so the run happened at or before that pin. Seven 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).
+2.6.0), `df5f34c5c` (2026-09-01, gpuwm 2.6.1), `636ab1b4b`
+(2026-09-02, gpuwm 2.6.3) and `d60b883e7` (2026-09-02, gpuwm 2.6.4).
 
 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
@@ -80,6 +81,42 @@ 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 (gpuwm 2.6.1) and the 2026-09-02 move (gpuwm 2.6.3)
+both cross the executed seam at its centre -- the seam's own batch driver
+`gpuwm/core/mpas_column_batch.py` gains restart schema v2 and the P3
+transport at 2.6.1, and the aerosol-aware Thompson species row at 2.6.3 --
+and each carries its own one-hour byte arm.  The 2.6.1 x4 proof wrote all
+four snapshots byte-identical to the 2.6.0 proof's
+(`../evidence/repin-261-20260901/x4-proof/`); the 2.6.3 move's arm was not
+run separately, because the 2.6.4 arm below covers it by inclusion
+(`../evidence/repin-263-20260902/x4-proof/SKIPPED.md`).  One mesh, one case,
+one hour, same caveat.
+
+The 2026-09-02 move to gpuwm 2.6.4, three hours after the 2.6.3 one,
+crosses the executed seam more widely than any move since 2.5.8: six of
+the sixteen pinned files moved between the two published wheels, measured
+wheel against wheel (`../evidence/repin-264-20260902/wheel-pair-263-264.txt`)
+-- the phase-one driver `gpuwm/core/physics.py` (the cumulus adapter
+contract grew a result type and a column-tendency coupler for a third
+cumulus scheme), the Grell-Freitas adapter `gpuwm/core/gf.py` (a
+`release()` that breaks the driver/adapter reference cycle) and its kernel
+source `gpuwm/core/kernels/gf.cu` (the glibc float32 words moved into a
+header the loader prepends; the loader's own comment states the seven GF
+entry points kept byte-identical resource counts and the GF parity suites
+still grade at max_ulp 0), the kernel loader, the config loader and the
+restart identity table.  The column batch and the contract document did
+not move.  Its one-hour byte arm is the x4 frozen-source proof re-run at
+the 2.6.4 pins (`../evidence/repin-264-20260902/x4-proof/`): all four
+snapshots (F000, F030, F001 and the restarted F001) byte-identical to the
+2.6.1 proof's, so one F001 SHA-256 now spans 2.5.8, 2.6.0, 2.6.1 and 2.6.4,
+and the GF lift is measured byte-neutral THROUGH THIS SEAM at that scope.
+One mesh, one case, one hour, same caveat.
+
+The published 2.6.5 (2026-09-02, ninety minutes after 2.6.4) moved none of
+the sixteen pinned files, measured wheel against wheel
+(`../evidence/repin-265-20260902/wheel-pair-264-265.txt`), so it is
+admitted by the range without a pin move and the 2.6.4 arm covers it.
+
 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

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

@@ -33,23 +33,26 @@ 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.6.1,<2.6.2` — so pip
+The declaration now carries a bounded range — `gpuwm>=2.6.4,<2.6.6` — 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.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.
+- **2.6.4 and 2.6.5 are the only published engines that match**, re-measured
+  2026-09-02 against every published 2.5.x and 2.6.x release, and they carry
+  the same sixteen pinned files byte for byte. The range is two versions
+  wide because two versions qualify. (2.6.3, published three hours before
+  2.6.4, fails the pin by six files; 2.6.2 fails by the same six and never
+  reached PyPI at all.)
 - **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.6.2 is excluded exactly as 2.6.0 is. That is deliberate: an unmeasured
+  2.6.6 is excluded exactly as 2.6.3 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.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
+  reads `gpuwm 2.6.4: 16 of 16 pinned files are in this install and all 16
+  match` (measured 2026-09-02 against the published 2.6.4 wheel, in a fresh
   virtualenv holding only the published wheels).
 
 Then add the CUDA lane:
@@ -151,7 +154,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.6.1,<2.6.2` (the floor is
+this distribution's declared range is `gpuwm>=2.6.4,<2.6.6` (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
@@ -302,7 +305,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.6.1`**,
+not in the wheel) and `--gpuwm-checkout` is a gpuwm checkout at **`v2.6.4`**,
 the tag whose bytes the seam pin matches (2.1). Leave `--repo` off and the
 door refuses before it reads anything else.
 
@@ -316,7 +319,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.6.1>
+  --gpuwm-checkout <gpuwm-checkout-at-v2.6.4>
 ```
 
 `--gpuwm-checkout` must be a **git clone**, not an unpacked release tarball
@@ -398,7 +401,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.6.1> \
+  --gpuwm-checkout <gpuwm-checkout-at-v2.6.4> \
   --case-label quickstart
 ```
 

{gpuwm_hex-0.2.2 → gpuwm_hex-0.2.3}/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.6.1,<2.6.2` range requires. The commands below were proven from a `gpuwm` checkout.)
+declared `gpuwm>=2.6.4,<2.6.6` range requires. The commands below were proven from a `gpuwm` checkout.)
 
 **See what a card can hold:**
 

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

@@ -194,7 +194,7 @@ 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.8, and this port's physics seam is
-pinned to gpuwm 2.6.1`** — the checkout is a real gpuwm tree at the wrong
+pinned to gpuwm 2.6.4`** — 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.2 → gpuwm_hex-0.2.3}/docs/manual/09-reference.md

@@ -147,12 +147,13 @@ 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.6.1,<2.6.2` is what pip enforces — a bounded
+- Engine range: `gpuwm>=2.6.4,<2.6.6` 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.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
+  one: 2.6.4 and 2.6.5 are the only published engines whose bytes match the
+  sixteen-file Arwen seam manifest (byte-identical to each other on every
+  pinned path), re-measured 2026-09-02 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

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

@@ -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.6.1**, not just whatever pip installs — not
+a `gpuwm` **git** checkout at **v2.6.4**, 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.2 with the gpuwm 2.6.x
+**Version.** This manual describes gpuwm-hex 0.2.3 with the gpuwm 2.6.x
 engine line. Where a measurement was taken on specific hardware, the card is
 named beside the number.
 

{gpuwm_hex-0.2.2 → gpuwm_hex-0.2.3}/pyproject.toml

@@ -38,7 +38,7 @@ name = "gpuwm-hex"
 # partition-invariant, but it has no door, no demo, and no re-proof at the
 # current engine pin, so it is not what a version number should be sold on.
 # Numbers are not reserved here any more.  A minor bump names what shipped.
-version = "0.2.2"
+version = "0.2.3"
 description = "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."
 readme = "README.md"
 requires-python = ">=3.11"
@@ -103,17 +103,27 @@ license-files = ["LICENSE", "NOTICE"]
 # 16" survived here even in the edit that called it out.  Read the counts off
 # `engine_pin.PUBLISHED_ENGINES`, which is machine-written.
 #
-# THE FLOOR IS 2.6.1 AND IT IS THE ONLY USABLE ENGINE (re-measured
-# 2026-09-01, evidence/repin-261-20260901/).  The engine published 2.6.1 and
-# this port re-pinned its manifest to that cut's bytes; because the `moved`
-# column is measured AGAINST the manifest, re-pinning moved every row, and
-# every engine from 2.5.0 to 2.6.0 now fails it -- including the 2.6.0 that
-# was this floor the day before (three files moved at the 2.6.1 cut:
-# gpuwm/core/mpas_column_batch.py, gpuwm/config.py, docs/mpas-seam.md).
-# There is no fallback engine and no wider range to fall back to: if 2.6.1
-# were yanked, `engine_pin` raises EnginePinError rather than loosening the
-# bound, because widening it means measuring something that passes and
-# nothing published does.
+# THE FLOOR IS 2.6.4 AND THE RANGE ADMITS 2.6.5 (re-measured 2026-09-02,
+# evidence/repin-265-20260902/, after the same day's re-pin to 2.6.4,
+# evidence/repin-264-20260902/).  The engine published 2.6.4 and this port
+# re-pinned its manifest to that cut's bytes; because the `moved` column is
+# measured AGAINST the manifest, re-pinning moved every row, and every
+# engine from 2.5.0 to 2.6.3 fails it -- including the 2.6.3 that was this
+# floor the same morning (six files moved at the 2.6.4 cut:
+# gpuwm/core/physics.py, gpuwm/core/gf.py, gpuwm/core/kernels/gf.cu,
+# gpuwm/core/kernels/__init__.py, gpuwm/config.py, gpuwm/io/restart.py; the
+# column batch and the contract document did not).  2.6.2, the tag whose
+# publish job died, fails on bytes as well, so the 2.5.5-shaped finding it
+# carried no longer reaches the floor.  The engine then published 2.6.5
+# ninety minutes after 2.6.4 (a soil-archive layout fix for doctor, the mesh
+# door and the static builder, off the physics path), and all sixteen
+# manifest files are byte-identical between the two published wheels, so the
+# manifest did NOT move: 2.6.4 stays the floor, 2.6.5 is measured usable,
+# and the ceiling sits at 2.6.6, the first engine nobody has measured.  The
+# range is two versions wide because two versions carry the pinned bytes,
+# and for no other reason: if both were yanked, `engine_pin` raises
+# EnginePinError rather than loosening the bound, because widening it means
+# measuring something that passes.
 #
 # Two earlier findings are kept in the table and no longer reach the floor,
 # since 2.5.5 and 2.5.6 now fail on bytes before either applies: 2.5.5 is a
@@ -154,7 +164,7 @@ dependencies = [
     "numpy>=2.0",
     "netCDF4>=1.6",
     "scipy>=1.11",
-    "gpuwm>=2.6.1,<2.6.2",
+    "gpuwm>=2.6.4,<2.6.6",
 ]
 # Search terms, which is what a keyword is: the words somebody types into
 # PyPI when they are looking for this kind of thing.  `MPAS` is here as a