gpuwm-hex 0.3.2__tar.gz → 0.3.3__tar.gz

{gpuwm_hex-0.3.2/src/gpuwm_hex.egg-info → gpuwm_hex-0.3.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: gpuwm-hex
-Version: 0.3.2
+Version: 0.3.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
@@ -177,7 +177,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 per-allocation ledger can still supply it with `--device-fixed-mib` / `--device-bytes-per-cell`. |
+| GPU | A CUDA device: any NVIDIA card of compute capability 7.5 (Turing) or newer runs, on CUDA 13, with no flag. sm_86 and sm_89 are anchored (the numerical contract measured again on that architecture), sm_120 is the proven contract floor where it was first measured, and any other card runs unanchored and its receipt says so; `gpuwm-hex doctor` names your card and its status. 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 per-allocation ledger can still supply it with `--device-fixed-mib` / `--device-bytes-per-cell`. |
 | 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.8.0,<2.8.1`, a bounded range, and pip resolves it for you: the physics seam, and the bundle that carries the MPAS bridge binaries the doors drive. The forecast runs on the installed engine; a git clone at `v2.8.0` is optional (receipts then name its commit) — 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*. |

{gpuwm_hex-0.3.2 → gpuwm_hex-0.3.3}/README.md

@@ -139,7 +139,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 per-allocation ledger can still supply it with `--device-fixed-mib` / `--device-bytes-per-cell`. |
+| GPU | A CUDA device: any NVIDIA card of compute capability 7.5 (Turing) or newer runs, on CUDA 13, with no flag. sm_86 and sm_89 are anchored (the numerical contract measured again on that architecture), sm_120 is the proven contract floor where it was first measured, and any other card runs unanchored and its receipt says so; `gpuwm-hex doctor` names your card and its status. 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 per-allocation ledger can still supply it with `--device-fixed-mib` / `--device-bytes-per-cell`. |
 | 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.8.0,<2.8.1`, a bounded range, and pip resolves it for you: the physics seam, and the bundle that carries the MPAS bridge binaries the doors drive. The forecast runs on the installed engine; a git clone at `v2.8.0` is optional (receipts then name its commit) — 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*. |

{gpuwm_hex-0.3.2 → gpuwm_hex-0.3.3}/docs/hex-point-hrrr.md

@@ -129,8 +129,11 @@ Fifty hybrid levels are carried as level-indexed slabs with the 3-D
 `PRESSURE` beside them (the init engine's model-level branch, the ERA5-ML
 convention), plus the 200100.0 surface level, so `--nfglevels 51
 --nfgsoillevels 4 --use-spechumd yes --extrap-airtemp constant`. Hydrometeors
-are not carried: the init stream has no slot for them, and hour zero has no
-ice (README, limited-area lane).
+are not carried, although the engine's window decodes them: the init stream
+has slots for cloud water and rain (`qc`, `qr`), but the init and boundary
+writers read no hydrometeor record from an intermediate file and write both
+as zero, and it has no slot for cloud ice, snow or graupel, so hour zero has
+no ice (README, limited-area lane).
 
 The source is a ROW (`hexcore.hrrr_intermediate.SOURCE_ROWS`): decoder key,
 loader module, file names, field map, soil nodes, level count. Nothing below

{gpuwm_hex-0.3.2 → gpuwm_hex-0.3.3}/docs/manual/02-quickstart.md

@@ -329,14 +329,15 @@ version and `RECORD` digest.
 
 On a card that holds the mesh, preflight binds it, admits it, runs the
 driver's own source-pin and host checks, and exits 0. This transcript is
-from a 10 GiB RTX 3080 with a desktop session on it, run 2026-08-25; the `ADMISSION` line is the
-one the door prints for that card and that free reading today:
+from a 10 GiB RTX 3080 with a desktop session on it, run 2026-08-25; the `ADMISSION` and
+`ARCHITECTURE` lines are the ones the door prints for that card and that
+free reading today:
 
 ```
 [mesh-binding] bound x1.40962: nCells=40962, nEdges=122880, dx=120000.0 m, dt=120.0 s
 BIND mesh=x1.40962 rebound=True dt=120.0 s
 ADMISSION mesh=x1.40962 cells=40,962 card=68 SM row=measured global predicted=5,682.0 MiB margin=884.0 MiB free=9,097.0 MiB of 10,239.5 MiB -> admitted
-ARCHITECTURE sm=sm_86 -> admitted (per-architecture anchor of 2026-08-25 (evidence/sm86-tier-20260825/RECEIPT.md))
+ARCHITECTURE sm=sm_86 -> admitted, anchored: the 2026-08-25 anchor (evidence/sm86-tier-20260825/RECEIPT.md, evidence pin 75437c663c9894dc...)
 PREFLIGHT mesh=x1.40962 problems=0 status=preflight_passed
 ```
 

{gpuwm_hex-0.3.2 → gpuwm_hex-0.3.3}/docs/manual/06-forecast.md

@@ -170,20 +170,47 @@ what the door selected. `--headroom-mib` overrides the margin the same
 way; its default is no longer a flat 512 MiB but the model's own two named
 terms, priced from your card.
 
-**Architecture is admission too, and it is a registry rather than one
-number.** The port's numerical contract was proven on sm_120, so an
-architecture below that floor runs only if it holds its own anchor — a
-measured contract receipt and a frozen-authority anchor taken on real
-hardware of that architecture
+**Architecture is admission too, and every NVIDIA architecture NVRTC can
+compile the kernels for is admitted, with no flag.** The kernels are
+compiled by NVRTC for your card when the run starts, and they ask for
+nothing an older card lacks, so the floor is the CUDA 13 toolkit's:
+compute capability 7.5 (Turing) and newer. A card NVRTC cannot compile for
+is refused by name, because no kernel could be built for it. The one other
+architecture refusal is the IEEE check below, on an unanchored card, when
+ordinary arithmetic is not IEEE; nothing else about the architecture
+refuses a run.
+
+What differs between architectures is the evidence behind the numbers. The
+port's numerical contract was first measured on sm_120; an architecture
+holds an **anchor** when the same contract has been measured again on real
+hardware of it, a contract receipt and a frozen-authority anchor, each row
+pinned to its evidence by SHA-256
 (`src/hexcore/cuda_backend/arch_admission.py`). **sm_86 holds one**
-(2026-08-25, a 10 GiB RTX 3080), which is
-why the quickstart's preflight prints `ARCHITECTURE sm=sm_86 -> admitted`
-and why a full-physics limited-area forecast runs on that card (6.8). An
-architecture holding no anchor is refused by name before a single
-allocation, with the roster of the ones that do. `--preflight` answers this
-half from a device-properties read rather than from the driver's CUDA
-import, so it can no longer say `preflight_passed` about a card the run
-then refuses by architecture.
+(2026-08-25, a 10 GiB RTX 3080) and **sm_89 holds one** (2026-09-24, an
+RTX 4090, so the RTX 40 series and the L40S), each with the guard-cost
+ceiling measured on its card (1.75 and 1.55). The preflight prints one line
+saying which it is, with the evidence pin of an anchored row:
+
+```
+ARCHITECTURE sm=sm_89 -> admitted, anchored: the 2026-09-24 anchor (evidence/sm89-tier-20260924/RECEIPT.md, evidence pin 15357eb4d576853f...)
+```
+
+On a card of any other architecture the line reads `admitted, unanchored`,
+and before the run the door measures the numeric route on that card in one
+tiny compile and launch: what the route does with an FP32 subnormal, what
+the port's guarded fallback returns for it, whether `--fmad=false` keeps
+`a*b+c` separately rounded, and whether ordinary FP32 and FP64 arithmetic
+agree with IEEE 754. The line ends with what it found. Only the last check
+refuses, because on such a card every number the run produced would be
+wrong; the others are recorded. Every receipt (the door's, the driver's and
+the proof harness's) records the compute capability and either `anchored`
+or `unanchored`. An anchored row carries its evidence pin; sm_120, the
+proven contract floor where the contract was first measured, is anchored
+and carries no pin. No receipt claims an anchor its architecture does not
+hold, and `gpuwm-hex doctor` names the card, its compute capability and
+the same status before you run. `--preflight` answers this half from a
+device-properties read and NVRTC's own target list, so it and the run
+agree about the architecture.
 
 **`--preflight` answers the whole question.** It runs every check —
 inputs, the mesh bind, the admission decision, and the driver's own
@@ -197,7 +224,7 @@ question is the one no file fixes:
 INPUT MISSING --init names a missing file: .../x1.40962.init.nc.  Build one with `gpuwm-hex init` (chapter 5 of the manual).
 BIND mesh=x1.40962 rebound=True dt=120.0 s
 ADMISSION mesh=x1.40962 cells=40,962 card=68 SM row=measured global predicted=5,682.0 MiB margin=884.0 MiB free=9,097.0 MiB of 10,239.5 MiB -> admitted
-ARCHITECTURE sm=sm_86 -> admitted (per-architecture anchor of 2026-08-25 (evidence/sm86-tier-20260825/RECEIPT.md))
+ARCHITECTURE sm=sm_86 -> admitted, anchored: the 2026-08-25 anchor (evidence/sm86-tier-20260825/RECEIPT.md, evidence pin 75437c663c9894dc...)
 PREFLIGHT mesh=x1.40962 problems=1 status=preflight_refused
 ```
 

{gpuwm_hex-0.3.2 → gpuwm_hex-0.3.3}/docs/manual/index.md

@@ -74,7 +74,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.3.2 with the gpuwm 2.8.0
+**Version.** This manual describes gpuwm-hex 0.3.3 with the gpuwm 2.8.0
 engine. Where a measurement was taken on specific hardware, the card is
 named beside the number.
 

{gpuwm_hex-0.3.2 → gpuwm_hex-0.3.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.3.2"
+version = "0.3.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"

{gpuwm_hex-0.3.2 → gpuwm_hex-0.3.3/src/gpuwm_hex.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: gpuwm-hex
-Version: 0.3.2
+Version: 0.3.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
@@ -177,7 +177,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 per-allocation ledger can still supply it with `--device-fixed-mib` / `--device-bytes-per-cell`. |
+| GPU | A CUDA device: any NVIDIA card of compute capability 7.5 (Turing) or newer runs, on CUDA 13, with no flag. sm_86 and sm_89 are anchored (the numerical contract measured again on that architecture), sm_120 is the proven contract floor where it was first measured, and any other card runs unanchored and its receipt says so; `gpuwm-hex doctor` names your card and its status. 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 per-allocation ledger can still supply it with `--device-fixed-mib` / `--device-bytes-per-cell`. |
 | 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.8.0,<2.8.1`, a bounded range, and pip resolves it for you: the physics seam, and the bundle that carries the MPAS bridge binaries the doors drive. The forecast runs on the installed engine; a git clone at `v2.8.0` is optional (receipts then name its commit) — 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*. |

{gpuwm_hex-0.3.2 → gpuwm_hex-0.3.3}/src/gpuwm_hex.egg-info/SOURCES.txt

@@ -175,6 +175,7 @@ src/hexcore/swath/rank.py
 src/hexcore/swath/registry.py
 src/hexcore/swath/sizing.py
 src/hexcore/swath/track.py
+tests/_layout.py
 tests/conftest.py
 tests/test_admission_strings.py
 tests/test_arch_admission.py
@@ -197,6 +198,7 @@ tests/test_dt_admission.py
 tests/test_dual_edge_admission.py
 tests/test_element_parallel_kernels.py
 tests/test_engine_pin.py
+tests/test_f000_start_frame.py
 tests/test_forecast_door.py
 tests/test_forecast_preset.py
 tests/test_forecast_receipt_engine.py