Dear Graeme, at the ECM last year Arwen Pearson suggested an even more sophisticated method than the sum of runs. It was based on a set of random sums based on Hadamard-matrices and the subsequent 'deconvolution'.
It sounded very promising to improve signal-to-noise and to turn your sentence "you may get better data" into "you will get better data". I think this would be worth implementing at beamlines - do you know if anything in this direction is on its way? Best, Tim On 05/01/2014 09:25 AM, Graeme Winter wrote: > Hi All, > > A major opportunity with Pilatus detectors is the chance to redistribute > the dose in reciprocal space i.e. measure a lot more data, with less dose / > frame, then decide in hindsight where you probably should have cut off the > data set. > > It is certainly true that "strategies" such as 0.2 s/0.2 degree (I would > call this a tactic myself ;oD) seem to work well, and that it often seems > that you need a reasonable dose to be able to process the data properly > (see below). I would however agree strongly that unless you are not > vulnerable to radiation damage the use of a strategy program such as EDNA > is critical as continuous readout of a fast detector can let you kill your > sample really quickly... and it would be a shame to measure the wrong part > of reciprocal space. > > Also the 0.2s / 0.2 degree rate is very beamline dependent. Here at Diamond > it is certainly routine to measure data with 0.05 s / 0.1 degree exposure > times with Pilatus2 and end up with very good data, and the latest Pilatus3 > machines can run with 0.01s exposure times. As Nukri said earlier, once you > start running at these very high rates you become much more sensitive to > beamline and source characteristics, so your mileage may vary and so on. > It's certainly worth spending some time exploring the capability and what > works well for *your* samples. I would however strongly agree with the > recommendations for fine slicing, and avoid e.g. 1 degree images. > > In terms of "a reasonable dose to process the data properly" there are some > major challenges when dealing with exceedingly weak data in measuring the > reflections at high resolution well: the statistics start to become poorly > behaved with current analysis software. One tactic I have been playing with > is to record the same wedge of data (for example from an EDNA strategy) > with exceedingly low dose perhaps 20 times, then to process this and look > for signs of radiation damage. After arbitrarily deciding which "pass" > radiation damage kicked in at then *sum* the *raw images* from each pass up > to this point e.g. > > pass_1_0001.cbf + pass_2_0001.cbf + .... pass_N_0001.cbf => sum_0001.cbf > > Then process these summed images as if this was the original data. Funnily > enough you may get better data than processing pass_1 to pass_N separately > and then scaling and merging all of the measurements, which leads me to > pointing the pointy finger of blame at the behaviour of the statistics, and > that statistics and things like background subtraction become hard when you > have very sparse data. > > This summing process may seem like manipulating your raw data (naughty!!) > but in essence it is really just performing the same process as when you > recorded multiple exposures / passes on a single CCD image. It also has the > happy side effect of averaging out any random / high frequency effects > induced from source / beamline effects, but will also average in any > radiation damage effects as well! This by the way is what I was getting at > with redistributing your dose in reciprocal space... > > Cheerio, Graeme > > > > > On 30 April 2014 17:41, Harry Powell <ha...@mrc-lmb.cam.ac.uk> wrote: > >> Hi >> >> Marcus Mueller (from Dectris, who develop and manufacture the Pilatus) did >> some work on this a couple of years ago and determined that an oscillation >> angle ~ 0.5x the mosaicity of the crystal (using the XDS value of >> mosaicity, which is not the same as Mosflm's); the abstract says - >> >> The results show that fine ’-slicing can substantially improve scaling >>> statistics and anomalous signal provided that the rotation angle is >>> comparable to half the crystal mosaicity. >>> >>> >>> Acta Cryst. (2012). D68, 42-56 [ doi:10.1107/S0907444911049833 ] >>> Optimal fine >> >> >> -slicing for single-photon-counting pixel detectors >>> >>> M. Mueller, M. Wang and C. Schulze-Briese >>> >>> >> My reading of this is that there is still a place for strategy >> calculations. >> >> >> >> On 30 Apr 2014, at Wed30 Apr 15:06, Sanishvili, Ruslan wrote: >> >> Hi Jacob, >>> >>> I'll take a first crack as I am sure many will follow. >>> It is true that with CCD detectors one has to be careful how small an >>> oscillation range to use for a frame before read noise starts to eat into >>> the data quality. >>> Pilatus offers two major new features - is fast and is photon counting as >>> opposed to integrating detector. >>> The speed allows to collect data without a shutter and it is very >>> important as it can dramatically improve data quality. Now there are fast >>> CCD detectors as well on the market. >>> Being a photon counter, Pilatus has no "read" noise which, as you have >>> pointed out, allows you to collect as thin a frame as you want. However, it >>> is if you consider the detector only. In reality, if you go very thin and >>> very fast, you may not have enough flux to record the data. Also, even once >>> we get rid of the shutter, there are still other sources of instabilities >>> and they do affect the fast data collection adversely. One could try going >>> (very) thin sliced and somewhat slow but there is another gotcha there. >>> Most rotation stages used for rotating the sample crystal, do not like >>> going extremely slow which would be the case with thin frames and long >>> exposure times. In this case the speed may not remain as constant as we >>> would like during data collection. >>> I think there was a publication from Diamond Synchrotron discussing >>> strategies of data collection with Pilatus. >>> We've done a little bit of systematic studies as well and while things >>> may well be sample- and facility-dependent, ~0.2 degree frames with ~0.2 >>> sec exposure time seemed to make good compromise between above-mentioned >>> issues. Here I would like to emphasize again - there certainly will be >>> samples which will benefit from somewhat different parameters. >>> Hope it helps, >>> Cheers, >>> N. >>> >>> Ruslan Sanishvili (Nukri) >>> Macromolecular Crystallographer >>> GM/CA@APS >>> X-ray Science Division, ANL >>> 9700 S. Cass Ave. >>> Lemont, IL 60439 >>> >>> Tel: (630)252-0665 >>> Fax: (630)252-0667 >>> rsanishv...@anl.gov >>> >>> >>> ________________________________________ >>> From: CCP4 bulletin board [CCP4BB@jiscmail.ac.uk] on behalf of Keller, >>> Jacob [kell...@janelia.hhmi.org] >>> Sent: Wednesday, April 30, 2014 7:49 AM >>> To: CCP4BB@jiscmail.ac.uk >>> Subject: [ccp4bb] Pilatus and Strategy wrt Radiation Damage >>> >>> Dear Pilatus/Radiation Damage Cognoscenti, >>> >>> I read a few years ago, before the advent of Pilatus detectors, that the >>> best strategy was a sort of compromise between number of images and >>> detector readout noise "overhead." I have heard that Pilatus detectors, >>> however, have essentially no readout noise, so I am wondering whether >>> strategies have changed in light of this, i.e., is the best practice now to >>> collect as many images as possible at lowest exposure possible? >>> >>> JPK >>> >>> ******************************************* >>> Jacob Pearson Keller, PhD >>> Looger Lab/HHMI Janelia Farms Research Campus >>> 19700 Helix Dr, Ashburn, VA 20147 >>> email: kell...@janelia.hhmi.org >>> ******************************************* >>> >> >> Harry >> -- >> ** note change of address ** >> Dr Harry Powell, MRC Laboratory of Molecular Biology, Francis Crick >> Avenue, Cambridge Biomedical Campus, Cambridge, CB2 0QH >> Chairman of European Crystallographic Association SIG9 (Crystallographic >> Computing) >> >> >> >> >> >> > -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A
signature.asc
Description: OpenPGP digital signature
