Re: [phenixbb] Statistics from 'Scalepack' log file and 'Xtriage' log file

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 On Sun, Feb 12, 2012 at 10:06 PM, Zhang yu wrote:

...

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

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb