Frozen MnBi c-scan closed tooling-dead: route 0a23817e backing service 404s all 13 points on both launch attempts
Does DFT on the platform pass the Mn-Bi geometry known-answer that CHGNet failed? The frozen protocol was a 13-point static c-scan on LTP MnBi (a = 4.290 Ã… fixed, c from 5.5 to 6.7 Ã… in 0.1 Ã… steps): DFT has standing on the Mn-Bi compression question only if the fitted minimum lands within 0.01 eV/atom of the experimental c = 6.129 Ã…. CHGNet failed the same test at 0.022 eV/atom.
It cannot run. Both launch attempts failed at the route's backing service, and per the pre-registered decision rule the question closes as tooling-dead: no model on the platform can currently answer the Mn-Bi geometry question.
Attempt 1 (2026-09-15 01:39Z): all 13 points queued, then every action errored with external_service_error 404 Not Found, retryable=false about 5 seconds after queue.
Attempt 2 (2026-09-15 13:04Z): I re-verified the route asset reported healthy, smoke-tested one point before committing, then launched the remaining 12. All 13 actions were accepted and queued, then errored with the identical signature: in-progress → error, external_service_error 404, non-retryable, each ~5 s in, spread over 27 seconds. Representative receipts: c=6.0 run, c=5.5 run. The full id list, frozen body, and per-point statuses are in the campaign's launch receipt. The attempt budget (max 2 relaunches per point, frozen before any run) is now spent, so I am recording this as exactly what it is: the scan never produced a single total energy.
Nothing about the chemistry is decided. The inputs were built and validated before the launch gate (13 CIFs, all P6₃/mmc #194 at two symprecs, site order preserved, Mn-Mn = c/2), and they stay frozen in the campaign folder along with the decision rule. If the service is fixed, the scan is one relaunch away.
Observation: route 0a23817e (Magnetic moments) reports healthy as an asset, but its backing service 404s the compute endpoint on every execution since at least 2026-09-15 01:39Z.
Interpretation: with route 713bcc70 (large-cell MAE) hung in-progress for over 22 hours on three actions, both platform DFT routes are effectively down. That closes every capability gate the magnet program is standing on: the Fe17W3 20-atom acceptance MAE, the DFT signed-moments check behind the contested route-Ms, and this geometry scan. The standing-wait posture was correct; the waiting is now total.
0a23817e;
For the record: this was the trigger-gated slice (T3) of the program's standing-wait, executed on its frozen schedule. The program stays in standing-wait on the remaining triggers (T1 collection, phonon go-live, weekly control re-check). No hypothesis was formed or tested today, and none should be until a DFT route answers again.
I already mentioned this to you - Modal services are currently down due to overspend. Pausing a few days to keep cost under control. Thank you for your patience.
Understood, thank you. That explains both signatures at once: the 22h log freeze on the three route 713bcc70 MAE actions and the instant 404s on route 0a23817e, so the MnBi c-scan closure stands as recorded (tooling-unavailable, chemistry untouched, one relaunch away when service returns).
I will treat the whole platform DFT axis as paused for the next few days: no probes, no smoke tests, no attempt-budget spend on either route. All standing-wait triggers that depend on those routes (T1 collection on the three hung MAE actions, T3-resume for the c-scan, the Fe17W3 GO-decision chain) hold until you confirm services are back, and the frozen inputs stay staged. Nothing to do on your side beyond the restore.