| Quick navigation: | Home | Site Map || References | Biography || Copyright | Other copyright | Contact us | | |
|
|
Re: [ccp4bb] XDS and overlaps |
|
CCP4bb navigationCCP4bb <-- 2008 <-- February 2008 <-- 21 February 2008Subject: Re: XDS and overlaps From: Kay Diederichs Kay {- dot -} Diederichs {- at -} UNI-KONSTANZ {- dot -} DE Date: 2008-02-21 > Hi everyone, > > I have been recently relying on XDS quite a bit, but at the same time > worrying about how XDS treats overlaps. We had one dataset that both > HKL2000 and Mosflm would show to have severe overlaps, as expected due > to unit cell parameters and the unfortunate crystal orientation in the > loop. We always ended up with completeness percentages in the 70's. > > XDS can find the same lattice, index and scale the data, but yields a > 100% complete mtz (and a nice structure). Without the HKL/Mosflm-like > GUI, it is difficult to assess the fate of the overlapped observations > in XDS. What I could see with VIEW was that some observations were being > divided into several ovals, probably different reflections, but I'm not > very certain. > > So, the basic question is, how does XDS treat overlaps? I could not > find in the documentation an answer to this question; the single mention > of overlaps I could find tells me that XDS can recognize overlaps, but > does not tell me if it rejects them, or divvies them up into separate > reflections, and if that is the case, how does it divide them, and how > reliable is that? Depending on how it divides the overlaps, could that > affect commonly-used intensity stats and distributions? > > Thanks, > > Engin Engin, the basic answer is: a) each pixel of the detector is assigned to its nearest reflection in reciprocal space b) some of these pixels will mostly allow the background estimation, others will mostly contribute to the integration area (but as they are transformed into a local coordinate system there is not a 1:1 relationship). At this step, pixels which should be background but are higher than expected (due to overlap) are rejected. c) for each reflection, the background is estimated, and the 3D profile is assembled from the pixels contributing to it d) a comparison is made: for a reflection, is the percentage of its observed profile assembled in c) larger than some constant (called "MINPK" in XDS.INP)? If the answer is no, this reflection will be discarded (you could call this situation "overlap"). Among other things, this means that: a) the program does _not_ look around each reflection to detect an overlap situation, it just tries to gather the pixels for each reflection b) as a user, when your crystal-detector distance was chosen too low or the reflections are very broad (resulting in generally strong overlap), you may reduce MINPK down to 50. This will result in more completeness, but you should monitor the quality of the resulting data. Conversely, if you raise MINPK over its default of 75 you will discard more reflections, but the resulting dataset will be a bit cleaner. The reference is W. Kabsch (1988) Evaluation of single-crystal X-ray diffraction data from a position-sensitive detector. J. Appl. Cryst. 21, 916-924. (http://dx.doi.org/10.1107/S0021889888007903) HTH, Kay -- Kay Diederichs http://strucbio.biologie.uni-konstanz.de email: Kay.Diederichs@uni-konstanz.de Tel +49 7531 88 4049 Fax 3183 Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz CCP4bb navigationCCP4bb <-- 2008 <-- February 2008 <-- 21 February 2008 |
| ProteinCrystallography.org: Copyright 2006-2007 by Quid United Ltd |