Hi Zhang,
Just a minor correction, iMosflm does not do scaling, so if it is rejecting a lot of reflections that is almost certainly because of reflection overlap (which would make sense if you say that you have very high mosaicity). The number of overlaps on each image is plotted in the Integration pane.
Probably the only effective way to deal with this in iMosflm is to set the mosaic spread to a value where you do not get too many overlaps and fix it at this value during integration. This will result in systematic errors in the integrated intensities, that will not necessarily show up in the scaling statistics (because the errors are almost the same in symmetry related intensities) but it may still give you a dataset that you can work with.
The reflection overlap is determined by the "minimum spot separation". The program will normally work out a value for this, that depends on the spot size, but you can sometimes cheat a bit and set the minimum spot separation to a slightly smaller value (Using the Settings->Processing options->Processing tab), which will reduce the number of overlaps. However, if you try to reduce this too much it can seriously affect the standard profiles and the data will not be good.
Good luck,
Andrew
On 14 Feb 2012, at 17:27, Zhang yu wrote:
Hi Nat,
The 'anomalous' signal is not useful to me. It is automatically outputted by HKL2000 if I use the "auto-correction" option. When "Xtriage" analyze data and output completeness, how does it handle anomalous signal?
Why I get such big different completeness from .sca and .mtz (converted from the .sca) files? Is that because .sca contains incomplete anomalous while .mtz is non-anomalous?
This dataset is with very high mosaicity. Imosflm reject two many reflections during scaling, but HKL2000 kept most of them and outputted acceptable statistics. I don't know why the resulting .sca file is still with severe incompleteness.
Yes, the Scalepack log and the actual reflections file are from the same run.
Thanks.
Fish
2012/2/13 Nathaniel Echols
<[email protected]> > What is the reason for the inconsistent data statistics from 'Scalpack' and
> 'Xtriage' ?
The root of the problem is that the "anomalous" data are in fact
almost entirely F+ only - there is just one actual Friedel pair (3, 3,
-4, for whatever that's worth). In situations like these I think you
will find phenix.data_viewer very useful for visualizing what is
wrong, since it will display (in reciprocal space) which reflections
are missing. The statistics output by Xtriage appear to be correct
(although perhaps not very useful for diagnosing the problem); note
that even for the (merged) MTZ file, you have severe incompleteness,
which may cause problems later. (It looked like possible collection
strategy issues, but it's difficult to tell from the reduced data
alone.)
> I scaled my data with 'Scalepack' and got the following statistics (take
> completeness as an example)
>
> Shell I/Sigma in resolution shells:
> Lower Upper % of of reflections with I / Sigma less than
> limit limit 0 1 2 3 5 10 20 >20
> total
> All hkl 8.6 19.9 30.0 37.4 48.7 72.4 94.9 0.0 94.9
I have no idea where Scalepack is getting these numbers - without
seeing the source code I can't even begin to guess. As far as I can
tell they have little relation to reality, since even the merged
non-anomalous data are only 74% complete. Are you certain that the
Scalepack log and the actual reflections file are from the same run?
If so, my suspicion is that this is a bug. (I'm not sure how the data
ended up this way either, unfortunately.)
-Nat
_______________________________________________
phenixbb mailing list
[email protected]
http://phenix-online.org/mailman/listinfo/phenixbb