Update partiality filtering in dials.export and dials.merge #1184
Conversation
|
I agree. This has hit me in the past when processing very small wedges, where everything is partial. DIALS then gives no reflections in the output MTZ unless you change default options, which seems wrong. |
|
After further discussion, I am not fully correct on this one. The partials that are combined are reflections that were split into different blocks during integration, rather than partials at the edge of sweeps. So these should be combined before export after integration (as per current behaviour), and also before scaling (not the current behaviour). This is tangential to the argument about lowering the partiality threshold, which I think should still occur if we're confident about our ability to integrate partials at the edge of sweeps. |
|
"which I think should still occur if we're confident about our ability to integrate partials at the edge of sweeps" - are we? |
|
The summing partials before scaling though is an important one 🤔 - #todo @jbeilstenedmands ? |
After thinking about this, I don't believe we're doing the right thing in dials export. We currently combine partials and only export if the partiality is 0.99 or greater, effectively filtering out all partials. This data/information can then not be used by other programs such as Aimless, and given that Aimless is able to deal with partials, this data should be kept. Also if partials are combined (how, because they have different scales?), then things like the ROT value become meaningless. Changing to these defaults would then mean a more consistent set of reflections are fed in to dials.scale and Aimless (by default dials.scale is considering all reflections with partiality above 0.4). Similar changes should be implemented in xia2.
For dials.merge, it makes sense to combine partials to get the best estimate of the full intensity, however we should probably not be quite as strict with the partiality cutoff, perhaps 0.95 or 0.9 is more suitable?