[ccp4bb] Competition organised by the Scientist: Proteopedia voted first place
Dear ccp4bb subscribers, I have just learned that Proteopedia (the wikipedia-style encyclopedia of macromolecular structures) has been voted winner in this year's competition organized by the Scientist ( http://www.the-scientist.com/ , readers and judges choice). So thanks to all who voted, this only shows the importance of our beautiful structures. Some of the comments on the Scientist's web site: Very absorbing. Kept me looking (and learning) with it for a long time (Holmes) Very informative and a good resource (Kirby) So thanks to all who voted for our lovely structures, anything that can make our structures understood by as many people as possible and (possibly) bring back some funding to our Science is always welcome. Fred.
[ccp4bb] Sftools and Phaser compatibility issues - continued
Dear bulletin board, After downloading and recompiling the complete CCP4 package (we had the precompiled 32bits version on our 64bits machines) we were able to apply the patches of Claus and the problem case P21221 went through without problems. However, with the next problem case tested, things immediately went wrong again. The space group was R3 and phaser had written the following space group information in the mtz file: 146 'R 3 :H'. Attempts to change the space group with sftools to 'H 3' failed because sftools does not know 'H 3'. Resetting the space group 146 with sftools was successful, however, the name written in the mtz was R3. This prompted autobuster to try to reset the spacegroup to 'H 3' using sftools (with the results described above). I did a quick comparison of the space groups implemented in sftools and the CCP4 library, I found the following discrepancies and there are probably more: SFTOOLS CCP4 number name number namecomment -3P112 1003P112different space group numbers -4P1121 1004P1121 different space group numbers -5 A112 ?? not present in CCP4, probably 2005: A2 146 R3146 H3different setting 1146 R3146 setting of SFTOOLS -146R3R 1146R3R different entries with the same name -155R32R different entries with the same name 1155R32R 1155 R32different name All non-chiral and origin shifted space groups are missing from SFTOOLS. As Bart told us, sftools was made to ease the transition from the groningen biomol package to ccp4 and he added a lot of options to manipulate the reflection data. I find this options very useful e.g. to simulate the effects of lattice translocation disorder. In a private mail, Bart told me that he has currently little time to maintain sftools and since the program does all he needs, there is little incentive for him to put a lot of time in it. This leaves me, and probably many other ccp4 users, with the problem that sftools may produce incompatible mtz files, especially in problem and non-standard settings. These are exactly the cases where one would use a program like sftools. In my opinion, either sftools should be fixed to use the ccp4 library (they really did a wonderful job to implement all space groups and all settings!), or sftools should be labeled an unsupported program to be used at ones own risk. For general scripts like autobuster, one should then probably switch to supported programs. E.g. I solved the R3/H3 problem by using the reindex program to change the space group. The other question is: why does phaser write 'R 3 :H' in the mtz? When the problem with the P21221 space group first popped up last year, Randy told me that space group numbers like 2018 are non-standard, and that space group 18 with the name P21221 was the way to go. This is fair enough, but 'R 3 :H' is neither PDB nor ccp4 standard and I did not find it in the international tables. Is it maybe a phenix standard? Best regards, Herman -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Bart Hazes Sent: Wednesday, September 01, 2010 5:03 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Sftools can not handle non-standard settings? Hi Herman, As a former biomol user you might have guessed why. SFTOOLS found its origin as a transitional program helping the Groningen group move to the CCP4 mtz format. Since the Groningen MDF and CCP4 mtz had different ideas about space group symmetry and, especially, asymmetric unit definitions SFTOOLS needed to handle both. Since the biomol space group routine was basically a very large spaghetti of nested if-then-elses to accommodate all the peculiar choices I chose to reimplement using a simple set of symmetry generators and a matrix to define the asymmetric unit. Since there is no longer need to support MDF, sftools could switch to use the ccp4 library but my code is used for many other things, determining if a reflection is (a)centric, on a symmetry axis, should be systematically absent, expected intensity, convertion to standard asymmetric unit etc. So this will be a major undertaking. Alternatively, you can create a list of symmetry generators and add space groups as Claus has apparently already done. Bart On 10-09-01 05:39 AM, herman.schreu...@sanofi-aventis.com wrote: Dear Claus, Thank you very much for this patch. We will install it, and I hope CCP4 will install it quickly as well ;-). Still I do not understand why sftools has all symmetry operations hardcoded, while most other programs use the CCP4 libraries. In that way, sftools would always be up to date and would not need to be patched. Best, Herman -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Claus Flensburg Sent: Wednesday, September
Re: [ccp4bb] CCP4 6.1.13 and ARP/wARP 7.1
Dear All hopefully the fix for modules.def is now in the source and binaries for ccp4 6.1.13 Charles Ballard CCP4 On 30 Aug 2010, at 18:06, ger...@embl-hamburg.de wrote: Dear Colleagues, some of you might have noticed that ARP/wARP does not install cleanly with the latest version of CCP4, 6.1.13. We did some experiments ourselves and can confirm the observation of an incomplete installation that is only partly functional, the lack of the possibility of manual deinstallation and the following error message that appears at the time of running the ARP/wARP 'install.sh' script: can't read getcontentlist_array(TASK_MODULE,206): no such element in array NOTE: You can skip the next paragraph if you're not interested in how I reproduced the error and proceed to a bug fix. Sorry for the long paragraph. Two scenarios of CCP4+ARP/wARP installation were tested: Mac OSX 10.5 and Ubuntu Linux 9, x86_64. Both the latest versions of both softwares. The download of CCP4 was made from ccp4.ac.uk, a typical installation chosen, which included also the tclsh/bltwish components that the GUI depends on. The dmg-installer was used on the Mac to install into the folder /Applications, on Linux the downloaded file was just untarred in a folder of choice followed by running CCP4's 'install.sh'. The 'ccp4.setup_sh/csh' file was placed into the user's shell config file by sourcing it there: '.bashrc', '.cshrc', '.tcshrc' depending on the shell used. Starting from a terminal that has the new CCP4 environment setup, the ARP/wARP installation could be done. On the Mac however it is more complicated because the superuser owns the installation. Through 'sudo xterm' and in there 'source ~user/.cshrc' (to be replaced by your settings) the ccp4 environment is setup for the superuser. In both cases (on the Mac as superuser) 'cd' to the ARP/wARP folder, e.g. arp_warp_7.1, and run ARP/wARP's 'install.sh'. This script tries to install ARP/wARP into the CCP4 GUI automatically and this is where problems start. The error message from above, the 'Program List' contains no buttons from the installation, these are just in 'Model Building', manual deinstallation is not possible, the new tasks don't seem to be registered with the CCP4 GUI. The fix: The tcl-files that control the installation of a new software module read the file '$CCP4I_TOP/etc/UNIX/modules.def'. This file seems to have a line missing: In the block of 'TASK_MODULE' lines (around line 500) the entry 'TASK_MODULE,206 programlist' is missing. Please add it there at about the right place. Rerun the ARP/wARP installation and the error message should be gone, the installation should be complete, i.e. ARP/wARP buttons in 'program list', too, and the possibility of manual deinstallation. I hope this is helpful. Cheers, Gerrit.
Re: [ccp4bb] Sftools and Phaser compatibility issues - continued
I'm sure it would be a good thing if SFTOOLS recognised all possible space groups, but I wonder why you are using SFTOOLS at all. I've almost never had the need to use it myself. Space group changes and many other things can be done with CAD for example Phil On 2 Sep 2010, at 13:31, herman.schreu...@sanofi-aventis.com wrote: Dear bulletin board, After downloading and recompiling the complete CCP4 package (we had the precompiled 32bits version on our 64bits machines) we were able to apply the patches of Claus and the problem case P21221 went through without problems. However, with the next problem case tested, things immediately went wrong again. The space group was R3 and phaser had written the following space group information in the mtz file: 146 'R 3 :H'. Attempts to change the space group with sftools to 'H 3' failed because sftools does not know 'H 3'. Resetting the space group 146 with sftools was successful, however, the name written in the mtz was R3. This prompted autobuster to try to reset the spacegroup to 'H 3' using sftools (with the results described above). I did a quick comparison of the space groups implemented in sftools and the CCP4 library, I found the following discrepancies and there are probably more: SFTOOLS CCP4 number name number namecomment -3P112 1003P112different space group numbers -4P1121 1004P1121 different space group numbers -5 A112 ?? not present in CCP4, probably 2005: A2 146 R3146 H3different setting 1146 R3146 setting of SFTOOLS -146R3R 1146R3R different entries with the same name -155R32R different entries with the same name 1155R32R 1155 R32different name All non-chiral and origin shifted space groups are missing from SFTOOLS. As Bart told us, sftools was made to ease the transition from the groningen biomol package to ccp4 and he added a lot of options to manipulate the reflection data. I find this options very useful e.g. to simulate the effects of lattice translocation disorder. In a private mail, Bart told me that he has currently little time to maintain sftools and since the program does all he needs, there is little incentive for him to put a lot of time in it. This leaves me, and probably many other ccp4 users, with the problem that sftools may produce incompatible mtz files, especially in problem and non-standard settings. These are exactly the cases where one would use a program like sftools. In my opinion, either sftools should be fixed to use the ccp4 library (they really did a wonderful job to implement all space groups and all settings!), or sftools should be labeled an unsupported program to be used at ones own risk. For general scripts like autobuster, one should then probably switch to supported programs. E.g. I solved the R3/H3 problem by using the reindex program to change the space group. The other question is: why does phaser write 'R 3 :H' in the mtz? When the problem with the P21221 space group first popped up last year, Randy told me that space group numbers like 2018 are non-standard, and that space group 18 with the name P21221 was the way to go. This is fair enough, but 'R 3 :H' is neither PDB nor ccp4 standard and I did not find it in the international tables. Is it maybe a phenix standard? Best regards, Herman -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Bart Hazes Sent: Wednesday, September 01, 2010 5:03 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Sftools can not handle non-standard settings? Hi Herman, As a former biomol user you might have guessed why. SFTOOLS found its origin as a transitional program helping the Groningen group move to the CCP4 mtz format. Since the Groningen MDF and CCP4 mtz had different ideas about space group symmetry and, especially, asymmetric unit definitions SFTOOLS needed to handle both. Since the biomol space group routine was basically a very large spaghetti of nested if-then-elses to accommodate all the peculiar choices I chose to reimplement using a simple set of symmetry generators and a matrix to define the asymmetric unit. Since there is no longer need to support MDF, sftools could switch to use the ccp4 library but my code is used for many other things, determining if a reflection is (a)centric, on a symmetry axis, should be systematically absent, expected intensity, convertion to standard asymmetric unit etc. So this will be a major undertaking. Alternatively, you can create a list of symmetry generators and add space groups as Claus has apparently already done. Bart On 10-09-01 05:39 AM, herman.schreu...@sanofi-aventis.com wrote: Dear Claus, Thank you very much for this patch. We will install it, and I hope
Re: [ccp4bb] Sftools and Phaser compatibility issues - continued
Dear Phil, CAD would also be an excellent alternative. I used REINDEX which also worked. The point I tried to make is that if people do not know that SFTOOLS is not up to date, they may use it in good faith and get into trouble. If they know it, they might use it to hack an mtz file when neccessary, but use other program for more serious purposes. Herman -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Phil Evans Sent: Thursday, September 02, 2010 3:02 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Sftools and Phaser compatibility issues - continued I'm sure it would be a good thing if SFTOOLS recognised all possible space groups, but I wonder why you are using SFTOOLS at all. I've almost never had the need to use it myself. Space group changes and many other things can be done with CAD for example Phil On 2 Sep 2010, at 13:31, herman.schreu...@sanofi-aventis.com wrote: Dear bulletin board, After downloading and recompiling the complete CCP4 package (we had the precompiled 32bits version on our 64bits machines) we were able to apply the patches of Claus and the problem case P21221 went through without problems. However, with the next problem case tested, things immediately went wrong again. The space group was R3 and phaser had written the following space group information in the mtz file: 146 'R 3 :H'. Attempts to change the space group with sftools to 'H 3' failed because sftools does not know 'H 3'. Resetting the space group 146 with sftools was successful, however, the name written in the mtz was R3. This prompted autobuster to try to reset the spacegroup to 'H 3' using sftools (with the results described above). I did a quick comparison of the space groups implemented in sftools and the CCP4 library, I found the following discrepancies and there are probably more: SFTOOLS CCP4 number name number namecomment -3P112 1003P112different space group numbers -4P1121 1004P1121 different space group numbers -5 A112 ?? not present in CCP4, probably 2005: A2 146 R3146 H3different setting 1146 R3146 setting of SFTOOLS -146R3R 1146R3R different entries with the same name -155R32R different entries with the same name 1155R32R 1155 R32different name All non-chiral and origin shifted space groups are missing from SFTOOLS. As Bart told us, sftools was made to ease the transition from the groningen biomol package to ccp4 and he added a lot of options to manipulate the reflection data. I find this options very useful e.g. to simulate the effects of lattice translocation disorder. In a private mail, Bart told me that he has currently little time to maintain sftools and since the program does all he needs, there is little incentive for him to put a lot of time in it. This leaves me, and probably many other ccp4 users, with the problem that sftools may produce incompatible mtz files, especially in problem and non-standard settings. These are exactly the cases where one would use a program like sftools. In my opinion, either sftools should be fixed to use the ccp4 library (they really did a wonderful job to implement all space groups and all settings!), or sftools should be labeled an unsupported program to be used at ones own risk. For general scripts like autobuster, one should then probably switch to supported programs. E.g. I solved the R3/H3 problem by using the reindex program to change the space group. The other question is: why does phaser write 'R 3 :H' in the mtz? When the problem with the P21221 space group first popped up last year, Randy told me that space group numbers like 2018 are non-standard, and that space group 18 with the name P21221 was the way to go. This is fair enough, but 'R 3 :H' is neither PDB nor ccp4 standard and I did not find it in the international tables. Is it maybe a phenix standard? Best regards, Herman -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Bart Hazes Sent: Wednesday, September 01, 2010 5:03 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Sftools can not handle non-standard settings? Hi Herman, As a former biomol user you might have guessed why. SFTOOLS found its origin as a transitional program helping the Groningen group move to the CCP4 mtz format. Since the Groningen MDF and CCP4 mtz had different ideas about space group symmetry and, especially, asymmetric unit definitions SFTOOLS needed to handle both. Since the biomol space group routine was basically a very large spaghetti of nested if-then-elses to accommodate all the peculiar choices I chose to reimplement using a simple set of symmetry generators and a matrix to
Re: [ccp4bb] Sftools and Phaser compatibility issues - continued
On Thu, Sep 2, 2010 at 5:31 AM, herman.schreu...@sanofi-aventis.com wrote: The other question is: why does phaser write 'R 3 :H' in the mtz? When the problem with the P21221 space group first popped up last year, Randy told me that space group numbers like 2018 are non-standard, and that space group 18 with the name P21221 was the way to go. This is fair enough, but 'R 3 :H' is neither PDB nor ccp4 standard and I did not find it in the international tables. Is it maybe a phenix standard? No, it pre-dates Phenix - it's the extended Hermann Mauguin symbol, whatever that means: http://www.ccp4.ac.uk/html/symmetry.html I don't know why it's used preferentially in Phenix, but in theory it's supported by CCP4 programs, except those which are still using the older symmetry information. syminfo.lib has the correct information (space group number 146), symop.lib does not. As previously noted the last time this discussion came up (December, if memory serves), Coot also uses this notation: http://www.biop.ox.ac.uk/coot/doc/coot/Reading-coordinates.html -Nat
Re: [ccp4bb] Sftools and Phaser compatibility issues - continued
Well, CCP4 programs using the core libraries should ignore the spacegroup symbol and use the operators instead, which bypasses the whole problem. I would advise anyone using the CCP4 libraries in their own programs to do the same. That works for mtz and map, but not for pdb files of course. Kevin Nat Echols wrote: On Thu, Sep 2, 2010 at 5:31 AM, herman.schreu...@sanofi-aventis.com mailto:herman.schreu...@sanofi-aventis.com wrote: The other question is: why does phaser write 'R 3 :H' in the mtz? When the problem with the P21221 space group first popped up last year, Randy told me that space group numbers like 2018 are non-standard, and that space group 18 with the name P21221 was the way to go. This is fair enough, but 'R 3 :H' is neither PDB nor ccp4 standard and I did not find it in the international tables. Is it maybe a phenix standard? No, it pre-dates Phenix - it's the extended Hermann Mauguin symbol, whatever that means: http://www.ccp4.ac.uk/html/symmetry.html I don't know why it's used preferentially in Phenix, but in theory it's supported by CCP4 programs, except those which are still using the older symmetry information. syminfo.lib has the correct information (space group number 146), symop.lib does not. As previously noted the last time this discussion came up (December, if memory serves), Coot also uses this notation: http://www.biop.ox.ac.uk/coot/doc/coot/Reading-coordinates.html -Nat -- EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm
Re: [ccp4bb] Sftools and Phaser compatibility issues - continued
FYI -- The :h suffix for R3 is described in the IUCr symmetry cif (intl tables vol G chapter 4.7) under _space_group.reference_setting where it states For the space groups where more than one setting is given in International Tables, the following choices have been made. For monoclinic space groups: unique axis b and cell choice 1. For space groups with two origins: origin choice 2 (origin at inversion centre, indicated by adding :2 to the Hermann-Mauguin symbol in the enumeration list). For rhombohedral space groups: hexagonal axes (indicated by adding :h to the Hermann-Mauguin symbol in the enumeration list). http://it.iucr.org/Ga/ch4o7v0001/ch4o7.pdf http://www.iucr.org/resources/cif/dictionaries/cif_sym The H3 / H32 designations are PDB conventions/standards. In the PDB format description it states that For a rhombohedral space group in the hexagonal setting, the lattice type symbol used is H. From an archive of the PDB documentation at the University of Washington, there is list of changes by PDB version that suggests that the PDB introduced the H designation with the release of PDB format v2.0 (sometime around March 1997) see http://www.bmsc.washington.edu/CrystaLinks/man/pdb/guide2.2_frame.html http://www.bmsc.washington.edu/CrystaLinks/man/pdb/part_6.html The RCSB's archive of the 2.2 format gives a file not found error. http://www.rcsb.org/pdb/docs/format/pdbguide2.2/guide2.2_frame.html Regards, Mitch -Original Message-- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Nat Echols Sent: Thursday, September 02, 2010 8:06 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Sftools and Phaser compatibility issues - continued On Thu, Sep 2, 2010 at 5:31 AM, herman.schreu...@sanofi-aventis.com wrote: The other question is: why does phaser write 'R 3 :H' in the mtz? When the problem with the P21221 space group first popped up last year, Randy told me that space group numbers like 2018 are non-standard, and that space group 18 with the name P21221 was the way to go. This is fair enough, but 'R 3 :H' is neither PDB nor ccp4 standard and I did not find it in the international tables. Is it maybe a phenix standard? No, it pre-dates Phenix - it's the extended Hermann Mauguin symbol, whatever that means: http://www.ccp4.ac.uk/html/symmetry.html I don't know why it's used preferentially in Phenix, but in theory it's supported by CCP4 programs, except those which are still using the older symmetry information. syminfo.lib has the correct information (space group number 146), symop.lib does not. As previously noted the last time this discussion came up (December, if memory serves), Coot also uses this notation: http://www.biop.ox.ac.uk/coot/doc/coot/Reading-coordinates.html -Nat
[ccp4bb] How to automatically answer NO to SFTOOLS reading in a shell script?
Hi, I am reading a ccp4 mtz file using SFTOOLS. It asked me Is this an XPLOR RFREE flag column?. First I assume the answer is NO, since the input is a CCP4 mtz file although the colume is for free-flags. Then, I am wondering what is the script to automatically answer NO in a shell script. Thanks! Best Regards, Hailiang
Re: [ccp4bb] How to automatically answer NO to SFTOOLS reading in a shell script?
Hi Hailiang sftools was first and foremost designed to be used interactively, that is why it tends to follow a question and answer user interface. Of course you can use sftools in scripts but if it pops up a question that was not anticipated, the script it will crash. There could be a batch mode where you give sftools permission to make a best guess but guessing can be dangerous. In your particular case, XPLOR uses a flag=1 for rfree reflections and 0 for working set reflections while CCP4 MTZ by default uses a flag=0 for rfree reflections and non-zero for working set reflections. If sftools encounters an mtz that appears to use the XPLOR definition it gives a warning and suggests to convert to the CCP4 definition. For proper MTZ files this should not happen and if it does happen maybe you should find out why. Bart On 10-09-02 02:00 PM, Hailiang Zhang wrote: Hi, I am reading a ccp4 mtz file using SFTOOLS. It asked me Is this an XPLOR RFREE flag column?. First I assume the answer is NO, since the input is a CCP4 mtz file although the colume is for free-flags. Then, I am wondering what is the script to automatically answer NO in a shell script. Thanks! Best Regards, Hailiang -- Bart Hazes (Associate Professor) Dept. of Medical Microbiology Immunology University of Alberta 1-15 Medical Sciences Building Edmonton, Alberta Canada, T6G 2H7 phone: 1-780-492-0042 fax:1-780-492-7521
Re: [ccp4bb] How to automatically answer NO to SFTOOLS reading in a shell script?
GOt it! Thanks! Best REgards, Hailiang Hi Hailiang sftools was first and foremost designed to be used interactively, that is why it tends to follow a question and answer user interface. Of course you can use sftools in scripts but if it pops up a question that was not anticipated, the script it will crash. There could be a batch mode where you give sftools permission to make a best guess but guessing can be dangerous. In your particular case, XPLOR uses a flag=1 for rfree reflections and 0 for working set reflections while CCP4 MTZ by default uses a flag=0 for rfree reflections and non-zero for working set reflections. If sftools encounters an mtz that appears to use the XPLOR definition it gives a warning and suggests to convert to the CCP4 definition. For proper MTZ files this should not happen and if it does happen maybe you should find out why. Bart On 10-09-02 02:00 PM, Hailiang Zhang wrote: Hi, I am reading a ccp4 mtz file using SFTOOLS. It asked me Is this an XPLOR RFREE flag column?. First I assume the answer is NO, since the input is a CCP4 mtz file although the colume is for free-flags. Then, I am wondering what is the script to automatically answer NO in a shell script. Thanks! Best Regards, Hailiang -- Bart Hazes (Associate Professor) Dept. of Medical Microbiology Immunology University of Alberta 1-15 Medical Sciences Building Edmonton, Alberta Canada, T6G 2H7 phone: 1-780-492-0042 fax:1-780-492-7521
[ccp4bb] to back-soak or not to back-soak
Hi, I recently collected a MAD dataset on one of my xtals soaked in ~7mM KAuCN2 for 1.5 days. I had backsoaked these xtals prior to freezing and the signal seems to be faint. I was wondering if it would help not back-soaking xtals. I would be grateful for any comments/suggestions. thanks, -- Amit Sharma, Postdoctoral Fellow, Department of Biophysics, Johns Hopkins University, Baltimore, MD21218
Re: [ccp4bb] microseeding SeMet drops with native xtal seeds
See the following publication for an interesting method to resolve pseudo-merohedral twinning in SeMet crystals: Cansizoglu, A. E. and Chook, Y. M. (2007) Conformational heterogeneity of Karyopherinβ2 is segmental. Structure, 15(11):1431-1441. In an effort to obtain single selenomethionine Kapβ2 crystals, mixtures of selenomethionine and native proteins were crystallized. A 1:1 molar mixture of the two proteins gave single crystals... Diana On Sep 1, 2010, at 10:37 PM, amit sharma wrote: Dear All, My SeMet protein crystals have a needle-like morphology, worse than that of the native xtals. Also, although the cell dimensions of both forms is very much similar, the SeMet xtals are twinned(as indicated by Ctruncate plots). I was wondering if such cases were commonly seen, also is it alright to microseed my SeMet protein drops with seeds from the native xtal. I would be grateful if someone could shed light on this. thanks in advance, -- Amit Sharma, Postdoctoral Fellow, Department of Biophysics, Johns Hopkins University, Baltimore, MD21218 * * * * * * * * * * * * * * * * * * * * * * * * * * * * Diana R. Tomchick Associate Professor University of Texas Southwestern Medical Center Department of Biochemistry 5323 Harry Hines Blvd. Rm. ND10.214B Dallas, TX 75390-8816, U.S.A. Email: diana.tomch...@utsouthwestern.edu 214-645-6383 (phone) 214-645-6353 (fax)
[ccp4bb] Confirming expression of a GPCR in HEK293
Dear All, Apologies for a non-ccp4 question. I am planning to express a GPCR in HEK293T cell line by transfecting with the requisite cDNA for performing an assay. I would like to confirm the expression of the protein in the cell line by western blot or histochemical studies. Any pointers in this regard would be helpful. Thanks, Qing Lu
Re: [ccp4bb] Confirming expression of a GPCR in HEK293
If I were you, I would just make a gfp-tagged construct--this is an easy way to make sure that the protein is there, and made it to the membrane. If necessary, you can blot for gfp, or add other tags in the process for alternative blotting (one on each side to make sure it is not cleaved, for example.) Jacob - Original Message - From: Qing Lu To: CCP4BB@JISCMAIL.AC.UK Sent: Thursday, September 02, 2010 7:42 PM Subject: [ccp4bb] Confirming expression of a GPCR in HEK293 Dear All, Apologies for a non-ccp4 question. I am planning to express a GPCR in HEK293T cell line by transfecting with the requisite cDNA for performing an assay. I would like to confirm the expression of the protein in the cell line by western blot or histochemical studies. Any pointers in this regard would be helpful. Thanks, Qing Lu *** Jacob Pearson Keller Northwestern University Medical Scientist Training Program Dallos Laboratory F. Searle 1-240 2240 Campus Drive Evanston IL 60208 lab: 847.491.2438 cel: 773.608.9185 email: j-kell...@northwestern.edu ***
Re: [ccp4bb] Confirming expression of a GPCR in HEK293
Hi Qing, I would recommend either the use of GFP as mentioned by Jacob or a his-tag or a flag-tag. C-terminal tagging is preferred to prevent interference with signal sequences at the N-terminus of the protein. Flag tag is really good for detection , the commercial antibodies for detection are really great, however it is not that great, in my hands, when it comes to purification of a membrane protein (in presence of detergent) I prefer his-tags to flag-tags in this case. You can use a his-flag to combine both advantages. Hope this helps -- Pascal F. Egea, PhD Assistant Professor UCLA, David Geffen School of Medicine Department of Biological Chemistry 314 Biomedical Sciences Research Building office (310)-983-3515 lab (310)-983-3516 email pe...@mednet.ucla.edu
[ccp4bb] fit a peptide in isolated density
In an isolated piece of density, I want to fit a 7AA peptide fragment from a protein. Only the sequence of the whole protein (200AA) is known, and I don't know the peptide sequence. I think it's best to try from the beginning of the whole sequence to the end. So is there any software or scripts which can do this automatically? The resolution is 2.3A. Waiting for your reply! Thank you!
