Statistics from 'Scalepack' log file and 'Xtriage' log file
Dear Phenixer, What is the reason for the inconsistent data statistics from 'Scalpack' and 'Xtriage' ? 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 40.00 8.93 0.1 0.2 0.4 0.9 1.5 22.6 97.3 0.0 97.3 8.93 7.10 0.8 1.7 2.7 4.1 7.1 35.8 99.2 0.0 99.2 7.10 6.20 2.0 4.6 7.6 10.9 18.4 56.6 99.5 0.0 99.5 6.20 5.64 2.9 6.5 11.1 16.3 27.5 65.0 99.0 0.0 99.0 5.64 5.24 4.1 8.2 13.7 19.2 33.0 67.3 97.4 0.0 97.4 5.24 4.93 4.3 9.4 14.8 19.9 33.1 67.6 96.1 0.0 96.1 4.93 4.68 5.2 10.1 15.9 21.8 33.9 67.8 95.6 0.0 95.6 4.68 4.48 5.4 11.2 17.6 24.7 37.8 69.0 94.5 0.0 94.5 4.48 4.31 5.8 11.0 18.1 25.1 39.8 71.2 94.0 0.0 94.0 4.31 4.16 6.4 14.3 23.6 32.7 47.2 73.6 93.7 0.0 93.7 4.16 4.03 8.2 16.7 27.2 36.7 53.0 76.5 93.1 0.0 93.1 4.03 3.91 9.3 20.5 32.4 42.6 57.8 79.1 93.5 0.0 93.5 3.91 3.81 9.6 23.1 37.2 47.7 61.4 81.6 93.6 0.0 93.6 3.81 3.72 11.6 26.5 41.3 51.7 66.1 84.5 92.9 0.0 92.9 3.72 3.63 11.6 30.9 47.8 58.4 71.0 86.5 93.7 0.0 93.7 3.63 3.55 14.9 34.4 50.7 62.0 74.3 88.9 94.5 0.0 94.5 3.55 3.48 15.4 37.1 54.7 64.6 76.2 89.5 93.4 0.0 93.4 3.48 3.42 17.2 41.5 60.1 69.4 79.6 90.8 94.0 0.0 94.0 3.42 3.36 18.3 44.6 62.3 70.9 79.7 89.4 92.1 0.0 92.1 3.36 3.30 20.8 46.9 64.2 71.9 79.7 88.3 90.3 0.0 90.3 All hkl 8.6 19.9 30.0 37.4 48.7 72.4 94.9 0.0 94.9 In summary, the overall completeness is 94.9%, while completeness of the lowest shell is close to 100%, and highest shell is 90.3%. But when I input the *.sca file into 'Xtriage', I got the following statistics (also completeness as an example). ---------------------------------------------------------------------------------------- | Res. Range | I/sigI>1 | I/sigI>2 | I/sigI>3 | I/sigI>5 | I/sigI>10 | I/sigI>15 | ---------------------------------------------------------------------------------------- | 40.02 - 8.19 | 51.1% | 50.9% | 50.7% | 50.2% | 38.9% | 5.1% | | 8.19 - 6.51 | 50.5% | 49.1% | 47.7% | 45.0% | 27.4% | 3.2% | | 6.51 - 5.69 | 49.0% | 45.7% | 42.9% | 37.1% | 18.0% | 1.4% | | 5.69 - 5.17 | 47.2% | 43.3% | 39.9% | 33.0% | 15.3% | 1.3% | | 5.17 - 4.80 | 45.8% | 41.6% | 38.4% | 31.6% | 14.6% | 1.2% | | 4.80 - 4.52 | 44.4% | 39.7% | 35.9% | 29.1% | 13.5% | 1.1% | | 4.52 - 4.29 | 43.4% | 38.2% | 33.6% | 26.4% | 11.5% | 0.8% | | 4.29 - 4.10 | 41.1% | 34.0% | 29.0% | 21.6% | 9.5% | 0.5% | | 4.10 - 3.95 | 36.1% | 29.2% | 24.6% | 18.5% | 7.6% | 0.3% | | 3.95 - 3.81 | 30.8% | 24.8% | 20.8% | 15.3% | 5.5% | 0.1% | | 3.81 - 3.69 | 27.4% | 21.6% | 17.7% | 12.4% | 3.8% | 0.0% | | 3.69 - 3.59 | 23.8% | 18.7% | 15.2% | 10.2% | 3.0% | 0.1% | | 3.59 - 3.49 | 20.3% | 15.5% | 12.6% | 8.3% | 1.9% | 0.0% | | 3.49 - 3.41 | 17.4% | 12.7% | 10.1% | 6.5% | 1.4% | 0.0% | ---------------------------------------------------------------------------------------- In summary, based on statistics from 'Xtriage', the data is quite incomplete, with only ~50% completeness even at lowest resolution shell. I convert the '*sca' into '*.mtz' file with "Reflection editor", and input the '*.mtz file' into 'Xtriage', I got another totally different statistics (completeness as an example) ---------------------------------------------------------------------------------------- | Res. Range | I/sigI>1 | I/sigI>2 | I/sigI>3 | I/sigI>5 | I/sigI>10 | I/sigI>15 | ---------------------------------------------------------------------------------------- | 39.67 - 8.19 | 96.5% | 96.2% | 95.8% | 94.9% | 74.0% | 10.0% | | 8.19 - 6.51 | 96.3% | 94.4% | 92.1% | 87.3% | 54.5% | 7.0% | | 6.51 - 5.69 | 92.6% | 88.1% | 83.3% | 72.7% | 36.2% | 3.5% | | 5.69 - 5.17 | 88.6% | 83.4% | 77.7% | 64.9% | 30.7% | 3.4% | | 5.17 - 4.80 | 85.6% | 80.0% | 74.8% | 62.3% | 29.4% | 3.3% | | 4.80 - 4.52 | 82.6% | 76.4% | 70.1% | 57.4% | 26.9% | 3.0% | | 4.52 - 4.29 | 80.6% | 73.4% | 65.7% | 52.3% | 23.2% | 2.2% | | 4.29 - 4.10 | 74.4% | 65.2% | 56.6% | 42.7% | 19.5% | 1.3% | | 4.10 - 3.95 | 64.2% | 55.7% | 48.2% | 36.7% | 15.5% | 1.0% | | 3.95 - 3.81 | 55.3% | 47.3% | 40.8% | 30.4% | 11.2% | 0.4% | | 3.81 - 3.69 | 48.7% | 40.9% | 34.7% | 24.8% | 8.1% | 0.2% | | 3.69 - 3.59 | 41.8% | 35.8% | 29.7% | 20.2% | 6.1% | 0.1% | | 3.59 - 3.49 | 35.3% | 29.4% | 24.5% | 16.6% | 4.1% | 0.0% | | 3.49 - 3.41 | 30.1% | 24.1% | 19.8% | 13.2% | 2.9% | 0.0% | ---------------------------------------------------------------------------------------- I am confused by the inconsistent statistics, could some explain it? Thanks. Yu
I'm not sure what's going on, but this is strange - could you please
send me the Scalepack and MTZ files off-list? (The Scalepack log
would be helpful too.)
thanks,
Nat
On Sun, Feb 12, 2012 at 10:06 PM, Zhang yu
Dear Phenixer,
What is the reason for the inconsistent data statistics from 'Scalpack' and 'Xtriage' ?
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 40.00 8.93 0.1 0.2 0.4 0.9 1.5 22.6 97.3 0.0 97.3 8.93 7.10 0.8 1.7 2.7 4.1 7.1 35.8 99.2 0.0 99.2 7.10 6.20 2.0 4.6 7.6 10.9 18.4 56.6 99.5 0.0 99.5 6.20 5.64 2.9 6.5 11.1 16.3 27.5 65.0 99.0 0.0 99.0 5.64 5.24 4.1 8.2 13.7 19.2 33.0 67.3 97.4 0.0 97.4 5.24 4.93 4.3 9.4 14.8 19.9 33.1 67.6 96.1 0.0 96.1 4.93 4.68 5.2 10.1 15.9 21.8 33.9 67.8 95.6 0.0 95.6 4.68 4.48 5.4 11.2 17.6 24.7 37.8 69.0 94.5 0.0 94.5 4.48 4.31 5.8 11.0 18.1 25.1 39.8 71.2 94.0 0.0 94.0 4.31 4.16 6.4 14.3 23.6 32.7 47.2 73.6 93.7 0.0 93.7 4.16 4.03 8.2 16.7 27.2 36.7 53.0 76.5 93.1 0.0 93.1 4.03 3.91 9.3 20.5 32.4 42.6 57.8 79.1 93.5 0.0 93.5 3.91 3.81 9.6 23.1 37.2 47.7 61.4 81.6 93.6 0.0 93.6 3.81 3.72 11.6 26.5 41.3 51.7 66.1 84.5 92.9 0.0 92.9 3.72 3.63 11.6 30.9 47.8 58.4 71.0 86.5 93.7 0.0 93.7 3.63 3.55 14.9 34.4 50.7 62.0 74.3 88.9 94.5 0.0 94.5 3.55 3.48 15.4 37.1 54.7 64.6 76.2 89.5 93.4 0.0 93.4 3.48 3.42 17.2 41.5 60.1 69.4 79.6 90.8 94.0 0.0 94.0 3.42 3.36 18.3 44.6 62.3 70.9 79.7 89.4 92.1 0.0 92.1 3.36 3.30 20.8 46.9 64.2 71.9 79.7 88.3 90.3 0.0 90.3 All hkl 8.6 19.9 30.0 37.4 48.7 72.4 94.9 0.0 94.9
In summary, the overall completeness is 94.9%, while completeness of the lowest shell is close to 100%, and highest shell is 90.3%. But when I input the *.sca file into 'Xtriage', I got the following statistics (also completeness as an example).
---------------------------------------------------------------------------------------- | Res. Range | I/sigI>1 | I/sigI>2 | I/sigI>3 | I/sigI>5 | I/sigI>10 | I/sigI>15 | ---------------------------------------------------------------------------------------- | 40.02 - 8.19 | 51.1% | 50.9% | 50.7% | 50.2% | 38.9% | 5.1% | | 8.19 - 6.51 | 50.5% | 49.1% | 47.7% | 45.0% | 27.4% | 3.2% | | 6.51 - 5.69 | 49.0% | 45.7% | 42.9% | 37.1% | 18.0% | 1.4% | | 5.69 - 5.17 | 47.2% | 43.3% | 39.9% | 33.0% | 15.3% | 1.3% | | 5.17 - 4.80 | 45.8% | 41.6% | 38.4% | 31.6% | 14.6% | 1.2% | | 4.80 - 4.52 | 44.4% | 39.7% | 35.9% | 29.1% | 13.5% | 1.1% | | 4.52 - 4.29 | 43.4% | 38.2% | 33.6% | 26.4% | 11.5% | 0.8% | | 4.29 - 4.10 | 41.1% | 34.0% | 29.0% | 21.6% | 9.5% | 0.5% | | 4.10 - 3.95 | 36.1% | 29.2% | 24.6% | 18.5% | 7.6% | 0.3% | | 3.95 - 3.81 | 30.8% | 24.8% | 20.8% | 15.3% | 5.5% | 0.1% | | 3.81 - 3.69 | 27.4% | 21.6% | 17.7% | 12.4% | 3.8% | 0.0% | | 3.69 - 3.59 | 23.8% | 18.7% | 15.2% | 10.2% | 3.0% | 0.1% | | 3.59 - 3.49 | 20.3% | 15.5% | 12.6% | 8.3% | 1.9% | 0.0% | | 3.49 - 3.41 | 17.4% | 12.7% | 10.1% | 6.5% | 1.4% | 0.0% | ----------------------------------------------------------------------------------------
In summary, based on statistics from 'Xtriage', the data is quite incomplete, with only ~50% completeness even at lowest resolution shell. I convert the '*sca' into '*.mtz' file with "Reflection editor", and input the '*.mtz file' into 'Xtriage', I got another totally different statistics (completeness as an example)
---------------------------------------------------------------------------------------- | Res. Range | I/sigI>1 | I/sigI>2 | I/sigI>3 | I/sigI>5 | I/sigI>10 | I/sigI>15 | ---------------------------------------------------------------------------------------- | 39.67 - 8.19 | 96.5% | 96.2% | 95.8% | 94.9% | 74.0% | 10.0% | | 8.19 - 6.51 | 96.3% | 94.4% | 92.1% | 87.3% | 54.5% | 7.0% | | 6.51 - 5.69 | 92.6% | 88.1% | 83.3% | 72.7% | 36.2% | 3.5% | | 5.69 - 5.17 | 88.6% | 83.4% | 77.7% | 64.9% | 30.7% | 3.4% | | 5.17 - 4.80 | 85.6% | 80.0% | 74.8% | 62.3% | 29.4% | 3.3% | | 4.80 - 4.52 | 82.6% | 76.4% | 70.1% | 57.4% | 26.9% | 3.0% | | 4.52 - 4.29 | 80.6% | 73.4% | 65.7% | 52.3% | 23.2% | 2.2% | | 4.29 - 4.10 | 74.4% | 65.2% | 56.6% | 42.7% | 19.5% | 1.3% | | 4.10 - 3.95 | 64.2% | 55.7% | 48.2% | 36.7% | 15.5% | 1.0% | | 3.95 - 3.81 | 55.3% | 47.3% | 40.8% | 30.4% | 11.2% | 0.4% | | 3.81 - 3.69 | 48.7% | 40.9% | 34.7% | 24.8% | 8.1% | 0.2% | | 3.69 - 3.59 | 41.8% | 35.8% | 29.7% | 20.2% | 6.1% | 0.1% | | 3.59 - 3.49 | 35.3% | 29.4% | 24.5% | 16.6% | 4.1% | 0.0% | | 3.49 - 3.41 | 30.1% | 24.1% | 19.8% | 13.2% | 2.9% | 0.0% | ----------------------------------------------------------------------------------------
I am confused by the inconsistent statistics, could some explain it? Thanks.
Yu
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
On Sun, Feb 12, 2012 at 10:06 PM, Zhang yu
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
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
On Tue, Feb 14, 2012 at 9:27 AM, Zhang yu
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?
As far as I know, Xtriage will treat F+ and F- as separate reflections (at least for the completeness analysis), and the number of expected reflections will be doubled if the data are anomalous.
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?
Yes.
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.
My best guess is that you have overlap problems - I think this is a common result of high mosaicity. I don't know what the best way to handle data like this is, unfortunately; hopefully someone with more knowledge of HKL2000 (or other integration software) can chime in. I'd recommend trying XDS too (you can run it through Xia2 which may be easier). Regardless, I still think this looks like a bug in HKL2000, since I can't see how those statistics correspond to the actual data file. -Nat
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
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"
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
On Tue, Feb 14, 2012 at 12:02 PM, Karolina Michalska
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.
Nope. I haven't seen them respond to many ccp4bb postings either, but it's generally a good forum to ask questions about data processing issues. -Nat
participants (4)
-
A Leslie
-
Karolina Michalska
-
Nathaniel Echols
-
Zhang yu