Re: [ccp4bb] High Rmerge with thin frames
Am 20:59, schrieb Harry Powell: ... I think there may be issues with collecting data too finely with a Pilatus, even in shutterless mode. I don't know where the problems arise (can't be shutter/rotation axis synchronisation), but it seems to be the normal thing in XDS (which should have no problems with fine phi-slicing) to use the "PATCH_SHUTTER_PROBLEM=TRUE" that Martin Hallberg suggested, which looks a bit like a fudge to me (but I expect Kay to correct me on that!). ... Hi Harry, no, it is a misunderstanding that the normal thing is to use PATCH_SHUTTER_PROBLEM=TRUE in XDS; rather, it may be the last resort to try before you abandon a dataset, and if the spindle/shutter de-synchronization is so poor that this fudge needs to be used, then the BL hardware needs to be fixed before other datasets are collected. Two other points: a) one may distinguish "weak data resulting in high R-factors" from "problems with hardware or radiation damage resulting in high R-factors" by looking at (I/sigma)^asymptotic as defined in Acta D66, 733 ( http://dx.doi.org/10.1107/S0907444910014836 ). b) Marcus Müller (SLS) has shown (to me, unambiguously) that the best data are obtained from the Pilatus if delta-phi is 1/2 to 1/4 of the mosaicity (as reported by XDS). However, for the best data, other parameters of the experiment (basically the transmission and the spindle speed) have to be optimized as well. The finding of Tassos that 0.5-1 degree data gave the best result in a particular case might indicate that these other factors of his experiment were not optimal (it is indeed not trivial to get them right). best, Kay smime.p7s Description: S/MIME Cryptographic Signature
Re: [ccp4bb] High Rmerge with thin frames
Hi All Both Martin and Kay ( in a later message) have misinterpreted what I wrote - what I meant was that it seems normal in using XDS with Pilatus data, not the normal thing to do with data from other detectors. I had found a number of scripts on the web that deal specifically with processing Pilatus data with XDS that seemed to use "PATCH_SHUTTER_PROBLEM=TRUE" - what I didn't notice was that the commands had all been commented out, and that "FALSE", the default, was in operation. So, in either case I was wrong. Apologies to Kay and Wolfgang, and all who write and use scripts for processing Pilatus data with XDS. On 5 Nov 2010, at 18:33, Martin Hallberg wrote: Hi Harry, On Nov 5, 2010, at 5:45 PM, Harry Powell wrote: I think there may be issues with collecting data too finely with a Pilatus, even in shutterless mode. I don't know where the problems arise (can't be shutter/rotation axis synchronisation), but it seems to be the normal thing in XDS (which should have no problems with fine phi-slicing) to use the "PATCH_SHUTTER_PROBLEM=TRUE" that Martin Hallberg suggested, which looks a bit like a fudge to me (but I expect Kay to correct me on that!). It is not the normal thing in XDS but it is perhaps a relatively common solution to shutter/spindle synchronisation problems discovered afterwards (always process directly at the beam line!). The default in XDS is indeed PATCH_SHUTTER_PROBLEM=FALSE Compensating like this is of course not the best (go and recollect!) but still way better than unusable data in the meantime. In the case Sergei originally described it would at least indicate what the problem may be. Sergei did not say which detector was used for the data collection so we don't know if it was a Pilatus or a CCD. Maybe Sergei can fill us in on the details? BTW, any views in the community on crystal lifetime with continuous data collection like on the Pilatus (or AXIOM) versus letting the crystal rest/cool/die(?) a second between frames on a CCD? Cheers, Martin Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 0QH
Re: [ccp4bb] High Rmerge with thin frames
Dear Ronnie, we are working with weak diffracting crystals. Many tests (and taking into account Marcus Muellers results) showed that 0.3-0.5 of XDS mosaicity, (very) low dose, and high redundancy give the best results. Our crystals diffract between 7 and 4 A. At low dose I do not check diffraction really by eye. I collect 200 images (fine slicing), process and check XDS statistics. (200 images is not much when the dataset comprises 9000-12000 images). Especially for anomalous data this strategy was pivotal. We did also comparisons between CCD and PILATUS. We used one long crystal and collected on end end a MAD dataset using a CCD and afterwards at the other end a MAD dataset on PILATUS, same dose per degree. Results were absolutely clear that the fine slicing give much better results. Best, Guenter Dear Tassos, I'm interested in your third point. Do you have any explanation for why 0.5-1 degrees oscillation gave better data? Purely due to the fact that the crystals survived longer and thus yielded higher redundancy data, or also other parameters? Also do anyone know where the threshold lies for when /not/ to use fine phi slicing on the PILATUS? ie, at what level of diffraction would one need to increase the exposure (and oscillation in order to still get redundant data)? We'll be in a similar position in the coming weeks with data collection using PILATUS detectors, and would like to maximize the potential data quality from our weak diffracting crystals. Any input on this would be greatly appreciated! Cheers, Ronnie Berntsson On Nov 5, 2010, at 16:16, Anastassis Perrakis wrote: three additional points: 1. OTOH, if "The diffraction is quite weak", one may be limited by counting statistics. This also cannot be overcome by processing. As JIm suggests above then, maybe you should look if the 15% Rmerge is almost reasonable given the specific I/sigI at low resolution? 2. If there is one thing I do not like in XDS, is that there is no (or I have failed to find) statistics of I/sigI and Rmerge as function of image. Have a look at the SCALA output. Maybe some images are bad? 3. making too fine slices of too weak diffraction images ends up with either too weak counting statistics or inability to 'lock' the refinement. we did that for one crystal form, collecting 0.1, 0.2, 0.35, 0.5, 0.7, 1.0 from various crystals (with the same dose per degree, at SLS using a PILATUS, mosaicity 0.4-0.6) in an attempt to get better Se signal. We miserably failed to get any useful signal at the end, but learned that for these very weak diffracting plates (submicron) collecting 0.5-1.0 degrees was actually giving at the end better data. A. -- *** Priv.Doz.Dr. Guenter Fritz Fachbereich Biologie Universitaet Konstanz http://www.biologie.uni-konstanz.de/fritz e-mail: guenter.fr...@uni-konstanz.de e-mail: guenter.fr...@uniklinik-freiburg.de http://www.uniklinik-freiburg.de/neuropathologie/live/forschung/ag-g-fritz.html Tel.: +49 761 270 5078 Fax.: +49 761 270 5050
Re: [ccp4bb] High Rmerge with thin frames
Dear All, first of all, I would like to thank the many good people who have responded to my query. Yet another truly interesting discussion on this BB! As a partial summary, two points: 1. Few people suggested that our high Rmerge problem could be caused by experimental troubles like phi angle imprecision rather than the crystal itself. Thus far we could not find indications for that but maybe we did not look carefully enough. However, the frames ARE weak, and I tend to think that this is the main cause of the problem. 2. Few people argued that data processing programs (XDS in particular) 'should' handle thin frames as efficiently as thicker frames... After digesting these (very useful!) arguments, I still tend to think that the best proof would be in the pudding, i.e. trying to pool thin frames into thicker frames (but I do not have an immediate means of doing this... ) Sergei Dear All, I am processing a dataset collected (not by me) with 0.1 degree oscillations. The diffraction is quite weak even though there is a clean diffraction pattern to about 3A. Either Mosflm or XDS processes the data readily with +/- default settings but both yield a high overall Rmerge of about 0.23 in the expected symmetry. Processing in P1 yields an overall Rmerge of ~0.18, but what is especially disappointing is that Rmerge is as high as 0.15 at ~5A resolution already. The question is, how can we process the data so that the merging statistics becomes more reasonable? Apparent mosaicity turns out to be ~0.5A. My naive way of thinking is to try treating each five consecutive frames as a single 0.5 degree frame. Does anyone have experience with this? Many thanks in advance, Sergei -- Prof. Sergei V. Strelkov Laboratory for Biocrystallography Department of Pharmaceutical Sciences, Katholieke Universiteit Leuven O&N2, Campus Gasthuisberg, Herestraat 49 bus 822, 3000 Leuven, Belgium Work phone: +32 16 330845 Fax: +32 16 323469 OR +32 16 323460 Mobile: +32 486 294132 Lab pages: http://pharm.kuleuven.be/anafar
Re: [ccp4bb] High Rmerge with thin frames
Am 20:59, schrieb Sergei Strelkov: ... I still tend to think that the best proof would be in the pudding, i.e. trying to pool thin frames into thicker frames (but I do not have an immediate means of doing this... ) Sergei, try to locate 2pck and 2pck.man which were part of former XDS distributions (there's a link to a Linux binary in article http://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/2pck ). 2pck can add several images, and writes them out as one new image. After the conversion, you may only have to change the filetype, the oscillation range and the number of images in your XDS.INP . Pls tell us what you find! HTH, Kay smime.p7s Description: S/MIME Cryptographic Signature
