<div dir="ltr"><div><div><div><div><div><div><div><div>While testing the new simTBX diffraction image simulator Aaron and I found that some rather beautiful-looking images still won't index. Subsequently, I followed up with mosflm, which does succeed in these cases, even without prior knowledge of the cell or space group.<br><br></div>I have now run this 1000 times, varying only the crystal orientation, and found 171 cases of dials.stills_process failing to index the simulated image whereas mosflm had no trouble, and 5 cases where mosflm failed and dials.stills_process succeeded. There were no overlapping cases where both programs failed. <br><br></div>I have tarballed up the relevant files here:<br><a href="http://bl831.als.lbl.gov/~jamesh/bugreports/dials_index_020218.tgz">http://bl831.als.lbl.gov/~jamesh/bugreports/dials_index_020218.tgz</a><br><br></div>The tarball contains a "<a href="http://runme.com">runme.com</a>" shell script for reproducing these results, and also the tst_nanoBragg_forindex.py jiffy for making a test image given a provided random-number seed. For example:<br><br></div>libtbx.python ./tst_nanoBragg_forindex.py random 15<br><br></div>will create a file called noiseimage_001.cbf that dials.stills_process cannot index (at least in my hands). For those of you who don't have mosflm installed, the tarball incluses a copy, and the "<a href="http://autoindex.com">autoindex.com</a>" script should run on any linux system.<br><br></div>Any ideas as to why there is this discrepancy? Feels like an opportunity for a non-trivial improvement.<br><br></div>Something to ponder over the weekend, I suppose. Note that I recently checked in a few bug fixes to simTBX, but this
analysis is unaffected by them, so you shouldn't have to update your
build to reproduce this.<br><br></div>Cheers,<br><div><br>-James Holton<br></div><div>MAD Scientist<br><br></div><div><br></div></div>