Re: [ccp4bb] RE : [ccp4bb] Large unit cell, overlaps
On Tue, 17 Jul 2012 06:26:39 +, LEGRAND Pierre pierre.legr...@synchrotron-soleil.fr wrote: 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. It is not true that this list in IDXREF.LP assumes the crystal to be in the worst orientation. Rather, it refers to the crystal in its _current_ orientation! I think this is a more useful piece of information once the crystal is indexed. best, Kay
Re: [ccp4bb] Large unit cell, overlaps
Hi Jason, I looked at the part of FRAME.cbf you posted, and I'd say it looks ok (i.e. nothing to worry about). Some overlap of a reflection doesn't matter much; if its full profile is not available then INTEGRATE replaces the missing intensity by an estimate based on the known fraction of the intensity. Below a cutoff of MINPK (default is 75 %) however the estimate is considered inaccurate and the reflection is discarded. To judge whether and how many reflections are affected by overlaps, you should consult the table in XDSSTAT.LP; it has no graphical representation and it is a little dense (sorry). If many reflections fail the MINPK test, you might get better completeness if you re-integrate with lower values of the mosaicity - see http://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Optimisation . If the data are for molecular replacement and refinement, you might want to decrease MINPK somewhat (check the table in XDSSTAT.LP!). As this is at the cost of data quality, I'd not recommend this for experimental phasing. HTH, Kay
[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.02.06 1.87 1.18 3.01.63 1.49 0.97 2.01.21 1.11 0.77 1.00.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 bin0.053- - Total number of observations 1981569 5075 44784 Total
[ccp4bb] RE : [ccp4bb] Large unit cell, overlaps [OOPS sign error]
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.01.36 1.17 0.48 3.00.93 0.79 0.27 2.00.51 0.41 0.07 1.00.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.02.06 1.87 1.18 3.01.63 1.49 0.97 2.01.21 1.11 0.77 1.00.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
Re: [ccp4bb] Large unit cell, overlaps
For large unit cells, one must take particular care with the X-ray beam and the orientation of the crystal. The latter has already been mentioned in previous response. For the beam, some things to do are: 1. Make crystal smaller. 2. Make beam smaller (use a smaller collimator size). 3. Reduce beam divergence (change the divergence setting of your optic). 4. Focus beam on the detector and not on the crystal. Also be aware that by definition large unit cells have small mosaicity. If they didn't, one would not even be collecting data because the spots would be all smeared together due to overlap. No amount of fine-slicing will help resolve spots that are overlapped in the rotation direction. Jim ... 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. 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.
Re: [ccp4bb] Large unit cell, overlaps
The cell predictions look like they're overlapping but the spots are not. At first glance it looks like the unit cell is incorrect and is too large. You seem to have intense spots mixed in with weak spots at the same resolution. Smells like multiple unit cells / cracked crystal (which if close together would confuse the autoindex into thinking it's a larger unit cell. . Difficult to tell without seeing the images. The data/spots (not the predicted spots) show reasonable separation. How does the unit cell of the derivative compare with the native? F On Jul 16, 2012, at 2: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 - Francis E. Reyes PhD 215 UCB University of Colorado at Boulder
Re: [ccp4bb] Large unit cell, overlaps
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 bin0.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 Completeness98.8 43.7 82.1 Multiplicity17.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.eduhttp://lupo.jhsph.edu/
Re: [ccp4bb] Large unit cell, overlaps
Hi, This is what I thought when collecting the data - the spots did not look to be overlapping. I have actually got 4 datasets (native, mercury, iodide and platinum soaks) and they all index as the same spacegroup and unit cell (the Pt soak being slightly larger unit cell). This is of a large heterodimer, and this unit cell would put 2 in the ASU and a solvent content of 56%, so this seems reasonable. Mosflm also picks the same unit cell, and the predictions seem to match up with spots (although mosflm predicts lots of overlaps) 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 2:53 PM, Francis E Reyes wrote: The cell predictions look like they're overlapping but the spots are not. At first glance it looks like the unit cell is incorrect and is too large. You seem to have intense spots mixed in with weak spots at the same resolution. Smells like multiple unit cells / cracked crystal (which if close together would confuse the autoindex into thinking it's a larger unit cell. . Difficult to tell without seeing the images. The data/spots (not the predicted spots) show reasonable separation. How does the unit cell of the derivative compare with the native? F On Jul 16, 2012, at 2: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 - Francis E. Reyes PhD 215 UCB University of Colorado at Boulder
Re: [ccp4bb] Large unit cell, overlaps
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 bin0.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 Completeness98.8 43.7 82.1 Multiplicity17.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.eduhttp://lupo.jhsph.edu/ .. Jürgen Bosch Johns Hopkins University Bloomberg School of Public Health Department of Biochemistry Molecular Biology Johns Hopkins Malaria Research
Re: [ccp4bb] Large unit cell, overlaps
From the statistics you posted, it seems like the integration went quite reasonably. There is a slight undercompleteness in the high resolution bin (82% is a bit on the low end but since this is for phasing I'd expect a traceable map in light of this). Do the diffraction images indicate very strong (say I/sd 4) spots beyond 3A? If so then it seems that they're being rejected in the final analysis, possibly due to overlaps. If so, I would certainly recollect this data to obtain the higher resolution spots for refinement (not necessarily for phasing). Depending on how long you've been at this, I'd be eager to solve the structure first :) Go with a synchrotron source, Pt anomalous peak is nearer to 1.1A than 1.54A. Except with the iodide data. Did that have a great anomalous signal? F On Jul 16, 2012, at 8:35 PM, Jason Busby wrote: Hi, This is what I thought when collecting the data - the spots did not look to be overlapping. I have actually got 4 datasets (native, mercury, iodide and platinum soaks) and they all index as the same spacegroup and unit cell (the Pt soak being slightly larger unit cell). This is of a large heterodimer, and this unit cell would put 2 in the ASU and a solvent content of 56%, so this seems reasonable. Mosflm also picks the same unit cell, and the predictions seem to match up with spots (although mosflm predicts lots of overlaps) 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 2:53 PM, Francis E Reyes wrote: The cell predictions look like they're overlapping but the spots are not. At first glance it looks like the unit cell is incorrect and is too large. You seem to have intense spots mixed in with weak spots at the same resolution. Smells like multiple unit cells / cracked crystal (which if close together would confuse the autoindex into thinking it's a larger unit cell. . Difficult to tell without seeing the images. The data/spots (not the predicted spots) show reasonable separation. How does the unit cell of the derivative compare with the native? F On Jul 16, 2012, at 2: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 - Francis E. Reyes PhD 215 UCB University of Colorado at Boulder
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 bin0.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 Completeness98.8 43.7 82.1 Multiplicity17.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
Re: [ccp4bb] Large unit cell, overlaps
I'd run INTEGRATE(REFINE)=CELL CORRECT(REFINE)=CELL and fixing your distance first. Then once XDS is done copy GXPARM.XDS to XPARM.XDS and enter those refined values into your XDS.INP script. Once you have a stable cell you can refine the distance and later fix that one. Moving distance is a bit worrying unless you experience an earthquake while collecting. It's more an indication that your data is not good enough to provide a stable refinement of all parameters at once. @Kai feel free to correct me here. For next time you could ask the following questions: a) am I using the whole detector area ? b) do I really need such high resolution for what I want ? c) collecting oscillations less then 1/3 of your mosaicity does not gain you much in terms of signal/noise you just spent more time collecting and perhaps frying your crystal before obtaining a complete dataset d) for HA less is more collect lower res 4Å for example but quick and reliable. Since you can pull the detector further back you won't run into overlap issues (but check it out with testgen in Mosflm or iMosflm via GUI) I think you are doing very well with what you have in terms of data. Jürgen On Jul 17, 2012, at 12:04 AM, Jason Busby wrote: 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 StCELL 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 bin0.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 Completeness98.8 43.7 82.1 Multiplicity17.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
Re: [ccp4bb] Large unit cell, overlaps
Hi Jason, don't really think that the overall scaling stats look very good. Even for such a long unit cell, we have plenty of in-house data (even with a smaller detector) with much lower Rmerge, typically below 0.15. Possibly monoclinic with beta close to 90deg? This might also explain the shifting distance you mention. Check the detailed output of the pointless log file, not only the last few lines. Check the section where Rmeas is reported for each symmetry element. If you have one or two axes sticking out a bit there, reduce symmetry. This table of pointless has shown to be most valuable in several cases. Good luck. Cheers, Jan -- Jan Abendroth Emerald BioStructures Seattle / Bainbridge Island WA, USA home: Jan.Abendroth_at_gmail.com work: JAbendroth_at_embios.com http://www.emeraldbiostructures.com On Jul 16, 2012, at 8: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 bin0.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 Completeness98.8 43.7 82.1 Multiplicity17.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
Re: [ccp4bb] Large unit cell, overlaps
I second Jürgen's suggestion of fixing the distance -- this is often quite helpful when dealing with difficult datasets, at least in my experience And this goes without saying, but also double check your beamcenter and try masking the beamstop (using UNTRUSTED_ELLIPSE) if you haven't done so already On Jul 17, 2012, at 12:17 AM, Bosch, Juergen jubo...@jhsph.edu wrote: I'd run INTEGRATE(REFINE)=CELL CORRECT(REFINE)=CELL and fixing your distance first. Then once XDS is done copy GXPARM.XDS to XPARM.XDS and enter those refined values into your XDS.INP script. Once you have a stable cell you can refine the distance and later fix that one. Moving distance is a bit worrying unless you experience an earthquake while collecting. It's more an indication that your data is not good enough to provide a stable refinement of all parameters at once. @Kai feel free to correct me here. For next time you could ask the following questions: a) am I using the whole detector area ? b) do I really need such high resolution for what I want ? c) collecting oscillations less then 1/3 of your mosaicity does not gain you much in terms of signal/noise you just spent more time collecting and perhaps frying your crystal before obtaining a complete dataset d) for HA less is more collect lower res 4Å for example but quick and reliable. Since you can pull the detector further back you won't run into overlap issues (but check it out with testgen in Mosflm or iMosflm via GUI) I think you are doing very well with what you have in terms of data. Jürgen On Jul 17, 2012, at 12:04 AM, Jason Busby wrote: 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 StCELL 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 bin0.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 Completeness98.8 43.7 82.1 Multiplicity17.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
