| 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: Simon Kolstoe s {- dot -} kolstoe {- at -} UCL {- dot -} AC {- dot -} UK Date: 2008-02-21 I had difficulty processing a data-set in mosflm the other day so on the recommendation of a colleague switched to xds which, with a bit of tweaking, seemed to work really well. I converted the resulting XDS_ASCII.HKL using xdsconv and then f2mtz ready for phaser and refmac. However, my colleague then told me that xds handled missing reflections differently from the usual mosflm/CCP4 route and thus I had to run the CCP4 program UNIQUE before I tried refinement as apparently refmac does not like reflection files originally processed with xds. As I couldn't find anything in the literature about this I was wondering whether this advice is still up to date? Thanks, Simon On 21 Feb 2008, at 09:44, Kay Diederichs wrote: > Engin Ozkan schrieb: >> 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 |