Quick navigation:        Home   |    Site Map   ||    References   |    Biography   ||    Copyright   |    Other copyright   |    Contact us   |   
Protein structure
 

Re: [ccp4bb] XDS and overlaps

 

Basic tutorials:
 
 

CCP4bb navigation

CCP4bb <-- 2008 <-- February 2008 <-- 21 February 2008
Previous message:
Subject: Re: Tough Low-Res MR
From: Raji Edayathumangalam redayath {- at -} MAIL {- dot -} ROCKEFELLER {- dot -} EDU
Date: 2008-02-21
Next message:
Subject: Re: Tough Low-Res MR
From: Roger Rowlett rrowlett {- at -} MAIL {- dot -} COLGATE {- dot -} EDU
Date: 2008-02-21


Subject: Re: XDS and overlaps
From: Simon Kolstoe s {- dot -} kolstoe {- at -} UCL {- dot -} AC {- dot -} UK
Date: 2008-02-21

Whilst we are on the subject of XDS...

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 navigation

CCP4bb <-- 2008 <-- February 2008 <-- 21 February 2008
Previous message:
Subject: Re: Tough Low-Res MR
From: Raji Edayathumangalam redayath {- at -} MAIL {- dot -} ROCKEFELLER {- dot -} EDU
Date: 2008-02-21
Next message:
Subject: Re: Tough Low-Res MR
From: Roger Rowlett rrowlett {- at -} MAIL {- dot -} COLGATE {- dot -} EDU
Date: 2008-02-21



ProteinCrystallography.org: Copyright 2006-2007 by Quid United Ltd