Quick navigation: Home   |    Site Map   ||    References   |    Biography   ||    Copyright   |    Other copyright   |    Contact us   |    Advert   |   
 

[ccp4bb] RE : [ccp4bb] Large unit cell, overlaps [OOPS sign error]

- Protein crystallography

Main steps:

   - Protein purification
   - Crystallisation

Special:

   - Programs for crystallography
   - X-ray detectors

Basic tutorials:

   - Chemistry
   - Protein
   - Peptide
   - Amino Acids

Xtal community:

   - CCP4BB

CCP4bb navigation

CCP4bb <-- 1999 <-- November 1999 <-- 30 November 1999
Previous message:
Subject: RE : Large unit cell, overlaps
From: LEGRAND Pierre pierre {- dot -} legrand {- at -} SYNCHROTRON-SOLEIL {- dot -} FR
Date: 2012-07-17
Next message:
Subject: Faculty position in protein crystallography
From: Danny Huang d {- dot -} huang {- at -} BEATSON {- dot -} GLA {- dot -} AC {- dot -} UK
Date: 2012-07-17


Subject: RE : Large unit cell, overlaps [OOPS sign error]
From: LEGRAND Pierre pierre {- dot -} legrand {- at -} SYNCHROTRON-SOLEIL {- dot -} FR
Date: 2012-07-17

OOPS, I've made a big sign error in this "simple" calculation... Here are the more correct results, script and revised conclusion:

With the correct effect of mosaicity:
dmin a* b* c*
4.0 1.36 1.17 0.48
3.0 0.93 0.79 0.27
2.0 0.51 0.41 0.07
1.0 0.08 0.03 -0.14

So, at your 3.A high resolution limit, you could already start to have overlap problems with 0.5Ëš oscillation range, depending of c* orientation.
If you have 3-circle goniometer, try to orient c* along the spindle axis, otherwise use 0.25Ëš oscillation range.

Pierre


________________________________________
De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de LEGRAND Pierre
Date d'envoi : mardi 17 juillet 2012 08:26
À : CCP4BB@JISCMAIL.AC.UK
Objet : [ccp4bb] RE : [ccp4bb] Large unit cell, overlaps

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.busby@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





















CCP4bb navigation

CCP4bb <-- 1999 <-- November 1999 <-- 30 November 1999
Previous message:
Subject: RE : Large unit cell, overlaps
From: LEGRAND Pierre pierre {- dot -} legrand {- at -} SYNCHROTRON-SOLEIL {- dot -} FR
Date: 2012-07-17
Next message:
Subject: Faculty position in protein crystallography
From: Danny Huang d {- dot -} huang {- at -} BEATSON {- dot -} GLA {- dot -} AC {- dot -} UK
Date: 2012-07-17



ProteinCrystallography.org: Copyright 2006-2010 by Quid United Ltd