Ledger (100): the batched fine advance on by default where the case admits it, decided by the toolchain under the validator rules -- the Fortran defaults stay off; gated on the CPU AMR set and the GPU goldens; the CI GPU lanes are the compilers verdict

Author: sbryngelson

docs/documentation/amr_action_plan.md

@@ -226,6 +226,44 @@ possible while AMR aborts on the target machine at 1 rank, and every increment b
 on a compiler that does not reproduce it. It also means the ladder should add a CCE arm as soon as one
 exists, or the same class of breakage will keep accumulating undetected.
 
+## 2026-09-07 (100) — PRE-REGISTERED: the batched fine advance turns ON BY DEFAULT where the case admits it, decided by the toolchain, not by a Fortran default -- an amr case that leaves amr_batched_advance unset gets it with amr_bat_pad = 0.1 when a trial validation with them on passes (amr_device_pack does not ride along: its cap-32/96 A/B is owed first), so the default and the validator's prohibitions are the same rule; the CPU AMR set 58/58 on both commits and the GPU goldens 70/70 (none regenerated); the compilers' verdict is the next CI run's, where every AMR test now runs batched on CCE and NVHPC for the first time
+
+**Why here and not in Fortran.** Ledger 99's probe flipped the three Fortran defaults and ran ten of 58 AMR cases into
+the combinations the validator prohibits (``case_validator.py:1739-1750``: IB, IGR, stretched grids, cylindrical, the
+per-block hooks) -- a Fortran default never meets the Python validator, which reads the case dictionary. The increment
+(``task28/batch-default-py``, fbd72e66 on up/mega f5f51523, +54/-2 then the device_pack drop): ``apply_batching_default(params)``
+in the validator module -- for an ``amr`` case with ``amr_batched_advance`` unset it validates a copy with the two flags on
+and, only if that passes, sets them (an explicit ``amr_bat_pad`` is kept); ``MFCInputFile.generate`` calls
+it before validation and prints one dim line when it applies (once per run: the first target's call sets the key, the
+later ones see it). The Fortran defaults stay F. The harness's golden ``case.py`` files do not record the applied flags:
+a golden's provenance is now toolchain-version-dependent, which is the same situation as every other toolchain-computed
+input, and is why this ledger names the rule. ``./mfc.sh validate`` calls the validator directly and does not apply the
+default (a case with ``amr_bat_pad > 0`` and the flag unset validates as an error there while running fine) -- noted, not
+fixed here. Three validator unit tests
+(admissible case gets the flags; ``ib``, ``igr``, ``stretch_x`` do not; an explicit F and a non-amr case are untouched);
+the case.md row states the rule; precheck (which runs the validator's pytest, 54 passed) passed at both commits.
+Predictions (amr-bench/notes/ledger_drafts/l100_prereg.md): CPU AMR set 58/58 with 48 batched; GPU goldens 70/70,
+TOUCHED=0; no Fortran change, so no identity or timing gate; the CI GPU lanes green. THE 48 WAS WRONG, found before the
+gate finished: applying the rule to the harness's own AMR dictionaries, the default reaches FOUR cases (churn growth
+np=2 and np=4, the two pinned-max_grid_size multi-level cases) -- 27 fail the validator's ``amr_max_grid_size > 0``
+rule (the tests leave the cap derived), 18 run ``amr_subcycle``, 5 ``ib``, 3 each chemistry / stretched / MHD, 2 each
+``igr`` / Lagrangian bubbles / hypoelasticity, 1 cylindrical. Ledger 99's probe ran 48 batched only because a Fortran
+default also bypasses the pinned-cap rule (the slab scratch is then sized to the global half-extent, which works and
+wastes; whether that rule is stricter than the code needs is a question for the next entry, not this one). So this
+default is a production-deck default (every timing deck pins the cap) and a four-test CI default.
+
+**Gate (sbatch 408336 after 408333, amr-bench/gate_t28-408336.out; 408333 gated e8cecbdb, the same code with
+``amr_device_pack`` still in the default).** End to end on one of the four (churn growth np=2, generated by the harness,
+``./mfc.sh run ... -t pre_process`` on the gated CPU build): the toolchain prints the notice and proceeds; on the
+droplet example (``amr_subcycle = T``) it does not, as the rule says. CPU AMR set on fbd72e66 (amdflang CPU, session node k004-003, 22:34-22:38): 58/58 -- 57 in the set plus churn np=2 re-run, because a by-hand check had removed that test's tracked golden directory minutes before (restored from git; the tree was clean before the queued gate started); on e8cecbdb (job 408333) 58/58 too. GPU goldens on fbd72e66 (job 408336, k004-008): 70/70, TOUCHED=0, four of them batched; on e8cecbdb (job 408333) 70/70, TOUCHED=0 as well.
+
+**What the CI run on this head decides.** With the default on, the four admissible AMR tests on every lane run the
+batched advance -- the CCE gpu-acc / gpu-omp and NVHPC gpu-acc / gpu-omp lanes have never run it; four cases is a thin
+verdict, and widening it (a pinned cap on more AMR tests, or relaxing the pinned-cap rule) is the follow-up. A lane that fails only on
+batched AMR cases is a backend defect of the batched path to record, and the default reverts to F for that lane (or
+altogether) in the next entry. ``amr_device_pack`` stays off by default until its cap-32 / cap-96 A/B (GOAL v3 item 3). Pad's measurements: null at cap 32, -12 to -16 %% at
+cap 64, null-to-small-win at cap 96 (ledgers 89, 90, 99).
+
 ## 2026-09-07 (99) — CAP 96 RE-MEASURED AND ITEM 3's DEFAULT PROBED: on 8644c8b4 amr_bat_pad = 0.10 at cap 96 is a NULL-TO-SMALL-WIN (-1.9 %% / -2.9 %% marginal step, both ON arms below both OFF, inside the +/-0.1 s floor; MPI wait flat where ledger 90 saw +14 %%) -- ledger 90's loss on 74764791 is NOT REPRODUCED and its phase tables show a regrid excursion and phase variance, memory pressure is not supported by VRAM sampling; and the coordinated batching default is NOT flippable: with the three flags on, 4 of 58 AMR cases abort on the flag's own uniform-grid rule, the two IGR cases and the four static-IBM cases run to completion and are WRONG against their per-block goldens by 1e-2 to 1e-1 absolute -- batched advance with ib or igr is a correctness defect that must be PROHIBITED before any default moves
 
 **Question and instrument.** Ledger 89 measured ``amr_bat_pad = 0.10`` at cap 64 at -12 to -16 %% of wall; ledger 90 at