Re: [cctbxbb] [Dials-support] indexing success rates
Right, typically if I don't know the cell, I'll index a bunch of images
with no target, then use cluster.unit_cell on the results to get a
consensus cell, then re-index with that cell.
For dials.stills_process, the default of fft1d works pretty well generally,
but to get the best results, indexing.method_list=fft1d,fft3d might be
better. There, if the first method fails the second is tried.
real_space_grid_search can also be used.
Getting a specific image in a composite file (such as hdf5) isn't a use
case I've hit often, so I don't have an easy solution there. It's possible
an image range parameter to dials.import would be useful?
-Aaron
On Sat, Feb 3, 2018 at 1:02 AM, Graeme Winter
I can definitely see the advantages of a second pass with a consensus cell. There will always be weak, split or contaminated images that could benefit from the prior information. But in this case I cranked up the spot intensity to be just shy of overloads and we have beautiful, clearly-single-crystal patterns. If you can't index these then something is wrong. I don't like comparing software packages like this because it is hard not to sound insulting to at least one group of authors, but I hope we can all accept that if we have a clear and high-quality image and both mosflm and XDS can get the correct cell from it, then there is no reason why DIALS shouldn't. I have now prepared a 2-image example based on seed 56. In this case rotating the crystal by 0.01 degrees makes the difference between dials.stills_process going from confidently arriving at a very wrong cell in fft1d,fft3d,real_space_grid_search mode to instead arriving at the correct one. In both orientations mosflm and xds arrive at the correct cell. Files here: http://bl831.als.lbl.gov/~jamesh/bugreports/dials_index_020418.tgz I believe the synthetic images do help nail down where the problem might be. It can't be finding too few spots, because the spots are clear. It can't be splitting, ice, zingers or other outlier spots, because I didn't put those in. It can't be the beam center because its in the center of the image and the spot separation is nice and wide. It has to be something in the indexing or cell reduction algorithms. Comparing the logs dials_000.log vs dials_001.log, the problem seems to arrive as early as the "Candidate basis vectors". A 4th ~8 A basis vector is found and seems to win out over the others for reasons that aren't really obvious to me. Where is the code for this step? -James On 2/3/2018 1:11 AM, Aaron Brewster wrote:
participants (2)
-
Aaron Brewster -
James Holton