DKX 2.3.1

Fixes both halves of a reported scanType=5 failure — an Er scan inside a
radius scan — on a 66004-DOF deck.

Tier-2 GCROT stalled at the largest |Er|. DKX fell back to the tier-3 host
direct solve, which builds its matrix by applying the operator to n identity
columns and so cannot run at that size — 66004 matvecs and 32.5 GB. The
resulting RuntimeError propagated out through the scan driver and killed every
remaining Er point at that radius: one radius folder finished with zero of a
hundred outputs, another with three.

A stalled solve now escalates

The old message told you to raise max_dense_size. At that size, taking the
advice would have asked for a 32.5 GB allocation.

SFINCS v3 has no equivalent failure mode, and why is what dictated the fix: it
preconditions GMRES with a sparse direct LU (MUMPS or SuperLU_dist) of the
analytically assembled simplified matrix, so its direct solve handles 66004
routinely — and it retries automatically on a failed factorization, doubling the
MUMPS working-memory factor. DKX already shipped the analogue (the sparse
preconditioner, which eliminates in a fill-reducing order instead of eliminating
L first) and simply never tried it.

A stalled Krylov solve is a preconditioner problem, so the ladder is now:
sparse → multigrid → 4× iteration budget → tier 3, only where tier 3 can
run. On the starved-tier-2 fixture, the first rung alone recovers the solve.

When every rung fails, the error names what was tried, the best residual
reached, why tier 3 was skipped, and the remedies that help.

A scan survives a failing point

All six scan types run each point through run_scan_point, which records a
failure and continues instead of raising. A failed point gets a
dkx_FAILED.txt holding the traceback; the scan prints a tally of what is
missing and exits nonzero so a job script still notices. KeyboardInterrupt is
re-raised, so Ctrl-C still stops a scan.

Losing ninety-nine points because one is hard was the wrong trade.

Two things to know

• A point that cannot be solved now takes longer to fail, because the
  escalation tries several remedies first. Right for an unattended scan, but a
  change in timing.
• The escalation is verified on a synthetic stall, not on the 66004-DOF deck
  at Er15 that prompted it. Whether it rescues that specific case is
  unverified until that run is repeated.

pip install --upgrade dkx