Re: [ccp4bb] Heme incorporation in expressed protein
Hi, You may find helpful suggestions in Kiyoshi Nagai's papers (mid 80ies) who did this with haemoglobin (I could be wrong but I think he was the first to do this). Cheers, Boaz Boaz Shaanan, Ph.D. Dept. of Life Sciences Ben-Gurion University of the Negev Beer-Sheva 84105 Israel E-mail: bshaa...@bgu.ac.il Phone: 972-8-647-2220 Skype: boaz.shaanan Fax: 972-8-647-2992 or 972-8-646-1710 From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Biswajit Pal [p...@ccmb.res.in] Sent: Monday, July 16, 2012 8:45 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Heme incorporation in expressed protein Dear all, Sorry for non-crystallography related question. We are trying to express an eukaryotic heme protein in E. coli. We are able to express it in soluble form. When we use 5-Aminolevulinic Acid, E. coli becomes brown. However, after cell lysis the soluble protein contains no heme and the pellet is brown. If we extract the pellet with detergent (Triton X-100 and Tween-20) the color comes in the supernatant, but there is no protein of our interest. These eventually indicate that the protein and heme are getting expressed/synthesized, but heme is not getting incorporated in the expressed protein. We would like to get this protein in heme-bound holo-form. Any suggestion to trouble-shoot this problem would be highly appreciated. Replies can be sent to me directly and I will post a summary on a later date. Thanks in advance, Sincerely yours, Biswajit Pal CCMB, Hyderabad, India
[ccp4bb] question on merging multiple data
Hi all, I have to merge several datasets from different crystals because the crystals suffer from severe radiation damage. I read some previous posts and follow the protocol as described, 1) individually process the data; 2) scaleit to compare the Rfactors between different datasets; 3) renumber the batch number; 4) for those with low R-factor files (below 0.25), sort them; 5) scala the sorted file. the script i used for the SCALA is, scales batch brotaion spacing 5 which is the one in CCP4 example script that recommended for synchrontron data. For the first four dataset that are all cutoff to about 3.0A based on I/sigI, and the statistics are like this, N 1/d^2 Dmin(A) Rmrg Rfull Rcum Av_I SIGMA I/sigma $$ 1 0.0111 9.49 0.038 0.030 0.038 1934 125.2 15.5 2 0.0222 6.71 0.050 0.009 0.044 118292.4 12.8 3 0.0333 5.48 0.086 0.018 0.05556571.0 8.0 4 0.0444 4.74 0.093 0.166 0.065724 100.2 7.2 5 0.0556 4.24 0.105 0.139 0.074746 116.9 6.4 6 0.0667 3.87 0.143 0.058 0.085522 105.4 5.0 7 0.0778 3.59 0.217 0.142 0.098358 107.8 3.3 8 0.0889 3.35 0.365 0.265 0.115216 109.5 2.0 9 0.1000 3.16 0.634 2.509 0.134126 110.0 1.1 10 0. 3.00 0.965 10.157 0.154 81 109.8 0.7 For the fifth data cutoff to 2.76A, the stastics for the single data is like this, N 1/d^2 Dmin(A) Rmrg Rfull Rcum Av_I SIGMA I/sigma $$ 1 0.0131 8.73 0.031 0.036 0.031 6866 416.2 16.5 2 0.0263 6.17 0.034 0.036 0.032 2994 185.5 16.1 3 0.0394 5.04 0.039 0.040 0.034 2327 185.5 12.5 4 0.0525 4.36 0.039 0.045 0.036 3358 249.6 13.5 5 0.0656 3.90 0.047 0.048 0.038 2226 184.2 12.1 6 0.0788 3.56 0.064 0.059 0.041 1390 151.7 9.2 7 0.0919 3.30 0.101 0.084 0.045787 118.0 6.7 8 0.1050 3.09 0.145 0.114 0.04848298.8 4.9 9 0.1181 2.91 0.271 0.234 0.05325996.5 2.7 10 0.1313 2.76 0.398 0.333 0.058183 102.8 1.8 Then i merge this fifth data with the other four and get the stastics like this, N 1/d^2 Dmin(A) Rmrg Rfull Rcum Av_I SIGMA I/sigma $$ 1 0.0131 8.73 0.072 0.048 0.0727545 954.4 7.9 2 0.0263 6.17 0.100 0.057 0.0853417 528.8 6.5 3 0.0394 5.04 0.145 0.072 0.1032497 543.6 4.6 4 0.0525 4.36 0.158 0.089 0.1213308 790.6 4.2 5 0.0656 3.90 0.200 0.091 0.1382374 710.3 3.3 6 0.0788 3.56 0.299 0.128 0.1581496 663.8 2.3 7 0.0919 3.30 0.462 0.173 0.177 848 644.7 1.3 8 0.1050 3.09 0.577 0.144 0.187 483 414.7 1.2 9 0.1181 2.91 0.720 0.265 0.192 311 358.2 0.9 10 0.1312 2.76 0.392 0.342 0.192 217 122.7 1.8 My question is that after why the SIG_I becomes very large at different resolution shells merging the five data. Say, at 8.73A, merging the four low-resolution files give about SIG_I of 125; the single high-resolution file give 416, but after merging, they give up to 954, is this normal? or i made something wrong? Thank you very much in advance! Fengyun
Re: [ccp4bb] question on merging multiple data
All this is best done from the GUI - pointless will sort out batch numbers, check indexing etc.. But you still have to identify any rogue batches, and decide on when to jettison the data st.. The Sigma level is related to the number of observations of each reflection, so this will decrease as the number of observations increases, and therefor I/Sigma will increase.. Eleanor On 16 Jul 2012, at 14:54, Fengyun Ni wrote: Hi all, I have to merge several datasets from different crystals because the crystals suffer from severe radiation damage. I read some previous posts and follow the protocol as described, 1) individually process the data; 2) scaleit to compare the Rfactors between different datasets; 3) renumber the batch number; 4) for those with low R-factor files (below 0.25), sort them; 5) scala the sorted file. the script i used for the SCALA is, scales batch brotaion spacing 5 which is the one in CCP4 example script that recommended for synchrontron data. For the first four dataset that are all cutoff to about 3.0A based on I/sigI, and the statistics are like this, N 1/d^2 Dmin(A) Rmrg Rfull Rcum Av_I SIGMA I/sigma $$ 1 0.0111 9.49 0.038 0.030 0.038 1934 125.2 15.5 2 0.0222 6.71 0.050 0.009 0.044 118292.4 12.8 3 0.0333 5.48 0.086 0.018 0.05556571.0 8.0 4 0.0444 4.74 0.093 0.166 0.065724 100.2 7.2 5 0.0556 4.24 0.105 0.139 0.074746 116.9 6.4 6 0.0667 3.87 0.143 0.058 0.085522 105.4 5.0 7 0.0778 3.59 0.217 0.142 0.098358 107.8 3.3 8 0.0889 3.35 0.365 0.265 0.115216 109.5 2.0 9 0.1000 3.16 0.634 2.509 0.134126 110.0 1.1 10 0. 3.00 0.965 10.157 0.154 81 109.8 0.7 For the fifth data cutoff to 2.76A, the stastics for the single data is like this, N 1/d^2 Dmin(A) Rmrg Rfull Rcum Av_I SIGMA I/sigma $$ 1 0.0131 8.73 0.031 0.036 0.031 6866 416.2 16.5 2 0.0263 6.17 0.034 0.036 0.032 2994 185.5 16.1 3 0.0394 5.04 0.039 0.040 0.034 2327 185.5 12.5 4 0.0525 4.36 0.039 0.045 0.036 3358 249.6 13.5 5 0.0656 3.90 0.047 0.048 0.038 2226 184.2 12.1 6 0.0788 3.56 0.064 0.059 0.041 1390 151.7 9.2 7 0.0919 3.30 0.101 0.084 0.045787 118.0 6.7 8 0.1050 3.09 0.145 0.114 0.04848298.8 4.9 9 0.1181 2.91 0.271 0.234 0.05325996.5 2.7 10 0.1313 2.76 0.398 0.333 0.058183 102.8 1.8 Then i merge this fifth data with the other four and get the stastics like this, N 1/d^2 Dmin(A) Rmrg Rfull Rcum Av_I SIGMA I/sigma $$ 1 0.0131 8.73 0.072 0.048 0.0727545 954.4 7.9 2 0.0263 6.17 0.100 0.057 0.0853417 528.8 6.5 3 0.0394 5.04 0.145 0.072 0.1032497 543.6 4.6 4 0.0525 4.36 0.158 0.089 0.1213308 790.6 4.2 5 0.0656 3.90 0.200 0.091 0.1382374 710.3 3.3 6 0.0788 3.56 0.299 0.128 0.1581496 663.8 2.3 7 0.0919 3.30 0.462 0.173 0.177 848 644.7 1.3 8 0.1050 3.09 0.577 0.144 0.187 483 414.7 1.2 9 0.1181 2.91 0.720 0.265 0.192 311 358.2 0.9 10 0.1312 2.76 0.392 0.342 0.192 217 122.7 1.8 My question is that after why the SIG_I becomes very large at different resolution shells merging the five data. Say, at 8.73A, merging the four low-resolution files give about SIG_I of 125; the single high-resolution file give 416, but after merging, they give up to 954, is this normal? or i made something wrong? Thank you very much in advance! Fengyun
Re: [ccp4bb] question on merging multiple data
Thank you, Eleanor! I'll try pointless. In my case, the Sigma increase as i merge all the five data while I/sigma decrease, which is opposite to what you describe. Is this abnormal? Fengyun Quoting Eleanor Dodson eleanor.dod...@york.ac.uk: All this is best done from the GUI - pointless will sort out batch numbers, check indexing etc.. But you still have to identify any rogue batches, and decide on when to jettison the data st.. The Sigma level is related to the number of observations of each reflection, so this will decrease as the number of observations increases, and therefor I/Sigma will increase.. Eleanor On 16 Jul 2012, at 14:54, Fengyun Ni wrote: Hi all, I have to merge several datasets from different crystals because the crystals suffer from severe radiation damage. I read some previous posts and follow the protocol as described, 1) individually process the data; 2) scaleit to compare the Rfactors between different datasets; 3) renumber the batch number; 4) for those with low R-factor files (below 0.25), sort them; 5) scala the sorted file. the script i used for the SCALA is, scales batch brotaion spacing 5 which is the one in CCP4 example script that recommended for synchrontron data. For the first four dataset that are all cutoff to about 3.0A based on I/sigI, and the statistics are like this, N 1/d^2 Dmin(A) Rmrg Rfull Rcum Av_I SIGMA I/sigma $$ 1 0.0111 9.49 0.038 0.030 0.038 1934 125.2 15.5 2 0.0222 6.71 0.050 0.009 0.044 118292.4 12.8 3 0.0333 5.48 0.086 0.018 0.05556571.0 8.0 4 0.0444 4.74 0.093 0.166 0.065724 100.2 7.2 5 0.0556 4.24 0.105 0.139 0.074746 116.9 6.4 6 0.0667 3.87 0.143 0.058 0.085522 105.4 5.0 7 0.0778 3.59 0.217 0.142 0.098358 107.8 3.3 8 0.0889 3.35 0.365 0.265 0.115216 109.5 2.0 9 0.1000 3.16 0.634 2.509 0.134126 110.0 1.1 10 0. 3.00 0.965 10.157 0.154 81 109.8 0.7 For the fifth data cutoff to 2.76A, the stastics for the single data is like this, N 1/d^2 Dmin(A) Rmrg Rfull Rcum Av_I SIGMA I/sigma $$ 1 0.0131 8.73 0.031 0.036 0.031 6866 416.2 16.5 2 0.0263 6.17 0.034 0.036 0.032 2994 185.5 16.1 3 0.0394 5.04 0.039 0.040 0.034 2327 185.5 12.5 4 0.0525 4.36 0.039 0.045 0.036 3358 249.6 13.5 5 0.0656 3.90 0.047 0.048 0.038 2226 184.2 12.1 6 0.0788 3.56 0.064 0.059 0.041 1390 151.7 9.2 7 0.0919 3.30 0.101 0.084 0.045787 118.0 6.7 8 0.1050 3.09 0.145 0.114 0.04848298.8 4.9 9 0.1181 2.91 0.271 0.234 0.05325996.5 2.7 10 0.1313 2.76 0.398 0.333 0.058183 102.8 1.8 Then i merge this fifth data with the other four and get the stastics like this, N 1/d^2 Dmin(A) Rmrg Rfull Rcum Av_I SIGMA I/sigma $$ 1 0.0131 8.73 0.072 0.048 0.0727545 954.4 7.9 2 0.0263 6.17 0.100 0.057 0.0853417 528.8 6.5 3 0.0394 5.04 0.145 0.072 0.1032497 543.6 4.6 4 0.0525 4.36 0.158 0.089 0.1213308 790.6 4.2 5 0.0656 3.90 0.200 0.091 0.1382374 710.3 3.3 6 0.0788 3.56 0.299 0.128 0.1581496 663.8 2.3 7 0.0919 3.30 0.462 0.173 0.177 848 644.7 1.3 8 0.1050 3.09 0.577 0.144 0.187 483 414.7 1.2 9 0.1181 2.91 0.720 0.265 0.192 311 358.2 0.9 10 0.1312 2.76 0.392 0.342 0.192 217 122.7 1.8 My question is that after why the SIG_I becomes very large at different resolution shells merging the five data. Say, at 8.73A, merging the four low-resolution files give about SIG_I of 125; the single high-resolution file give 416, but after merging, they give up to 954, is this normal? or i made something wrong? Thank you very much in advance! Fengyun
Re: [ccp4bb] strict structure based alignment
Hi - SSM algorithm at PDBeFold will do this sort of thing http://www.ebi.ac.uk/msd-srv/ssm/ I wrote a tutorial for multiple alignment to go with a Phaser story http://www.ebi.ac.uk/pdbe-apps/quips?story=Phaserauxpage=MultiplePDBeFoldminitutorial The last page of this tells you where to get an multiple fastA alignment of the superimposed structures and explains the format. Hope that helps. Martyn Martyn Symmons EBI Cambridge From: Eric Pettersen p...@cgl.ucsf.edu To: CCP4BB@JISCMAIL.AC.UK Sent: Monday, 16 July 2012, 2:17 Subject: Re: [ccp4bb] strict structure based alignment On Jul 13, 2012, at 4:00 PM, Christian Roth wrote: I want align a couple or protein structures by secondary structure matching to one target and want get a kind of aminoacid alignment file e.g. what residue fit the other, without adjustments due to sequence based alignments. I tried Strap, but as far as I understood it, it takes also the sequence into account. I tried also Rapido, but this does only a pairwise comparison. Superpose does align it nicely (ccp4 based or Coot based) but there seems to be no option to print the sequence alignment in a file and it is again just a pairwise comparison . Is there an other program which does something similar? If you use UCSF Chimera (www.cgl.ucsf.edu/chimera), you can use the MatchMaker tool to superimpose the structures. MatchMaker allows you to adjust the weight of sequence similarity vs. secondary structure matching, so you can just make the sequence similarity 0% and the secondary structure 100%. With the structures superimposed, you can use the Match-Align tool to generate a sequence alignment based solely on the proximity of residues to one another in space. Be warned that Match-Align will be very slow for 10+ structures, but is fine for half a dozen or so. The generated alignment will be displayed in a window that will have a File menu where you can save the alignment to a variety of common formats. --Eric Eric Pettersen UCSF Computer Graphics Lab
[ccp4bb] CCP4 6.3.0 release
Dear All, We're very pleased to announce the release of the latest version of the CCP4 Software Suite. Version 6.3.0 (Settle) is now available from the CCP4 download website: http://www.ccp4.ac.uk/download.php The release is available for Linux, Mac OSX and Windows platforms, and delivers a number of new programs, updates and features: 1. New Components and Updates: New: Aimless(Scaling and Merging, replacement for Scala) Prosmart (Generation of external restraints for Refmac) Nautilus (Automatic building of RNA/DNA) Ample (Automatic Ab initio modelling for Molecular Replacement) Dimple (Automatic difference map calculation) Zanuda (Space group checker/validator) CMapCut(Preparation of electron-density search model for MR) Comit (Composite omit maps) Gesamt (Structure aligner not using secondary structure assignments) ViewHKL(Graphical viewer for reflection data) Updated: Mosflm v7.0.9 (Data processing/reduction) iMosflm v1.0.7 (Mosflm GUI) Pointless v1.6 (Laue group determination) Refmac v5.7(Macromolecular refinement) Phaser v2.5.1 (Molecular Replacement and Experimental Phasing) MrBump (Automatic Molecular Replacement, now includes phaser.sculptor models) Xia2 (Automated data reduction) CCP4mg v2.6.2 (CCP4 Molecular Graphics, much improved on features and stability) CCP4 Graphical User Interface: - new automation module - provides interfaces for new and updated modules - ViewHKL option for viewing reflection (mtz) files More information on updates is available from: http://www.ccp4.ac.uk/html/CHANGESinV6_3.html 2. ARP/wARP co-distribution Release 6.3.0 marks a milestone in collaboration between CCP4 and ARP/wARP teams by releasing ARP/wARP Model Building software v7.3 jointly with CCP4 Software Suite. In order to get ARP/wARP Software, academic users need only to select the appropriate package from download pages or with our new Package Manager, and type in their name and e-mail address where required. Commerical users will be required also to provide their reference number, obtainable separately from EMBL-EM. ARP/wARP 7.3 includes the following major updates and changes (on behalf of Victor Lamzin): - The protocols for the use of NCS in protein chain tracing have been improved and expanded to a wider range of resolutions. - Common ligands can now be automatically identified and fit into a specified electron density. - The algorithm for modelling partial ligands (cocktail screening) has been replaced with a new one that applies a number of sophisticated numerical features - The ARP/wARP graphics front-end, ArpNavigator, automatically assigns secondary structure and has an improved visual presentation of a static model or real time protein or ligand building. - Supported computer platforms are Mac powerpc, Mac Intel and Linux (including 32 and 64-bit versions). - The ARP/wARP installer has been considerably updated on all platforms. - Joint software release and authentication with the CCP4 is now possible. - CCP4 6.3.0 and Refmac 5.7.0029 are the recommended versions to use with ARP/wARP 7.3. 3. 64-bit precompiled packages Starting with version 6.3.0, CCP4 distributes both 32-bit and 64-bit precompiled binaries for Linux. Note that 64-bit codes will not run on 32-bit architectures, and 32-bit codes will run on 64-bit setups only if 32-bit libraries are installed (not a default for most Linuxes). THEREFORE: PLEASE MAKE SURE THAT YOU HAVE SET THE 32-bit/64-bit SWITCH ON TOP OF THE DOWNLOAD PAGES CORRECTLY BEFORE ALL! 4. Friendly Coot and CCP4mg distributions Coot is known to be less portable than the rest of CCP4 Program Suite. CCP4mg is more portable and requires special builds only for older Linuxes. Our new Package Manager will try to automatically choose Coot and CCP4mg bundles that are most appropriate for your system. In addition, our new download pages will offer you a range of precompiled Coot and CCP4mg packages, from where you may choose ones that work for you. 5. New distribution mechanism We hope that you will find our new Download Pages more intuitive and convenient than before. We have worked hard to improve our Windows installer, to make it working faster and smoother. On Linux and Mac platforms, we recommend using Package Manager, a small graphical application that allows you to select the desired components, and automatically download and install them on your system. Note that Package Manager features resumable downloads, which may be useful for users with slow or less reliable Internet connection. We would like to thank all of the developers who have contributed into CCP4 6.3.0, and all of those who have helped in testing it. The following publication should be used to cite the use of CCP4: M. D. Winn, C. C. Ballard, K. D. Cowtan, E. J. Dodson, P. Emsley, P. R. Evans, R. M. Keegan, E. B.
Re: [ccp4bb] harvesting in cold room (was: cryo for high salt crystal)
BTW, a l-o-n-g time ago, I worked on a project with crystals that only grew in the cold room. BUT... we found out that the crystals could in fact be transferred to a regular lab under condition that you warmed them up very slowly. So I would harvest the crystals into capillaries (this was before cryo) and put them in a petri dish, then put the dish in a cooler with several glass bottles of buffer and put the cooler in the lab. Then you wait. This worked. If you did not warm them up slowly, the crystals would be ruined. Also, we never tried to take the trays in which the crystals were grown out of the cold room, i.e. when the crystals are still swimming. Just some old data that might apply to other projects. Mark -Original Message- From: Radisky, Evette S., Ph.D., Ph.D. radisky.eve...@mayo.edu To: CCP4BB CCP4BB@JISCMAIL.AC.UK Sent: Sat, Jul 14, 2012 7:20 am Subject: Re: [ccp4bb] harvesting in cold room (was: cryo for high salt crystal) As I recall, I used to wear latex gloves, add extra padding to the handle end of the wand (and other tools) with bits of tubing, and take my tools out of the cold room every 20 min or so to de-ice and dry them. I didn’t really have a choice about the cold room because it was the only place my crystals would grow, and my crystallization solution was 20% isopropanol which was too volatile to work with outside the cold room anyway. Evette S. Radisky, Ph.D. Assistant Professor Mayo Clinic Cancer Center Griffin Cancer Research Building, Rm 310 4500 San Pablo Road Jacksonville, FL 32224 (904) 953-6372 From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Bosch, Juergen Sent: Friday, July 13, 2012 8:27 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] harvesting in cold room (was: cryo for high salt crystal) This is a very interesting topic I have to say. But what I missed in this discussion is the pain you go through when freezing in the cold room. As the name implies it's supposed to be cold (most of the times). But that's not too much of an issue as you can dress up accordingly. The problem I always had was freezing up of the advertisement Hampton Magnetic Wand /advertisement and icing up towards your fingertips after some time when moisture from the cold room condenses and freezes. I hate wearing gloves when handling crystals so there was not much of a skin protection. How do you guys solve this problem ? Jürgen .. 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] Off-topic - Equipment to donate
The Beth Israel Deaconess Medical Center X-ray Core facility in the Longwood Medical Area of Boston, MA would like to donate the following surplus equipment ARI Art Robbins Instruments Robbins Scientific Hydra 96 in fair condition A set of Yale mirrors in good condition Please see our website for contact information: http://www.bidmc.org/Research/CoreFacilities/XrayCrystallographyCore.aspx Interested parties should provide shipping and handling.
[ccp4bb] co-express two proteins in E.coli
Dear ALL, We are planning to co-express two proteins in E.coli. Could anyone suggest a good dual set plasmid or a proper insertion sequence between two genes, including the Shine-Dalgarno sequence? Thank you very much and have a nice summer. Jerry McCully
[ccp4bb] Large unit cell, overlaps
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
Re: [ccp4bb] co-express two proteins in E.coli
I've had success with pet-Duet. http://ecoliwiki.net/colipedia/index.php/pETDuet-1 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 9:23 AM, Jerry McCully wrote: Dear ALL, We are planning to co-express two proteins in E.coli. Could anyone suggest a good dual set plasmid or a proper insertion sequence between two genes, including the Shine-Dalgarno sequence? Thank you very much and have a nice summer. Jerry McCully
Re: [ccp4bb] co-express two proteins in E.coli
I have been using the Duet system from Novagen (or whatever it is called these days), specifically the pETDuet-1 and pRSFDuet-1. Co-expression of my proteins did not work in either vector. Either, one protein expressed or the other. I played around with the promotors (they are both T7) by changing one to the tac promotor. This increased the expression of this gene but shut off expression of the other. The only way I could get my proteins to co-express was to use pGEX vector with one protein, and pRSFDuet with the other protein (leaving the second MCS empty). There is a paper which sums up co-expression in E coli. http://www.nature.com/nmeth/journal/v3/n1/full/nmeth0106-55.html Dan
Re: [ccp4bb] Heme incorporation in expressed protein
I was able to express a heme protein by inducing and expressing at room temperature and using a promoter weaker than T7 (can't remember the exact one right now). The key was to slow down the rate of protein production to allow heme incorporation. You might try using less IPTG too. Ho Leung Ng University of Hawaii at Manoa Assistant Professor, Department of Chemistry h...@hawaii.edu On Mon, Jul 16, 2012 at 1:00 PM, CCP4BB automatic digest system lists...@jiscmail.ac.uk wrote: Date:Mon, 16 Jul 2012 11:15:59 +0530 From:Biswajit Pal p...@ccmb.res.in Subject: Heme incorporation in expressed protein Dear all, Sorry for non-crystallography related question. We are trying to express an eukaryotic heme protein in E. coli. We are able to express it in soluble form. When we use 5-Aminolevulinic Acid, E. coli becomes brown. However, after cell lysis the soluble protein contains no heme and the pellet is brown. If we extract the pellet with detergent (Triton X-100 and Tween-20) the color comes in the supernatant, but there is no protein of our interest. These eventually indicate that the protein and heme are getting expressed/synthesized, but heme is not getting incorporated in the expressed protein. We would like to get this protein in heme-bound holo-form. Any suggestion to trouble-shoot this problem would be highly appreciated. Replies can be sent to me directly and I will post a summary on a later date. Thanks in advance, Sincerely yours, Biswajit Pal CCMB, Hyderabad, India
Re: [ccp4bb] Heme incorporation in expressed protein
Incomplete heme-incorporation in heme proteins expressed in E. coli. is a common issue. Check out the following paper for an easy method, which, in our experience, has solved all our issues regarding this problem. This has worked really well for many different heme-binding proteins (Cys / His ligated, mammalian / bacterial proteins) Protein Expr Purif. 2010 Sep;73(1):78-82. Co-expression of ferrochelatase allows for complete heme incorporation into recombinant proteins produced in E. coli. http://www.ncbi.nlm.nih.gov/pubmed/20303407 Jawahar Sudhamsu, Ph.D. 1 DNA Way, MS-27 Dept. of Structural Biology, Genentech Inc. South San Francisco, CA - 94080 On Mon, Jul 16, 2012 at 4:19 PM, Ho Leung Ng h...@hawaii.edu wrote: I was able to express a heme protein by inducing and expressing at room temperature and using a promoter weaker than T7 (can't remember the exact one right now). The key was to slow down the rate of protein production to allow heme incorporation. You might try using less IPTG too. Ho Leung Ng University of Hawaii at Manoa Assistant Professor, Department of Chemistry h...@hawaii.edu On Mon, Jul 16, 2012 at 1:00 PM, CCP4BB automatic digest system lists...@jiscmail.ac.uk wrote: Date:Mon, 16 Jul 2012 11:15:59 +0530 From:Biswajit Pal p...@ccmb.res.in Subject: Heme incorporation in expressed protein Dear all, Sorry for non-crystallography related question. We are trying to express an eukaryotic heme protein in E. coli. We are able to express it in soluble form. When we use 5-Aminolevulinic Acid, E. coli becomes brown. However, after cell lysis the soluble protein contains no heme and the pellet is brown. If we extract the pellet with detergent (Triton X-100 and Tween-20) the color comes in the supernatant, but there is no protein of our interest. These eventually indicate that the protein and heme are getting expressed/synthesized, but heme is not getting incorporated in the expressed protein. We would like to get this protein in heme-bound holo-form. Any suggestion to trouble-shoot this problem would be highly appreciated. Replies can be sent to me directly and I will post a summary on a later date. Thanks in advance, Sincerely yours, Biswajit Pal CCMB, Hyderabad, India
Re: [ccp4bb] co-express two proteins in E.coli
I have been using the Duet system from Novagen (or whatever it is called these days), specifically the pETDuet-1 and pRSFDuet-1. Co-expression of my proteins did not work in either vector. Either, one protein expressed or the other. I played around with the promotors (they are both T7) by changing one to the tac promotor. This increased the expression of this gene but shut off expression of the other. The only way I could get my proteins to co-express was to use pGEX vector with one protein, and pRSFDuet with the other protein (leaving the second MCS empty). There is a paper which sums up co-expression in E coli. http://www.nature.com/nmeth/journal/v3/n1/full/nmeth0106-55.html There is really absolutely no problem co-expressing two proteins both from near-identical pET vectors as long as the two plasmids carry difference selection marker. We've used pET24 in combination with pET28 or pET31 on several complexes and it always works as long as you keep both antibiotics around. - Dima
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
Re: [ccp4bb] co-express two proteins in E.coli
I fully agree with Dima. We are able to co-express and purify two interacting partners using pET28 and pET21 in E. coli. Some related references are : J. Mol. Biol. (2011) 405,49–64 J. Biol. Chem. (2006) 281, 26491–26500 J Struct Biol. (2011) 175(2):159-70 Biswajit - Original Message - From: Dima Klenchin klenc...@facstaff.wisc.edu To: CCP4BB@JISCMAIL.AC.UK Sent: Tuesday, July 17, 2012 5:16:34 AM Subject: Re: [ccp4bb] co-express two proteins in E.coli I have been using the Duet system from Novagen (or whatever it is called these days), specifically the pETDuet-1 and pRSFDuet-1. Co-expression of my proteins did not work in either vector. Either, one protein expressed or the other. I played around with the promotors (they are both T7) by changing one to the tac promotor. This increased the expression of this gene but shut off expression of the other. The only way I could get my proteins to co-express was to use pGEX vector with one protein, and pRSFDuet with the other protein (leaving the second MCS empty). There is a paper which sums up co-expression in E coli. http://www.nature.com/nmeth/journal/v3/n1/full/nmeth0106-55.html There is really absolutely no problem co-expressing two proteins both from near-identical pET vectors as long as the two plasmids carry difference selection marker. We've used pET24 in combination with pET28 or pET31 on several complexes and it always works as long as you keep both antibiotics around. - Dima
