Skip to content

aurora_configs/allscaip: run float32 — AllScAIP does not support FP64 inference - #224

Merged
OwenPriceSkelly merged 1 commit into
mainfrom
aurora-allscaip-fp64-default-dtype
Sep 1, 2026
Merged

aurora_configs/allscaip: run float32 — AllScAIP does not support FP64 inference#224
OwenPriceSkelly merged 1 commit into
mainfrom
aurora-allscaip-fp64-default-dtype

Conversation

@OwenPriceSkelly

@OwenPriceSkelly OwenPriceSkelly commented Sep 1, 2026

Copy link
Copy Markdown
Member

Supersedes the approach in #221 (merged) after CPU probing against fairchem main showed AllScAIP cannot run at base_precision_dtype=float64 at all — the Aurora verify crash was only the first of three layers:

  1. Radius graph image_id built at the torch default dtype → torch.mm(image_id, cell) crash (what the Aurora sync hit; aurora_configs/allscaip: patch radius-graph image_id dtype for FP64 inference #221 wrapped this one).
  2. Past that, the padded disp/envelope buffers are also default-dtype → index_put dtype crash (found testing the upstream fix; a wrapper can't reach between these internal sites).
  3. Past both (fixed in facebookresearch/fairchem#2184), the backbone hard-casts its node representations to torch.float32 before the output heads (AllScAIP.py, neighbor_reps[:, 0].to(torch.float32)), which then mismatch the doubled head weights. Verified by a full tiny-model FP64 forward on CPU: crashes identically with model.double() alone and with torch.set_default_dtype(float64) — no env-side workaround can reach an explicit cast.

Layer 3 makes FP64 AllScAIP an upstream design question (should the head seam honor base_precision_dtype?), so this PR stops forcing FP64 and runs the fairchem default float32 — exactly what nvidia_configs/allscaip.py runs and verifies green at. _fairchem_device (the xpu index shim) stays.

Known risk, explicitly accepted: uma.py forces FP64 because XPU float32 gave wrong energies for UMA (#217). Whether AllScAIP's float32 is numerically adequate on XPU is exactly what the next sync's verification adjudicates — if it fails tolerance, allscaip-on-Aurora is blocked on upstream FP64 support and we drop the env until then.

Validation: ruff format --check clean, AST parses, deps unchanged. Runtime proof is the next Aurora sync (both allscaip verifies retry automatically).

🤖 Generated with Claude Code

… inference

Reverts the FP64 forcing (and #221's image_id patch rationale) after CPU
probing against fairchem main showed AllScAIP cannot run at
base_precision_dtype=float64 at all, in three layers:

1. the radius graph builds image_id at the torch default dtype ->
   torch.mm(image_id, cell) dtype crash (the Aurora verify failure);
2. past that, the padded disp/envelope buffers are also default-dtype ->
   index_put dtype crash;
3. past both (fixed upstream in facebookresearch/fairchem#2184), the
   backbone hard-casts its node representations to float32 before the
   output heads (AllScAIP.py), which then mismatch the doubled head
   weights -- an explicit cast no default-dtype workaround can reach.

So FP64 AllScAIP needs upstream design work, not an env shim. Run the
fairchem default float32 instead -- the precision the NVIDIA deployments
verify at. If XPU float32 proves numerically inadequate (the reason
uma.py forces FP64), verification will say so and allscaip-on-Aurora is
blocked on upstream FP64 support.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@OwenPriceSkelly
OwenPriceSkelly force-pushed the aurora-allscaip-fp64-default-dtype branch from ea6278d to edfe81a Compare September 1, 2026 19:30
@OwenPriceSkelly OwenPriceSkelly changed the title aurora_configs/allscaip: set default dtype float64 instead of patching image_id aurora_configs/allscaip: run float32 — AllScAIP does not support FP64 inference Sep 1, 2026
@OwenPriceSkelly
OwenPriceSkelly merged commit 6c693b1 into main Sep 1, 2026
5 checks passed
@OwenPriceSkelly
OwenPriceSkelly deleted the aurora-allscaip-fp64-default-dtype branch September 1, 2026 19:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant