The rotation two-pass accumulates a dense multi-frame reciprocal-space cloud (all first-pass
frames de-rotated into one common frame) and needs a GLOBAL lattice finder - a 3D FFT whose
peaks are the basis vectors. ffbidx is a single-still, known-cell ORIENTATION finder: it assumes
the spots lie on one Ewald shell (one crystal, one orientation) and maximizes a near-integer-hkl
count for a fixed cell. On the volume-filling rotation cloud that objective has no dominant global
maximum, so ffbidx's coarse orientation scan locks onto an orientation valid for only a local wedge
(~18%) -> garbage merge.
GetIndexingAlgorithm resolved Auto->FFBIDX whenever a cell was known, even for rotation - and a
reference MTZ (-z) or -C silently supplies the cell. So a routine rotation run with a reference for
CCref/R-free flipped the indexer to the one solver that cannot handle its input (lyso_ref: ISa 17.8
with FFT -> 0.5 with FFBIDX, no warning). Force rotation to FFT (GPU) / FFTW (CPU) regardless of the
requested algorithm or a known cell.
Validated: lyso_ref -R with -z reference MTZ now indexes via FFT -> ISa 17.8 (was 0.5), 15975 refl.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>