Hi Jason,
To answer your initial question about overlaps versus finer slicing, you can
get a good description of the problem in Fig10 of Z. Dauter article
"Data-collection strategies" (open access article here:
http://journals.iucr.org/d/issues/1999/10/00/ba0020/ba0020.pdf).
From the initial cell parameters, XDS calculates the "Maximum oscillation range
to prevent angular overlap at high resolution limit" (bottom of the IDXREF.LP
file). This calculation assumes zero mosaicity, and crystal in the worst
orientation: with the longest axis perpendicular to the spindle axis.
You can easily have a finer estimation of this maximum oscillation by using the
formula proposed in Zbigniew's article (bottom of page 1707). For example,
using a very simple python script (attached) and the values you have given (and
assuming a 0.1 degree beam divergence):
cell_parameters = 134, 151, 276, 90, 90, 90
mosaicity = 0.25
divergence = 0.1
results are:
dmin a* b* c*
4.0 2.06 1.87 1.18
3.0 1.63 1.49 0.97
2.0 1.21 1.11 0.77
1.0 0.78 0.73 0.56
This shows that, in the worst orientation (c* perpendicular to the spindle) and
the same mosaicity you could record up to 1A resolution data without overlaps
using 0.56 degree oscillation range. In a better orientation, c* aligned along
the spindle axis (using a kappa goniometer for example), you could use up to
0.73 degree oscillations for the same high resolution.
In conclusion, since you have used 0.5˚ oscillations, if crystal moscaicity and
beam divergence are correct, you shouldn't have overlaps problems.
TIPS1: Try using the refined diffraction parameters (cp GXPARM.XDS XPARM.XDS)
and profiles parameters (look for "SUGGESTED VALUES" in INTEGRATE.LP) to re-run
xds using JOB=DEFPIX INTEGRATE CORRECT. You can repeat that several times if it
improves integration statistics.
TIPS2: Check that you don't have a pseudo-translational symmetry problem by
calculating a native Patterson (or running phenix.xtriage)
Good luck,
Pierre
De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Jason Busby
[j.bu...@auckland.ac.nz]
Date d'envoi : mardi 17 juillet 2012 06:04
À : CCP4BB@JISCMAIL.AC.UK
Objet : Re: [ccp4bb] Large unit cell, overlaps
Hi,
Ok, IDXREF.LP shows that it was only using 1-262. I tried running COLSPOT and
IDXREF again, and it picks the same unit cell.
Pointless picks Pmmm and picks 2 definite screw axes, and one possible (p
~0.5), so either P22121 or P212121.
I did change the number of grid points to 13 on my last integration run.
Distance seems to fluctuate from 303.7 to 298.7 - only 303 at the very
beginning and then it drops down to 299 for the rest of the images.
At this point I'm mostly wanting to get a handle on what to do next time I'm
collecting data - whether I need to collect finer slices or try and position
the crystal in the loop at a different angle, or what.
Thanks for the help,
Jason.
--
Jason Busby
PhD Student
Laboratory of Structural Biology
School of Biological Sciences
University of Auckland
Thomas Building 110
3a Symonds St
Private Bag 92019
Auckland 1142
New Zealand
ph: +64 9 3737599 ext 84155
fx: +64 9 3737414
On 17/07/2012, at 3:44 PM, Bosch, Juergen wrote:
grep SPOT_RANGE IDXREF.LP should provide you information about that. No idea
what the default would be.
How about pointless ?
Something else which might buy you a bit of signal is
NUMBER_OF_PROFILE_GRID_POINTS_ALONG_ALPHA/BETA=13
NUMBER_OF_PROFILE_GRID_POINTS_ALONG_GAMMA=13
The default for both is 9, you'll end up with a finer profile 13x13x13.
If you grep for DISTANCE in INTEGRATE.LP is it stable ? If not you might want
to define which values to refine in the integration step via
INTEGRATE(REFINE)=CELL etc.
Jürgen
On Jul 16, 2012, at 11:28 PM, Jason Busby wrote:
Hi,
The autoindexing picks this unit cell pretty much unambiguously, and the
profiles look reasonable. These are crystals of a very large heterodimer (2177
residues), and this unit cell would have 2 heterodimers and 56% solvent, which
seems reasonable. Scaling
and merging produce reasonable statistics (I used aimless, not XSCALE):
Overall InnerShell OuterShell
Low resolution limit 19.91 19.91 3.04
High resolution limit 2.99 16.38 2.99
Rmerge (within I+/I-) 0.339 0.040 0.907
Rmerge (all I+ and I-) 0.348 0.045 0.949
Rmeas (within I+/I-) 0.360 0.042 0.994
Rmeas (all I+ & I-) 0.359 0.046 0.997
Rpim (within I+/I-) 0.119 0.014 0.393
Rpim (all I+ & I-) 0.085 0.012 0.291
Rmerge in top intensity bin 0.053 - -
Total number of observations 1981569 5075 44784
Total number unique 112524 338 4559
Mean((I)/sd(I)) 10.6 53.4 2.6
Mn(I) half-set correlation CC(1/2) 0.993 0.999 0.527
Completeness 98.8 43.7 82.1
Multiplicity 17.6 15.0 9.8
Rmerge is high in the outer shell, but looks ok to me across the rest of the
data. The oscillation angle is correct.
The native data set also indexes with the same spacegroup and a slightly
smaller unit cell (a=134 b=148 c=274), I attributed the difference to the Pt
soak.
The only ambiguity is one of the screw axes, so it may be P22121 or P212121.
My XDS.INP has SPOT_RANGE commented out so I believe the default is to use all
the data for indexing.
Cheers,
Jason.
--
Jason Busby
PhD Student
Laboratory of Structural Biology
School of Biological Sciences
University of Auckland
Thomas Building 110
3a Symonds St
Private Bag 92019
Auckland 1142
New Zealand
ph: +64 9 3737599 ext 84155
fx: +64 9 3737414
On 17/07/2012, at 3:02 PM, Bosch, Juergen wrote:
Hi Jason,
if you look at the generated profiles in INTEGRATE.LP do they seem reasonable ?
Does XSCALE.LP produce reasonable I/SigI statistics and expected Rvalues ? If
not this might be another hint at wrong cell/spacegroup perhaps.
You can try collecting spots from your whole data set with SPOT_RANGE= [start
frame] [end frame] and then index the data. If you get too many strong spots
you can select the top 5000 from SPOT.XDS.
Is the oscillation correct in your script ?
Jürgen
P.S. we just collected some data on a 460Å cell
On Jul 16, 2012, at 5:52 PM, Jason Busby wrote:
Hi,
I have a crystal with a large unit cell in P21221 (a=134 b=151 c=276) and I'm
wondering if I have a problem with overlaps. I have a native dataset, and am
trying to get phases. I've collected a Pt soak data set on our home source
with a 0.5˚ oscillation angle,
but the anomalous signal drops off after about 8Å. I am wondering if this is
a problem due to overlaps at higher resolution.
The Pt dataset has been integrated with XDS, and there don't seem to be too
many rejects, but looking at FRAME.CBF it looks like the predicted spots are
overlapping at higher resolution. You can see a zoomed-in part of FRAME.CBF
here:
http://imgur.com/1WShV
Should I be concerned with this? The crystal mosaicity from XDS is 0.25, so
fairly low. What can I do about this, should I try smaller oscillation angles?
Thanks,
Jason.
--
Jason Busby
PhD Student
Laboratory of Structural Biology
School of Biological Sciences
University of Auckland
Thomas Building 110
3a Symonds St
Private Bag 92019
Auckland 1142
New Zealand
ph: +64 9 3737599 ext 84155
fx: +64 9 3737414
......................
Jürgen Bosch
Johns Hopkins University
Bloomberg School of Public Health
Department of Biochemistry & Molecular Biology
Johns Hopkins Malaria Research Institute
615 North Wolfe Street, W8708
Baltimore, MD 21205
Office: +1-410-614-4742
Lab: +1-410-614-4894
Fax: +1-410-955-2926
http://lupo.jhsph.edu
......................
Jürgen Bosch
Johns Hopkins University
Bloomberg School of Public Health
Department of Biochemistry & Molecular Biology
Johns Hopkins Malaria Research Institute
615 North Wolfe Street, W8708
Baltimore, MD 21205
Office: +1-410-614-4742
Lab: +1-410-614-4894
Fax: +1-410-955-2926
http://lupo.jhsph.edu
from math import pi
def delta_phi(unit_cell, mosaic, div, dmin=2.):
a, b, c = unit_cell[:3]
dphi = []
for axis_length in a, b, c:
dphi.append(180*dmin/(pi*axis_length)+(mosaic+div))
return tuple(dphi)
cell_parameters = 134, 151, 276, 90, 90, 90
mosaicity = 0.25
divergence = 0.1
print " dmin a* b* c*"
for dmin in 4,3,2,1:
print "%6.1f" % dmin,
print (3*"%7.2f") % delta_phi(cell_parameters, mosaicity, divergence, dmin)
