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

Hi, I would be careful with auto corrections in HKL2000. This option may reject a lot of reflections, typically the weak ones, which most of the time affects the highest resolution shell. It seems that in this case also low resolution suffered. Many reflections didn't go to your sca file, but this fact is not reflected in the scalepack statistics, which shows how many reflections you collected, but not how many of them passed the mysterious auto correction criteria. So I believe what Xtriage gives is the real statistics of your file. Now, the questions are what statistics do you get without auto corrections and whether you are sure of your space group. And if we want to hear comments from the HKL2000 people, this thread could be also posted on ccp4bb. I am not sure if they use phenixbb. Karolina On 14/2/2012, "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