An important aspect of fine phi slicing that has not been mentioned yet
(and took me a long time to figure out) is the impact of read-out time.
Traditionally, read-out time is simply a delay that makes the overall
data collection take longer, but with so-called "shutterless" data
collection the read-out time can have a surprising impact on data
quality. It's 2 ms on my Pilatus3 S 6M. This doesn't sound like much,
and indeed 2 ms is also the timing jitter of my x-ray shutter, which
had not been a problem with CCD detectors for 15 years. The difference
is that with so-called "shutterless" data collection not only can
appreciable intensity fall into this 2 ms hole, but none of the data
processing programs have a way to "correct" for it. What you end up
with is Rmerge/Rmeas values of 15-30% in the lowest-angle bin, and
correspondingly low overall I/sigma. At first, I couldn't even solve
lysozyme by S-SAD! This had been an easy task with the Q315r I had just
replaced. The difference turned out to be "noise" coming from this
read-out gap.
The 2 ms gap between images is only important if it is comparable to the
time it takes a relp to transit the Ewald sphere. At 1 deg/s and mosaic
spread of 0.5 deg this is 0.002 deg of missing data, or about 1% error
in integrated intensity. This is fine for most applications. But if
you are turning at 25 deg/s with a room-temperature crystal of mosaicity
0.05 deg, then you could loose the spot entirely in a 2 ms read-out gap
(100% error). This is one of several arguments for fine phi slicing,
where you make sure that every spot is not just observed, but split over
2-3 images. This also helps the pile-up correction Gerd already
mentioned. What is often overlooked, however, is that the error due to
read-out gap is only relevant to partials. Fulls don't experience it at
all, so wide phi slicing is practically immune to it. But with fine phi
slicing everything is a partial, and 100% of the spots are going to take
on read-out-gap error. So, what is the solution? Slow down.
The problem with slowing down the spindle, of course, is radiation
damage. If you've got a flux of 1e12 photons/s into a 100x100 micron
beam spot and 1 A wavelength you are dosing metal-free protein crystals
at about 50 kGy/s. Most room-temperature crystals can endure no more
than 200 kGy, so they will live for about 4 seconds in this beam. A
detector framing at 25 Hz will only get 100 images, no matter what the
spindle speed. The decision then: is it better to get 100 deg at 1
deg/image? or 2.5 deg with fine phi slicing? That is, if the mosaic
spread is 0.05 deg, you can do no more than 0.025 deg/image and still
barely qualify as "fine phi slicing". The 25 Hz framing rate dictates no
less than 40 ms exposures, and that means turning the spindle at (0.025
deg/ 0.04 s) = 0.625 deg/s. Thus, we cover 2.5 deg in the 4 seconds
before the crystal dies. That's just algebra. The pragmatic
consequence is the difference between getting a complete dataset from
one crystal and needing to merge 40 crystals.
Of course, you can attenuate 40x and get 100 fine-sliced degrees, but
that will take 40x more beam time. The images will also be 40x weaker.
In my experience you need at least an average of 1 photon/pixel/image
before even the best data processing algorithms start to fall over. You
can actually calculate photons/pixel/image beforehand if you know your
flux and how thick your sample is:
photons/pixel = 1.2e-5*flux*exposure*thickness/pixels
where flux is in photons/s, exposure in seconds, thickness in microns
and 1.2e-5 comes from the NIST elastic scattering cross section of light
atoms (C, N, O are all ~ 0.2 cm^2/g), the rough density of protein
crystals (1.2 g/cm^3), and the fact that about half of all scattered
photons land on a flat detector at typical distance from the sample, or:
0.2*1.2*(1e-4 cm/um)/2 = 1.155e-5
So, if your flux is 1e12 photons/s and your sample is 100 um thick you
will get ~1 photon/pixel on a 6M in about 5 ms. That corresponds to a
framing rate of 200 Hz. If the detector can't go that fast, you need to
attenuate. Note this is the total sample thickness, including the stuff
around the crystal. Air scatter counts as 1 micron of sample thickness
for every mm of air between the beamstop and collimator. So, in a way,
the beam properties and detector properties can be matched. What is
counter-intuitive is that a 25 Hz detector is sub-optimal for a 100
micron beam with flux 1e12 photons/s. Certain fluxaholics would already
call that a "weak" beam, so why does getting a faster detector mean you
should attenuate it?
It would seem that fine slicing requires throwing away a lot of beam,
unless you only want a few degrees from every crystal. Maybe there is a
better way?
I have experimented with 1-deg images with no attenuation and room
temperature crystals and the results are surprisingly good. Median
real-world Rmeas value are 5%. Not beautiful, but more than adequate
for molecular replacement. I expect what is going on is the pile-up
issues from wide slicing are being compensated by the "instant
re-trigger" feature of Pilatus3. This is basically a pile-up correction
that does not depend on even illumination over an entire image. As for
the accumulation of "extra background" in the wide slices, in the
weak-image limit the background level is already close to zero, so it
doesn't add up very fast over 1 deg. That is, you don't get more than 0
or 1 photon/pixel of background anyway, even with 1 deg images.
So, it would seem that the realities of crystal lifetimes in modern
beams can make fine slicing at full beam difficult to the point of being
inadvisable. Everyone's goals and situation are different, but I do
advise everyone to bear in mind the significance of the read-out gap
noise when deciding on an exposure time and spindle rotation rate. You
should either fine-slice properly, or not at all. And you should
certainly point this out when writing a grant to get an Eiger, which has
a read-out time of 3 microseconds.
-James Holton
MAD Scientist
On 7/13/2017 3:02 PM, Gerd Rosenbaum wrote:
Hi Fred,
fine slicing does not alleviate the count RATE limitation of photon
counting detectors because fine slicing does not reduce the
instantaneous photon flux on the detector when you cross the
diffraction maximum. Fine slicing does help if you push the maximum
counts per pixel per frame to the counter register limit. On
integrating detectors, like CCDs, there is practically no count RATE
limit. They do have a charge (~photons) per pixel per frame limit, as
well, which is mostly much lower than for the photon counting
detectors - about 1/10 even after taking into account the diffraction
spot covers many more pixels.
Different from integrating detectors where you only have to watch the
overflow, for counting detectors you have to watch for exceeding
either the count rate limit or the total count limit. The former is
not an easy task because you will see only the count per exposure.
Divide that by the exposure time you get the AVERAGE rate, not the
peak rate.
The count rate limit, very short exposure time (using high flux) and
the 1-pixel point spread function work against each other. Exposure
time = 0.01 s, count rate limit 1e6 /sec (Pilatus2), 1-2 pixel per
spot => 10-20k counts per spot maximum for the strongest peak.
Dectris has come up with an ingenious hardware and software in the
Pilatus3 pushing the rate for reasonable dead time correction to over
1e7 counts/sec so even with 10 ms exposures weak reflections can be
well recorded besides strong reflections.
Gerd
On 13.07.2017 15:34, Dyda wrote:
I could be wrong here, but isn't the case that fine slicing is an option
with a CCD and a necessity on a PAD b/c of dead time and/or counter
dynamic range
issues?
(no current and/or former financial ties to any manufacturer)
Fred
[32m*******************************************************************************
Fred Dyda, Ph.D. Phone:301-402-4496
Laboratory of Molecular Biology Fax: 301-496-0201
DHHS/NIH/NIDDK e-mail:fred.d...@nih.gov
Bldg. 5. Room 303
Bethesda, MD 20892-0560 URGENT message e-mail:
2022476...@mms.att.net
Google maps coords: 39.000597, -77.102102
http://www2.niddk.nih.gov/NIDDKLabs/IntramuralFaculty/DydaFred
*******************************************************************************[m
