I use XDSCONV to make the mtz file using all of the reflections. Then I use uniqueify in CCP4 to make sure the asymmetric unit is correct for CCP4, and tag the test set.
Bernie Santarsiero On Thu, February 21, 2008 9:32 am, Dirk Kostrewa wrote: > Usually, I run CAD first after F2MTZ to make sure that the > reflections are in the correct reciprocal asymmetric unit for CCP4 > programs. I think, UNIQUE on its own doesn't do this, but the > UNIQUEIFY script calls CAD, UNIQUE and FREERFLAG for setting a > FreeR_flag column. The latter may or may not be wanted, depending on > whether the test-set has been assigned by XDS/XSCALE, already. > > Best regards, > > Dirk. > > Am 21.02.2008 um 16:15 schrieb [EMAIL PROTECTED]: > >> In my experience when going from XDS via some intermediate file to >> mtz format, XDS uses in some cases a different reciprocal >> asymmetric unit as mtz uses, which may result in only half of the >> reflections being used and/or ccp4 programs getting confused. By >> using UNIQUE, one makes sure that the reflections are mapped to the >> correct asymmetric unit. It has nothing to do with missing >> reflections but is in many cases essential. >> >> Best regards, >> Herman >> >> >> -----Original Message----- >> From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On Behalf >> Of Kay Diederichs >> Sent: Thursday, February 21, 2008 3:46 PM >> To: CCP4BB@JISCMAIL.AC.UK >> Subject: Re: [ccp4bb] XDS and overlaps >> >> Simon Kolstoe schrieb: >>> 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. >> >> We do it in the same way here. >> >>> >>> However, my colleague then told me that xds handled missing >>> reflections differently from the usual mosflm/CCP4 route >> >> I have honestly not the slightest idea what your colleague was >> referring to. >> >>> 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 >> >> In the case of a new project, one should run "uniqueify" or some >> other means of assigning reflections to the free set (thin shells >> come to mind; see earlier discussions on CCP4BB). >> >> In the case of an old project, one should transfer the free set of >> reflections from some master data set to the new dataset. >> >> None of this is specific to XDS. >> >> HTH, >> >> Kay >> >>> 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: [EMAIL PROTECTED] Tel +49 7531 88 4049 Fax >>>> 3183 >>>> Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 >>>> Konstanz >>> >> >> >> -- >> Kay Diederichs http://strucbio.biologie.uni-konstanz.de >> email: [EMAIL PROTECTED] Tel +49 7531 88 4049 Fax 3183 >> Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz > > > ******************************************************* > Dirk Kostrewa > Gene Center, A 5.07 > Ludwig-Maximilians-University > Feodor-Lynen-Str. 25 > 81377 Munich > Germany > Phone: +49-89-2180-76845 > Fax: +49-89-2180-76999 > E-mail: [EMAIL PROTECTED] > ******************************************************* > > >
