Re: [ccp4bb] raw data deposition
Generally during these rigorous bb debates I prefer to stay silent and absorb all the information possible so that I can make an informed decision later on. I fear that I am compelled to contribute in this instance. In regards to the does this make a difference in the biological interpretation stage issue, I can state that it does. In my comparatively miniscule career I have run into this issue three times. The first two address Adrian's point... And (b) even if they do, is this continual improvement even worthwhile? I am always depressed at how little a model changes from an initial build to the final one, even when the rfree drops from 35 to 23. All that work! - and my biological interpretation would have been almost the same at the beginning as at the end. In one instance I adopted an orphaned structure and ran it through a slightly more advanced refinement protocol (on the same structure factors) and ended up with a completely different story than the one I started with [1]. Another researcher in my grad lab identified mis-oriented catalytic residues in an existing structure from EDS server maps which affects the biochemistry of the catalytic mechanism [2]. In another case I decided that I would reprocess some images that I had originally indexed and scaled in my Ooo buttons clicky clicky stage of learning crystallography and the improved structure factors revealed a alternate conformations for both a critical loop and ligand orientation [3]. And this was all in the last 4 years. So I would posit that the answer is yes there are significant biological insights to be had with the capacity to reassess data in any form. Katherine [1] J Phys Chem Lett. 2010 Oct 7;1(19):2898-2902 [2] Acta Crystallogr D Biol Crystallogr. 2009 Mar;65(Pt 3):294-6. [3] Manuscript in progress Katherine Sippel, PhD Postdoctoral Associate Baylor College of Medicine
Re: [ccp4bb] raw data deposition
Dear colleagues, my opinion is that we should develop methods or approaches to validate !processing! of raw data. If this is possible. We have many validation tools for structure refinement, but no tool to validate data processing. In case we have this tools, there is no need to deposit diffraction images (2-5GB instead of 10 MB). I think. Of course, how to validate this? This might be topic for a new discussion. I am sure, that in the very beginning of crystallography, there were no tools to validate the structures as well. I am also sure that some opinions may arise today. (Online server, where one can upload the images with log files from processing?) We should concentrate more on quality of our outcome, than on storage of these data. Petr 2011/10/28 Katherine Sippel katherine.sip...@gmail.com: Generally during these rigorous bb debates I prefer to stay silent and absorb all the information possible so that I can make an informed decision later on. I fear that I am compelled to contribute in this instance. In regards to the does this make a difference in the biological interpretation stage issue, I can state that it does. In my comparatively miniscule career I have run into this issue three times. The first two address Adrian's point... And (b) even if they do, is this continual improvement even worthwhile? I am always depressed at how little a model changes from an initial build to the final one, even when the rfree drops from 35 to 23. All that work! - and my biological interpretation would have been almost the same at the beginning as at the end. In one instance I adopted an orphaned structure and ran it through a slightly more advanced refinement protocol (on the same structure factors) and ended up with a completely different story than the one I started with [1]. Another researcher in my grad lab identified mis-oriented catalytic residues in an existing structure from EDS server maps which affects the biochemistry of the catalytic mechanism [2]. In another case I decided that I would reprocess some images that I had originally indexed and scaled in my Ooo buttons clicky clicky stage of learning crystallography and the improved structure factors revealed a alternate conformations for both a critical loop and ligand orientation [3]. And this was all in the last 4 years. So I would posit that the answer is yes there are significant biological insights to be had with the capacity to reassess data in any form. Katherine [1] J Phys Chem Lett. 2010 Oct 7;1(19):2898-2902 [2] Acta Crystallogr D Biol Crystallogr. 2009 Mar;65(Pt 3):294-6. [3] Manuscript in progress Katherine Sippel, PhD Postdoctoral Associate Baylor College of Medicine -- Petr Kolenko kole...@imc.cas.cz http://kolda.webz.cz
Re: [ccp4bb] Weird blob appears
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Jacob, On 10/28/2011 03:46 AM, Jacob Keller wrote: Blob is gone--something funny happened, I guess. I went back to using the original mtz from scala, removed and replaced a bunch of waters, ^^^ maybe that solves your question: You should always use the same file as input, i.e., should never have used anything but the original mtz from scala...? Tim [...] - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOqlw/UxlJ7aRr7hoRAnqNAKDmtXDRfufug9xYcgrCcQ5U7e7HbgCggpqs FQewmDYxkJivxPXXnSmi524= =6Job -END PGP SIGNATURE-
Re: [ccp4bb] refmac 5.6 ccp4 6.2.0
Hi Kenneth, This looks like an off-by-one bug in the restraint generation. Typical sources are weird LINKs, wrong atom names and bad luck. I suggest you make sure you have the very latest Refmac and dictionary and try setting up a new refinement instead of recycling an old job. If that doesn't work, we may need a closer look at your input model. Cheers, Robbie Date: Thu, 27 Oct 2011 20:48:49 -0500 From: satys...@wisc.edu Subject: [ccp4bb] refmac 5.6 ccp4 6.2.0 To: CCP4BB@JISCMAIL.AC.UK Has anyone had problems with Refmac 5.6? I tried refining our stucture at 1.24 A, aniso with H in riding position and it just exploded! I get error in distances such as Standard External All Bonds: 3270 0 3270 Angles: 4923 0 4923 Chirals: 214 0 214 Planes: 368 0 368 Torsions: 957 0 957 --- Number of reflections in file 90428 Number of reflections read 90428 CGMAT cycle number = 1 Bond distance outliers Bond distance deviations from the ideal 10.000Sigma will be monitored A 5 PRO C A - A 5 PRO HB1 A mod.= 3.344 id.= 1.329 dev= -2.015 sig.= 0.014 A 5 PRO C B - A 5 PRO HB1 B mod.= 2.997 id.= 1.329 dev= -1.668 sig.= 0.014 A 5 PRO HB1 A - A 5 PRO HG1 A mod.= 2.292 id.= 1.458 dev= -0.834 sig.= 0.021 A 5 PRO HB1 A - A 6 LEU HD23A mod.= 7.407 id.= 0.860 dev= -6.547 sig.= 0.020 A 5 PRO HB1 B - A 5 PRO HG1 B mod.= 2.247 id.= 1.458 dev= -0.789 sig.= 0.021 A 5 PRO HB1 B - A 6 LEU HD23B mod.= 6.529 id.= 0.860 dev= -5.669 sig.= 0.020 A 5 PRO HG1 A - A 5 PRO HD1 A mod.= 2.267 id.= 0.980 dev= -1.287 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU N A mod.= 4.860 id.= 1.530 dev= -3.330 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU HD21A mod.= 6.129 id.= 1.525 dev= -4.604 sig.= 0.021 A 5 PRO HG1 B - A 5 PRO HD1 B mod.= 2.236 id.= 0.980 dev= -1.256 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU N B mod.= 4.922 id.= 1.530 dev= -3.392 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU HD21B mod.= 6.664 id.= 1.525 dev= -5.139 sig.= 0.021 A 6 LEU N A - A 6 LEU CA A mod.= 1.467 id.= 0.970 dev= -0.497 sig.= 0.020 A 6 LEU N A - A 6 LEU HA A mod.= 2.005 id.= 0.970 dev= -1.035 sig.= 0.020 A 6 LEU N A - A 6 LEU CB A mod.= 2.497 id.= 1.530 dev= -0.967 sig.= 0.020 A 6 LEU N B - A 6 LEU CA B mod.= 1.469 id.= 0.970 dev= -0.499 sig.= 0.020 A 6 LEU N B - A 6 LEU HA B mod.= 2.032 id.= 0.970 dev= -1.062 sig.= 0.020 A 6 LEU N B - A 6 LEU CB B mod.= 2.446 id.= 1.530 dev= -0.916 sig.= 0.020 A 6 LEU CB A - A 6 LEU HB2 A mod.= 0.969 id.= 1.521 dev= 0.552 sig.= 0.020 A Rfree goes form 17 to 28 and R from 15 to 25. Coot map looks like a bunch of busted insect parts. I use the exact same input using ccp4 6.1.13 and Refmac 5.5 and all is good. I am forced to use the old ccp4 and refmac to publish. Rf 17 R 15. thanks -- Kenneth A. Satyshur, M.S.,Ph.D. Associate Scientist University of Wisconsin Madison, Wisconsin 53706 608-215-5207
[ccp4bb] postdoctoral position Warsaw
The group of Dr. Marcin Nowotny at the International Institute of Molecular and Cell Biology (IIMCB) in Warsaw, Poland is seeking candidates for postdoctoral fellows. The fellows will work on protein complexes involved in DNA repair using protein crystallography and protein biochemistry (for examples of our previous work please see: Jaciuk M. et al. Nat. Struct. Mol. Biol. 18(2):191-7 and Rychlik M.P., et al. Mol. Cell 40(4):658-70). Further information about IIMCB can be found at: http://www.iimcb.gov.pl. The Institute has state-of-the-art equipment and facilities, including crystallization robots, an automated crystallization station and a microfocus home X-ray source. The positions are funded through an ERC Starting Grant and are available for up to five years starting in January 2012. The candidates should hold a Ph. D. degree, must be motivated, well-organized and able to work independently as well as a part of the team. Experience with protein expression, purification and biochemical characterization is required. Knowledge and experience in protein crystallography will be an advantage. The candidates should send their detailed CV to mnowo...@iimb.gov.plmailto:mnowo...@iimb.gov.pl with reference contact information. Closing date for applications is December 5th 2001.
Re: [ccp4bb] PDB header info wrong.
Dear Ian, Truncating the data to 10A and then filling in the missing hkl values and including them with Fo replaced by e.g. DFc is an established way of improving the maps (at the cost of a little model bias), but the novel twist in your example was the assignment of R-free flags to these missing reflections. Does this also lead to a reduction in the free R?! Best wishes, George On Fri, Oct 28, 2011 at 09:47:26AM +0200, Tim Gruene wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Ian, 10.00A sounds very much like somebody used shelxpro to create an ins-file from a PDB file and did not correct the SHEL card to include low resolution data. So the data may well contain data at 84A, but shelx does not use the data if the SHEL card is left at its default (10 0.1). Cheers, Tim P.S.: obvious can be just a dangerous word as trivial... On 10/27/2011 09:31 PM, Ian Tickle wrote: Hi, currently Refmac writes the wrong info for the low resolution cutoff, for example: REMARK 3 PROGRAM : REFMAC 5.6.0119 REMARK 3 DATA USED IN REFINEMENT. REMARK 3 RESOLUTION RANGE HIGH (ANGSTROMS) : 1.00 REMARK 3 RESOLUTION RANGE LOW (ANGSTROMS) : 84.35 In contrast Shel-X puts in: REMARK 3 RESOLUTION RANGE LOW (ANGSTROMS) : 10.00 The mtzdump of the MTZ file shows: 1 NONE -83 0 0 100.00-27.0 27.0 84.35 1.00 H H 2 NONE 0 97 0 100.00 54.9 54.9 84.35 1.00 H K 3 ASC 0 83 0 100.00 31.0 31.0 84.35 1.00 H L 4 NONE0.0 1.0 0 100.00 0.95 0.95 84.35 1.00 I FREE 5 NONE0.0 2071.8 435 99.82 125.22 125.22 10.00 1.00 F FP 6 NONE0.990.0 435 99.82 2.73 2.73 10.00 1.00 Q SIGFP So obviously what has happened is that the Free R flags have been generated to the high resolution cutoff and the low-res reflections, i.e. below 10 Ang only have HKL FREE defined. Somewhere along the line (this is data from the PDB) the low-res F's were lost. So IMO one cannot claim that these data were used in refinement. Getting tthe low-res cutoff wrong has a big effect on the electron density that one expects for a given resolution range! It seems to me that it would be preferable to omit information rather than risk putting in the wrong value, at least then one would know to go find the info somewhere else. Cheers -- Ian - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOql4OUxlJ7aRr7hoRAurhAKCFuKzPjt9uGKlg38/PlIPvEYyK0QCfW3r5 uOugyeB1TLn8WBjI5cHz66Q= =72lY -END PGP SIGNATURE- -- Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582
Re: [ccp4bb] raw data deposition
D Bonsor wrote: and allow someone else to have ago at solving the structure. I'd be careful there if there was a motion to try to implement a policy at SR sources (for academic research projects) to make it compulsory to publically release all data frames after a period (1 year ? 2 years ? 4 years) during which you are supposed to solve the structures you have collected the data for, so that others can have a go at it (and solve the structures for you): you may find yourself for example in between grants and need to spend all of your time looking for funding for a couple of years, with little or no staff working with you. With the trend we see of ever diminishing resources, this would mean that the very large and well funded labs and groups would solve their own structures, and solve those of smaller groups as well (and publish the latter). This would then mean (after a while) the concentration of macromolecular crystallography to only the lucky few who have managed to secure large grants and will therefore go-on securing such grants. You could call that evolution I suppose. We are already in a situation where the crystallographers who solved the structures are not necessarily authors on the publications reporting the structures... so is it time to go back to home sources (X-ray generators) for data collection ? Fred.
[ccp4bb] scalepack2mtz for trigonal crystal
Dear colleagues We obtained the trigonal crystals (s.g. R3 or R32). We processed X-ray intensity data using HKL2000, which chose the hexagonal axes (a=b; alpha=beta=90, gamma=120). Then we tried converting the data to mtz using scalepack2mtz, but received an error message. LW: severe warning - specified symmetry not consistent with cell dimensions! SCALEPACK2MTZ: Error in space group or cell dimensions. So we could not convert the data. My questions are Does scalepack2mtz accept only rhombohedral axes for the trigonal crystal system? Why is it(if yes)? Do we have to reindex the intensity data? Best regards ~ Masaki UNNO, Ph.D. Frotier Research Center for Applied Atomic Sciences, Ibaraki University Ibaraki Quantum Beam Research Center 162-1 Shirakata, Tokai, Naka, Ibaraki 319-1106, Japan Tel: 029-352-3239, Fax: 029-287-7872 E-mail: unn...@mx.ibaraki.ac.jp HP: http://www.fas.ibaraki.ac.jp/?page_id=961 ~
Re: [ccp4bb] raw data deposition
Dear Fred, Frankly, with respect, this sounds to me like fanciful and rather non-sensical paranoia. The time frame for public disclosure of all SR data has been quoted at 5 years, or something of that order. If someone has been unable to solve a structure 5 years after having collected data on it, then it does make perfect sense that he/she be rescued in one way or another. Any responsible scientist in that situation would have called for specialist help long before then, and having failed to do so would indicate a loss of interest in the project anyway. This is again the type of argument that strays away from a serious question by throwing decoys around the place. Of course such views must be heard, but so should the counter-arguments of those who disagree with them. With best wishes, Gerard. -- On Fri, Oct 28, 2011 at 10:42:25AM +0200, Vellieux Frederic wrote: D Bonsor wrote: and allow someone else to have ago at solving the structure. I'd be careful there if there was a motion to try to implement a policy at SR sources (for academic research projects) to make it compulsory to publically release all data frames after a period (1 year ? 2 years ? 4 years) during which you are supposed to solve the structures you have collected the data for, so that others can have a go at it (and solve the structures for you): you may find yourself for example in between grants and need to spend all of your time looking for funding for a couple of years, with little or no staff working with you. With the trend we see of ever diminishing resources, this would mean that the very large and well funded labs and groups would solve their own structures, and solve those of smaller groups as well (and publish the latter). This would then mean (after a while) the concentration of macromolecular crystallography to only the lucky few who have managed to secure large grants and will therefore go-on securing such grants. You could call that evolution I suppose. We are already in a situation where the crystallographers who solved the structures are not necessarily authors on the publications reporting the structures... so is it time to go back to home sources (X-ray generators) for data collection ? Fred. -- === * * * Gerard Bricogne g...@globalphasing.com * * * * Global Phasing Ltd. * * Sheraton House, Castle Park Tel: +44-(0)1223-353033 * * Cambridge CB3 0AX, UK Fax: +44-(0)1223-366889 * * * ===
[ccp4bb] RE : [ccp4bb] refmac 5.6 ccp4 6.2.0
Hi Kenneth, I am experiencing exactly the same problem, in similar conditions: refinement with H at 0.84 A resolution. From a bunch of tests made yesterday, I have found that it is linked to incompatibilities between cif dictionaries definitions and H names in the input PDB. For me, one simple solution to that problem, was to remove all H atoms from my input pdb and let refmac rebuild them (MAKE HYDR ALL). I hope the trick will work for you. By the way, I am facing an other problem: Clashes in inter residues H-bonds between H and acceptor atoms. What is the correct way to define these. The HYDBND pdb definition doesn't seems to work. Do I need to use LINK definitions ? Is there a way to do that automatically ? Cheers, Pierre De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Robbie Joosten [robbie_joos...@hotmail.com] Date d'envoi : vendredi 28 octobre 2011 09:42 À : CCP4BB@JISCMAIL.AC.UK Objet : Re: [ccp4bb] refmac 5.6 ccp4 6.2.0 Hi Kenneth, This looks like an off-by-one bug in the restraint generation. Typical sources are weird LINKs, wrong atom names and bad luck. I suggest you make sure you have the very latest Refmac and dictionary and try setting up a new refinement instead of recycling an old job. If that doesn't work, we may need a closer look at your input model. Cheers, Robbie Date: Thu, 27 Oct 2011 20:48:49 -0500 From: satys...@wisc.edu Subject: [ccp4bb] refmac 5.6 ccp4 6.2.0 To: CCP4BB@JISCMAIL.AC.UK Has anyone had problems with Refmac 5.6? I tried refining our stucture at 1.24 A, aniso with H in riding position and it just exploded! I get error in distances such as Standard External All Bonds: 3270 0 3270 Angles: 4923 0 4923 Chirals: 214 0 214 Planes: 368 0 368 Torsions: 957 0 957 --- Number of reflections in file 90428 Number of reflections read 90428 CGMAT cycle number = 1 Bond distance outliers Bond distance deviations from the ideal 10.000Sigma will be monitored A 5 PRO C A - A 5 PRO HB1 A mod.= 3.344 id.= 1.329 dev= -2.015 sig.= 0.014 A 5 PRO C B - A 5 PRO HB1 B mod.= 2.997 id.= 1.329 dev= -1.668 sig.= 0.014 A 5 PRO HB1 A - A 5 PRO HG1 A mod.= 2.292 id.= 1.458 dev= -0.834 sig.= 0.021 A 5 PRO HB1 A - A 6 LEU HD23A mod.= 7.407 id.= 0.860 dev= -6.547 sig.= 0.020 A 5 PRO HB1 B - A 5 PRO HG1 B mod.= 2.247 id.= 1.458 dev= -0.789 sig.= 0.021 A 5 PRO HB1 B - A 6 LEU HD23B mod.= 6.529 id.= 0.860 dev= -5.669 sig.= 0.020 A 5 PRO HG1 A - A 5 PRO HD1 A mod.= 2.267 id.= 0.980 dev= -1.287 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU N A mod.= 4.860 id.= 1.530 dev= -3.330 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU HD21A mod.= 6.129 id.= 1.525 dev= -4.604 sig.= 0.021 A 5 PRO HG1 B - A 5 PRO HD1 B mod.= 2.236 id.= 0.980 dev= -1.256 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU N B mod.= 4.922 id.= 1.530 dev= -3.392 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU HD21B mod.= 6.664 id.= 1.525 dev= -5.139 sig.= 0.021 A 6 LEU N A - A 6 LEU CA A mod.= 1.467 id.= 0.970 dev= -0.497 sig.= 0.020 A 6 LEU N A - A 6 LEU HA A mod.= 2.005 id.= 0.970 dev= -1.035 sig.= 0.020 A 6 LEU N A - A 6 LEU CB A mod.= 2.497 id.= 1.530 dev= -0.967 sig.= 0.020 A 6 LEU N B - A 6 LEU CA B mod.= 1.469 id.= 0.970 dev= -0.499 sig.= 0.020 A 6 LEU N B - A 6 LEU HA B mod.= 2.032 id.= 0.970 dev= -1.062 sig.= 0.020 A 6 LEU N B - A 6 LEU CB B mod.= 2.446 id.= 1.530 dev= -0.916 sig.= 0.020 A 6 LEU CB A - A 6 LEU HB2 A mod.= 0.969 id.= 1.521 dev= 0.552 sig.= 0.020 A Rfree goes form 17 to 28 and R from 15 to 25. Coot map looks like a bunch of busted insect parts. I use the exact same input using ccp4 6.1.13 and Refmac 5.5 and all is good. I am forced to use the old ccp4 and refmac to publish. Rf 17 R 15. thanks -- Kenneth A. Satyshur, M.S.,Ph.D. Associate Scientist University of Wisconsin Madison, Wisconsin 53706 608-215-5207
Re: [ccp4bb] RE : [ccp4bb] refmac 5.6 ccp4 6.2.0
Hi All I think that is the reason. In version of refmac (with new dictio uses new pdb v3 hydrogen naming and there are a lot of differences. regards Garib On 28 Oct 2011, at 10:00, LEGRAND Pierre wrote: Hi Kenneth, I am experiencing exactly the same problem, in similar conditions: refinement with H at 0.84 A resolution. From a bunch of tests made yesterday, I have found that it is linked to incompatibilities between cif dictionaries definitions and H names in the input PDB. For me, one simple solution to that problem, was to remove all H atoms from my input pdb and let refmac rebuild them (MAKE HYDR ALL). I hope the trick will work for you. By the way, I am facing an other problem: Clashes in inter residues H-bonds between H and acceptor atoms. What is the correct way to define these. The HYDBND pdb definition doesn't seems to work. Do I need to use LINK definitions ? Is there a way to do that automatically ? Cheers, Pierre De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Robbie Joosten [robbie_joos...@hotmail.com] Date d'envoi : vendredi 28 octobre 2011 09:42 À : CCP4BB@JISCMAIL.AC.UK Objet : Re: [ccp4bb] refmac 5.6 ccp4 6.2.0 Hi Kenneth, This looks like an off-by-one bug in the restraint generation. Typical sources are weird LINKs, wrong atom names and bad luck. I suggest you make sure you have the very latest Refmac and dictionary and try setting up a new refinement instead of recycling an old job. If that doesn't work, we may need a closer look at your input model. Cheers, Robbie Date: Thu, 27 Oct 2011 20:48:49 -0500 From: satys...@wisc.edu Subject: [ccp4bb] refmac 5.6 ccp4 6.2.0 To: CCP4BB@JISCMAIL.AC.UK Has anyone had problems with Refmac 5.6? I tried refining our stucture at 1.24 A, aniso with H in riding position and it just exploded! I get error in distances such as Standard External All Bonds: 3270 0 3270 Angles: 4923 0 4923 Chirals: 214 0 214 Planes: 368 0 368 Torsions: 957 0 957 --- Number of reflections in file 90428 Number of reflections read 90428 CGMAT cycle number = 1 Bond distance outliers Bond distance deviations from the ideal 10.000Sigma will be monitored A 5 PRO C A - A 5 PRO HB1 A mod.= 3.344 id.= 1.329 dev= -2.015 sig.= 0.014 A 5 PRO C B - A 5 PRO HB1 B mod.= 2.997 id.= 1.329 dev= -1.668 sig.= 0.014 A 5 PRO HB1 A - A 5 PRO HG1 A mod.= 2.292 id.= 1.458 dev= -0.834 sig.= 0.021 A 5 PRO HB1 A - A 6 LEU HD23A mod.= 7.407 id.= 0.860 dev= -6.547 sig.= 0.020 A 5 PRO HB1 B - A 5 PRO HG1 B mod.= 2.247 id.= 1.458 dev= -0.789 sig.= 0.021 A 5 PRO HB1 B - A 6 LEU HD23B mod.= 6.529 id.= 0.860 dev= -5.669 sig.= 0.020 A 5 PRO HG1 A - A 5 PRO HD1 A mod.= 2.267 id.= 0.980 dev= -1.287 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU N A mod.= 4.860 id.= 1.530 dev= -3.330 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU HD21A mod.= 6.129 id.= 1.525 dev= -4.604 sig.= 0.021 A 5 PRO HG1 B - A 5 PRO HD1 B mod.= 2.236 id.= 0.980 dev= -1.256 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU N B mod.= 4.922 id.= 1.530 dev= -3.392 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU HD21B mod.= 6.664 id.= 1.525 dev= -5.139 sig.= 0.021 A 6 LEU N A - A 6 LEU CA A mod.= 1.467 id.= 0.970 dev= -0.497 sig.= 0.020 A 6 LEU N A - A 6 LEU HA A mod.= 2.005 id.= 0.970 dev= -1.035 sig.= 0.020 A 6 LEU N A - A 6 LEU CB A mod.= 2.497 id.= 1.530 dev= -0.967 sig.= 0.020 A 6 LEU N B - A 6 LEU CA B mod.= 1.469 id.= 0.970 dev= -0.499 sig.= 0.020 A 6 LEU N B - A 6 LEU HA B mod.= 2.032 id.= 0.970 dev= -1.062 sig.= 0.020 A 6 LEU N B - A 6 LEU CB B mod.= 2.446 id.= 1.530 dev= -0.916 sig.= 0.020 A 6 LEU CB A - A 6 LEU HB2 A mod.= 0.969 id.= 1.521 dev= 0.552 sig.= 0.020 A Rfree goes form 17 to 28 and R from 15 to 25. Coot map looks like a bunch of busted insect parts. I use the exact same input using ccp4 6.1.13 and Refmac 5.5 and all is good. I am forced to use the old ccp4 and refmac to publish. Rf 17 R 15. thanks -- Kenneth A. Satyshur, M.S.,Ph.D. Associate Scientist University of Wisconsin Madison, Wisconsin 53706 608-215-5207 Garib N Murshudov Structural Studies Division MRC Laboratory of Molecular Biology Hills Road Cambridge CB2 0QH UK Email: ga...@mrc-lmb.cam.ac.uk Web http://www.mrc-lmb.cam.ac.uk
Re: [ccp4bb] raw data deposition
Hi Katherine, It sounds as if you had all you needed to correct other people's (and your own) errors, as you described, in the existing database (EDS, PDB) or your own data, right? That hardly justifies establishing a new database of which at least 80-90% is worthless. Furthermore, since much of the non-indexable data arise from experimenter's faults, is it not the time to start a discussion (preferably prior to setting up a committee) on deposition of crystals so that anybody can have a go at them to detect problems if they wish? 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-2220Skype: boaz.shaanan Fax: 972-8-647-2992 or 972-8-646-1710 From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Katherine Sippel [katherine.sip...@gmail.com] Sent: Friday, October 28, 2011 8:06 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] raw data deposition Generally during these rigorous bb debates I prefer to stay silent and absorb all the information possible so that I can make an informed decision later on. I fear that I am compelled to contribute in this instance. In regards to the does this make a difference in the biological interpretation stage issue, I can state that it does. In my comparatively miniscule career I have run into this issue three times. The first two address Adrian's point... And (b) even if they do, is this continual improvement even worthwhile? I am always depressed at how little a model changes from an initial build to the final one, even when the rfree drops from 35 to 23. All that work! - and my biological interpretation would have been almost the same at the beginning as at the end. In one instance I adopted an orphaned structure and ran it through a slightly more advanced refinement protocol (on the same structure factors) and ended up with a completely different story than the one I started with [1]. Another researcher in my grad lab identified mis-oriented catalytic residues in an existing structure from EDS server maps which affects the biochemistry of the catalytic mechanism [2]. In another case I decided that I would reprocess some images that I had originally indexed and scaled in my Ooo buttons clicky clicky stage of learning crystallography and the improved structure factors revealed a alternate conformations for both a critical loop and ligand orientation [3]. And this was all in the last 4 years. So I would posit that the answer is yes there are significant biological insights to be had with the capacity to reassess data in any form. Katherine [1] J Phys Chem Lett. 2010 Oct 7;1(19):2898-2902 [2] Acta Crystallogr D Biol Crystallogr. 2009 Mar;65(Pt 3):294-6. [3] Manuscript in progress Katherine Sippel, PhD Postdoctoral Associate Baylor College of Medicine
Re: [ccp4bb] raw data deposition
Dear Remy, You are right, and I was about to send a message confessing that I had been rash in my response to Fred's. Another person e-mailed me off-list to point out that sometimes a structure can be quickly solved, but that doing all the rest of the work involved in wrapping that structure into a good biological story for publication can take a very long time, and that it would be wrong for a SR source's forced disclosure policy to start imposing deadlines on that process. I entirely agree with both of you and admit that I reacted too quickly and with insufficient thought to Fred's message. However, as you point out yourself, this issue is related to a different question (SR sources' disclosure policy towards all data collected on their beamlines) from the original one that started this thread (deposition of raw images with the pdb entries they led to). The two topics became entangled through the idea of prototyping an approach to the latter by tweaking the storage and access features involved in the former. Many thanks to you and to the other correspondent for picking up and correcting my error. This however leaves the main topic of this thread untouched. With best wishes, Gerard. -- On Fri, Oct 28, 2011 at 01:38:29PM +0200, Remy Loris wrote: Dear Gerard, I cannot agree. Last year my group published a paper in Cell which contained a structure for which the native data were collected at a synchrotron around 1997. Various reasons contributed to the long lag period for solving this structure, but basically it all came down to money needed to do the work. Equally I am sure there are other cases for which a first good native data set is a breakthrough you wish to protect rather than hand it out to anyone who might potentially scoop you after you have put lots of money and effort into the project. Therefore: Images corresponding to structures I deposit in the PDB: No problem. That is what we do with processed data as well. But images of unsolved structures, I don't see why that should be enforced or done automatically by synchrotrons. Nobody deposits processed data without an accompanying structure either. I do agree that one could be given the option to deposit interesting data with which he/se will not continue for whatever reason. But this should be optional, and a clear consensus should emerge within the community as how the original producers of the data have to be acknowledged if these data are used and the results published by another team, especially if the use of that particular dataset is crucial for the publication. Remy Loris Vrije Universiteit Brussel and VIB Op 28/10/2011 11:54, Gerard Bricogne schreef: Dear Fred, Frankly, with respect, this sounds to me like fanciful and rather non-sensical paranoia. The time frame for public disclosure of all SR data has been quoted at 5 years, or something of that order. If someone has been unable to solve a structure 5 years after having collected data on it, then it does make perfect sense that he/she be rescued in one way or another. Any responsible scientist in that situation would have called for specialist help long before then, and having failed to do so would indicate a loss of interest in the project anyway. This is again the type of argument that strays away from a serious question by throwing decoys around the place. Of course such views must be heard, but so should the counter-arguments of those who disagree with them. With best wishes, Gerard. -- On Fri, Oct 28, 2011 at 10:42:25AM +0200, Vellieux Frederic wrote: D Bonsor wrote: and allow someone else to have ago at solving the structure. I'd be careful there if there was a motion to try to implement a policy at SR sources (for academic research projects) to make it compulsory to publically release all data frames after a period (1 year ? 2 years ? 4 years) during which you are supposed to solve the structures you have collected the data for, so that others can have a go at it (and solve the structures for you): you may find yourself for example in between grants and need to spend all of your time looking for funding for a couple of years, with little or no staff working with you. With the trend we see of ever diminishing resources, this would mean that the very large and well funded labs and groups would solve their own structures, and solve those of smaller groups as well (and publish the latter). This would then mean (after a while) the concentration of macromolecular crystallography to only the lucky few who have managed to secure large grants and will therefore go-on securing such grants. You could call that evolution I suppose. We are already in a situation where the crystallographers who solved the structures are not necessarily authors on the publications reporting the structures... so is it time to go back to
Re: [ccp4bb] raw data deposition
I must say that there were some emails exchanged between me and Gerard later, in which I pointed out that I wasn't against deposition of images (data frames). In fact, if SR sources kept user's data there would be one more structure from here in the PDB: HDD failure here, the data on a mirror HDD but the company in charge of maintenance erased the data frames and data processing statistics by accident. For a trypanosomal enzyme there is no chance that I can ever get funding now to replicate the work (protein production and purification, crystallisation, data collection) so that Table 1 could be produced for a manuscript. However, my email to the bb was provocative - I admit I was doing this willingly - to write that in such harsh funding times someone could start a career, get some small grant, enough to clone produce purify crystallize and collect a first data set. And then find him or herself without funding for X years (success rate = less than 10% these days). If this person then gets scooped by whoever, end of a promising career. Unfortunately, such a prospect doesn't seem to be science fiction any more nowadays. I hope this clears things. I wanted to be provocative and point out the difficulties we are all facing wrt funding so that we shouldn't set up a system that may result in killing careers. Our politicians do not need any help from us on that I think. Fred. Gerard Bricogne wrote: Dear Remy, You are right, and I was about to send a message confessing that I had been rash in my response to Fred's. Another person e-mailed me off-list to point out that sometimes a structure can be quickly solved, but that doing all the rest of the work involved in wrapping that structure into a good biological story for publication can take a very long time, and that it would be wrong for a SR source's forced disclosure policy to start imposing deadlines on that process. I entirely agree with both of you and admit that I reacted too quickly and with insufficient thought to Fred's message. However, as you point out yourself, this issue is related to a different question (SR sources' disclosure policy towards all data collected on their beamlines) from the original one that started this thread (deposition of raw images with the pdb entries they led to). The two topics became entangled through the idea of prototyping an approach to the latter by tweaking the storage and access features involved in the former. Many thanks to you and to the other correspondent for picking up and correcting my error. This however leaves the main topic of this thread untouched. With best wishes, Gerard. -- On Fri, Oct 28, 2011 at 01:38:29PM +0200, Remy Loris wrote: Dear Gerard, I cannot agree. Last year my group published a paper in Cell which contained a structure for which the native data were collected at a synchrotron around 1997. Various reasons contributed to the long lag period for solving this structure, but basically it all came down to money needed to do the work. Equally I am sure there are other cases for which a first good native data set is a breakthrough you wish to protect rather than hand it out to anyone who might potentially scoop you after you have put lots of money and effort into the project. Therefore: Images corresponding to structures I deposit in the PDB: No problem. That is what we do with processed data as well. But images of unsolved structures, I don't see why that should be enforced or done automatically by synchrotrons. Nobody deposits processed data without an accompanying structure either. I do agree that one could be given the option to deposit interesting data with which he/se will not continue for whatever reason. But this should be optional, and a clear consensus should emerge within the community as how the original producers of the data have to be acknowledged if these data are used and the results published by another team, especially if the use of that particular dataset is crucial for the publication. Remy Loris Vrije Universiteit Brussel and VIB
Re: [ccp4bb] [PyMOL] Putting a protein molecule into a grid and traversing through the grid
Hi Anasuya, at least, Gerard Kleywegt's program moleman2 from the Uppsala Software Factory http://xray.bmc.uu.se/usf/ has a command XYz ALign_inertia_axes should do your first task. From the moleman2 manual: This will move the currently selected atoms such that their centre-of-gravity is at the origin (0,0,0); then it will calculate the three principal inertia axes, and align the selected atoms such that these axes coincide with the X, Y and Z axis. This alignment is done such that the major inertia axis coincides with the X-axis (largest eigenvalue), and the minor inertia axis coincides with the Z-axis (smallest eigenvalue). Best regards, Dirk. Am 27.10.11 14:17, schrieb Anasuya Dighe: how do i put a protein molecule inside a cube with x-axis spanning till the largest x-coordinate, y-axis spanning till the largest y-coordinate, and z-axis spanning till the largest z-coordinate? Once i do this, can i divide the larger cube(i.e. the one holding the entire protein) into smaller ones of lesser dimensions? Say, 5A x 5A x 5A? Once i generate these smaller cubes, is there a way via pymol, by which i can navigate through the protein molecule, (smaller)cube by (smaller)cube? As in, can pymol be used to tell me which residues are lying in which (smaller) cube and so on? Can all this be done in a single pymol window/script? please let me know. Thanks -Anasuya -- *** Dirk Kostrewa Gene Center Munich, A5.07 Department of Biochemistry Ludwig-Maximilians-Universität München Feodor-Lynen-Str. 25 D-81377 Munich Germany Phone: +49-89-2180-76845 Fax:+49-89-2180-76999 E-mail: kostr...@genzentrum.lmu.de WWW:www.genzentrum.lmu.de ***
Re: [ccp4bb] Weird blob appears
On Thu, 2011-10-27 at 20:46 -0500, Jacob Keller wrote: I went back to using the original mtz from scala Curious. What were you using - the refmac output mtz? Just for the record - the refmac output mtz contains *modified* amplitudes, and Garib said many times it should not be used as the input for the next cycle... However, from what I understand about scaling applied to output fobs, it is highly unlikely that it will generate an extra density of the kind you observed. -- Oh, suddenly throwing a giraffe into a volcano to make water is crazy? Julian, King of Lemurs
Re: [ccp4bb] refmac 5.6 ccp4 6.2.0
Just to verify, is this by any chance *unrestrained* refinement? On Fri, 2011-10-28 at 09:37 +0200, Tim Gruene wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Kenneth A. Satyshur, what is your weight set to? If it is set to 'auto', try setting it to a specific value and lower that value until the explosion stops. If this happens at low matrix values (at 1.24A it should be way above 5 or 10 for a well refined structure), your resolution might not be 1.24A, i.e., you may have integrated noise (check I/sigI over resolution shells). Tim P.S.: I wonder what power somebody might have to _force_ you use a specific software version... On 10/28/2011 03:48 AM, Kenneth A. Satyshur wrote: Has anyone had problems with Refmac 5.6? I tried refining our stucture at 1.24 A, aniso with H in riding position and it just exploded! I get error in distances such as Standard External All Bonds: 3270 0 3270 Angles: 4923 0 4923 Chirals: 214 0 214 Planes: 368 0 368 Torsions: 957 0 957 --- Number of reflections in file 90428 Number of reflections read 90428 CGMAT cycle number = 1 Bond distance outliers Bond distance deviations from the ideal 10.000Sigma will be monitored A 5 PRO C A - A 5 PRO HB1 A mod.= 3.344 id.= 1.329 dev= -2.015 sig.= 0.014 A 5 PRO C B - A 5 PRO HB1 B mod.= 2.997 id.= 1.329 dev= -1.668 sig.= 0.014 A 5 PRO HB1 A - A 5 PRO HG1 A mod.= 2.292 id.= 1.458 dev= -0.834 sig.= 0.021 A 5 PRO HB1 A - A 6 LEU HD23A mod.= 7.407 id.= 0.860 dev= -6.547 sig.= 0.020 A 5 PRO HB1 B - A 5 PRO HG1 B mod.= 2.247 id.= 1.458 dev= -0.789 sig.= 0.021 A 5 PRO HB1 B - A 6 LEU HD23B mod.= 6.529 id.= 0.860 dev= -5.669 sig.= 0.020 A 5 PRO HG1 A - A 5 PRO HD1 A mod.= 2.267 id.= 0.980 dev= -1.287 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU N A mod.= 4.860 id.= 1.530 dev= -3.330 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU HD21A mod.= 6.129 id.= 1.525 dev= -4.604 sig.= 0.021 A 5 PRO HG1 B - A 5 PRO HD1 B mod.= 2.236 id.= 0.980 dev= -1.256 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU N B mod.= 4.922 id.= 1.530 dev= -3.392 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU HD21B mod.= 6.664 id.= 1.525 dev= -5.139 sig.= 0.021 A 6 LEU N A - A 6 LEU CA A mod.= 1.467 id.= 0.970 dev= -0.497 sig.= 0.020 A 6 LEU N A - A 6 LEU HA A mod.= 2.005 id.= 0.970 dev= -1.035 sig.= 0.020 A 6 LEU N A - A 6 LEU CB A mod.= 2.497 id.= 1.530 dev= -0.967 sig.= 0.020 A 6 LEU N B - A 6 LEU CA B mod.= 1.469 id.= 0.970 dev= -0.499 sig.= 0.020 A 6 LEU N B - A 6 LEU HA B mod.= 2.032 id.= 0.970 dev= -1.062 sig.= 0.020 A 6 LEU N B - A 6 LEU CB B mod.= 2.446 id.= 1.530 dev= -0.916 sig.= 0.020 A 6 LEU CB A - A 6 LEU HB2 A mod.= 0.969 id.= 1.521 dev= 0.552 sig.= 0.020 A Rfree goes form 17 to 28 and R from 15 to 25. Coot map looks like a bunch of busted insect parts. I use the exact same input using ccp4 6.1.13 and Refmac 5.5 and all is good. I am forced to use the old ccp4 and refmac to publish. Rf 17 R 15. thanks -- Kenneth A. Satyshur, M.S.,Ph.D. Associate Scientist University of Wisconsin Madison, Wisconsin 53706 608-215-5207 - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOqluhUxlJ7aRr7hoRAjadAJ9Df2hbWjixDCdS3Z4DB7mm4ubRIACeOw6X 6JkjyzRUdxqjH/9b/oftBjE= =xRXE -END PGP SIGNATURE-
Re: [ccp4bb] raw data deposition
Hi Boaz, I see your point in regards to making a database of all diffraction images. The argument I clearly failed to make effectively was that improvement of structures can frequently yield useful biological information which is why I believe that, at the least, images of deposited structures should be archived. The availability of the structure factors alone can allow crystallographers to improve models significantly, but there is always the question of whether there was more data lost to button smashing despite developers efforts to make data processing idiot-proof. If I am going to invest years of my life and millions of tax dollars on a hypothesis derived from a structure I personally would be willing to take a day to reprocess the images and put the model through it's paces to ensure that I'm not wasting my time and/or other people's money. Yes experimenters (including myself) make mistakes, but the joy of crystallography is that we can effectively backtrack, identify where the mistake was made, fix it and learn from it. All it costs us is a couple of hours and perhaps a little pride whereas the result is stronger more effective science for our field as a whole. In my mind that equalizes out the cost:benefit ratio considerably. Of course this is all just my opinion, Katherine 2011/10/28 Boaz Shaanan bshaa...@exchange.bgu.ac.il Hi Katherine, It sounds as if you had all you needed to correct other people's (and your own) errors, as you described, in the existing database (EDS, PDB) or your own data, right? That hardly justifies establishing a new database of which at least 80-90% is worthless. Furthermore, since much of the non-indexable data arise from experimenter's faults, is it not the time to start a discussion (preferably prior to setting up a committee) on deposition of crystals so that anybody can have a go at them to detect problems if they wish? 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 Katherine Sippel [katherine.sip...@gmail.com] *Sent:* Friday, October 28, 2011 8:06 AM *To:* CCP4BB@JISCMAIL.AC.UK *Subject:* Re: [ccp4bb] raw data deposition Generally during these rigorous bb debates I prefer to stay silent and absorb all the information possible so that I can make an informed decision later on. I fear that I am compelled to contribute in this instance. In regards to the does this make a difference in the biological interpretation stage issue, I can state that it does. In my comparatively miniscule career I have run into this issue three times. The first two address Adrian's point... And (b) even if they do, is this continual improvement even worthwhile? I am always depressed at how little a model changes from an initial build to the final one, even when the rfree drops from 35 to 23. All that work! - and my biological interpretation would have been almost the same at the beginning as at the end. In one instance I adopted an orphaned structure and ran it through a slightly more advanced refinement protocol (on the same structure factors) and ended up with a completely different story than the one I started with [1]. Another researcher in my grad lab identified mis-oriented catalytic residues in an existing structure from EDS server maps which affects the biochemistry of the catalytic mechanism [2]. In another case I decided that I would reprocess some images that I had originally indexed and scaled in my Ooo buttons clicky clicky stage of learning crystallography and the improved structure factors revealed a alternate conformations for both a critical loop and ligand orientation [3]. And this was all in the last 4 years. So I would posit that the answer is yes there are significant biological insights to be had with the capacity to reassess data in any form. Katherine [1] J Phys Chem Lett. 2010 Oct 7;1(19):2898-2902 [2] Acta Crystallogr D Biol Crystallogr. 2009 Mar;65(Pt 3):294-6. [3] Manuscript in progress Katherine Sippel, PhD Postdoctoral Associate Baylor College of Medicine
Re: [ccp4bb] raw data deposition
What about a case in which two investigators have differences about what cutoff to apply to the data, for example, A thinks that Rsym of 50 should be used regardless of I/sig, and B thinks that I/sig of 2 and Rpim should be used. Usually A would cut off the data at a lower resolution than B, especially with high multiplicity, so B would love to have the images to see what extra info could be gleaned from a higher-res cutoff. Or the converse, A is skeptical of B's cutoff, and wants to see whether the data according to A's cutoff justify B's conclusion. Don't these types of things happen a lot, and wouldn't images be helpful for this? JPK
Re: [ccp4bb] raw data deposition
Which trps protein check the MSGPP or SGPP website they might have what you are looking for. Jürgen .. Jürgen Bosch Johns Hopkins Bloomberg School of Public Health Department of Biochemistry Molecular Biology Johns Hopkins Malaria Research Institute 615 North Wolfe Street, W8708 Baltimore, MD 21205 Phone: +1-410-614-4742 Lab: +1-410-614-4894 Fax: +1-410-955-3655 http://web.mac.com/bosch_lab/ On Oct 28, 2011, at 8:19, Vellieux Frederic frederic.velli...@ibs.fr wrote: I must say that there were some emails exchanged between me and Gerard later, in which I pointed out that I wasn't against deposition of images (data frames). In fact, if SR sources kept user's data there would be one more structure from here in the PDB: HDD failure here, the data on a mirror HDD but the company in charge of maintenance erased the data frames and data processing statistics by accident. For a trypanosomal enzyme there is no chance that I can ever get funding now to replicate the work (protein production and purification, crystallisation, data collection) so that Table 1 could be produced for a manuscript. However, my email to the bb was provocative - I admit I was doing this willingly - to write that in such harsh funding times someone could start a career, get some small grant, enough to clone produce purify crystallize and collect a first data set. And then find him or herself without funding for X years (success rate = less than 10% these days). If this person then gets scooped by whoever, end of a promising career. Unfortunately, such a prospect doesn't seem to be science fiction any more nowadays. I hope this clears things. I wanted to be provocative and point out the difficulties we are all facing wrt funding so that we shouldn't set up a system that may result in killing careers. Our politicians do not need any help from us on that I think. Fred. Gerard Bricogne wrote: Dear Remy, You are right, and I was about to send a message confessing that I had been rash in my response to Fred's. Another person e-mailed me off-list to point out that sometimes a structure can be quickly solved, but that doing all the rest of the work involved in wrapping that structure into a good biological story for publication can take a very long time, and that it would be wrong for a SR source's forced disclosure policy to start imposing deadlines on that process. I entirely agree with both of you and admit that I reacted too quickly and with insufficient thought to Fred's message. However, as you point out yourself, this issue is related to a different question (SR sources' disclosure policy towards all data collected on their beamlines) from the original one that started this thread (deposition of raw images with the pdb entries they led to). The two topics became entangled through the idea of prototyping an approach to the latter by tweaking the storage and access features involved in the former. Many thanks to you and to the other correspondent for picking up and correcting my error. This however leaves the main topic of this thread untouched. With best wishes, Gerard. -- On Fri, Oct 28, 2011 at 01:38:29PM +0200, Remy Loris wrote: Dear Gerard, I cannot agree. Last year my group published a paper in Cell which contained a structure for which the native data were collected at a synchrotron around 1997. Various reasons contributed to the long lag period for solving this structure, but basically it all came down to money needed to do the work. Equally I am sure there are other cases for which a first good native data set is a breakthrough you wish to protect rather than hand it out to anyone who might potentially scoop you after you have put lots of money and effort into the project. Therefore: Images corresponding to structures I deposit in the PDB: No problem. That is what we do with processed data as well. But images of unsolved structures, I don't see why that should be enforced or done automatically by synchrotrons. Nobody deposits processed data without an accompanying structure either. I do agree that one could be given the option to deposit interesting data with which he/se will not continue for whatever reason. But this should be optional, and a clear consensus should emerge within the community as how the original producers of the data have to be acknowledged if these data are used and the results published by another team, especially if the use of that particular dataset is crucial for the publication. Remy Loris Vrije Universiteit Brussel and VIB
Re: [ccp4bb] raw data deposition
Dear Jacob, See the paper by J. Wang cited at the end of Francis Reyes's message under this thread yesterday: it is a case of exactly what you are talking about. With best wishes, Gerard. -- On Fri, Oct 28, 2011 at 10:05:44AM -0500, Jacob Keller wrote: What about a case in which two investigators have differences about what cutoff to apply to the data, for example, A thinks that Rsym of 50 should be used regardless of I/sig, and B thinks that I/sig of 2 and Rpim should be used. Usually A would cut off the data at a lower resolution than B, especially with high multiplicity, so B would love to have the images to see what extra info could be gleaned from a higher-res cutoff. Or the converse, A is skeptical of B's cutoff, and wants to see whether the data according to A's cutoff justify B's conclusion. Don't these types of things happen a lot, and wouldn't images be helpful for this? JPK -- === * * * Gerard Bricogne g...@globalphasing.com * * * * Global Phasing Ltd. * * Sheraton House, Castle Park Tel: +44-(0)1223-353033 * * Cambridge CB3 0AX, UK Fax: +44-(0)1223-366889 * * * ===
[ccp4bb] RE : [ccp4bb] refmac 5.6 ccp4 6.2.0
Dear Ed, Not in my case. I still do *restrained* refinement. I use: refi type REST - resi MLKF - meth CGMAT - bref MIXED ncyc 10 blim 0.1 200.0 With both: weight MATRIX 50 or weight AUTO it gives the same problem. I have also tested the latest refmac5 version (Refmac_5.6.0119) and latest dictionaries (refmac_dictionary_v5.31), but it still produce the same error, directly from the first cycle. I can give more details and files off-list if requested. Cheers, Pierre De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Ed Pozharski [epozh...@umaryland.edu] Date d'envoi : vendredi 28 octobre 2011 16:00 À : CCP4BB@JISCMAIL.AC.UK Objet : Re: [ccp4bb] refmac 5.6 ccp4 6.2.0 Just to verify, is this by any chance *unrestrained* refinement? On Fri, 2011-10-28 at 09:37 +0200, Tim Gruene wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Kenneth A. Satyshur, what is your weight set to? If it is set to 'auto', try setting it to a specific value and lower that value until the explosion stops. If this happens at low matrix values (at 1.24A it should be way above 5 or 10 for a well refined structure), your resolution might not be 1.24A, i.e., you may have integrated noise (check I/sigI over resolution shells). Tim P.S.: I wonder what power somebody might have to _force_ you use a specific software version... On 10/28/2011 03:48 AM, Kenneth A. Satyshur wrote: Has anyone had problems with Refmac 5.6? I tried refining our stucture at 1.24 A, aniso with H in riding position and it just exploded! I get error in distances such as Standard External All Bonds: 3270 0 3270 Angles: 4923 0 4923 Chirals: 214 0 214 Planes: 368 0 368 Torsions: 957 0 957 --- Number of reflections in file 90428 Number of reflections read 90428 CGMAT cycle number = 1 Bond distance outliers Bond distance deviations from the ideal 10.000Sigma will be monitored A 5 PRO C A - A 5 PRO HB1 A mod.= 3.344 id.= 1.329 dev= -2.015 sig.= 0.014 A 5 PRO C B - A 5 PRO HB1 B mod.= 2.997 id.= 1.329 dev= -1.668 sig.= 0.014 A 5 PRO HB1 A - A 5 PRO HG1 A mod.= 2.292 id.= 1.458 dev= -0.834 sig.= 0.021 A 5 PRO HB1 A - A 6 LEU HD23A mod.= 7.407 id.= 0.860 dev= -6.547 sig.= 0.020 A 5 PRO HB1 B - A 5 PRO HG1 B mod.= 2.247 id.= 1.458 dev= -0.789 sig.= 0.021 A 5 PRO HB1 B - A 6 LEU HD23B mod.= 6.529 id.= 0.860 dev= -5.669 sig.= 0.020 A 5 PRO HG1 A - A 5 PRO HD1 A mod.= 2.267 id.= 0.980 dev= -1.287 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU N A mod.= 4.860 id.= 1.530 dev= -3.330 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU HD21A mod.= 6.129 id.= 1.525 dev= -4.604 sig.= 0.021 A 5 PRO HG1 B - A 5 PRO HD1 B mod.= 2.236 id.= 0.980 dev= -1.256 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU N B mod.= 4.922 id.= 1.530 dev= -3.392 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU HD21B mod.= 6.664 id.= 1.525 dev= -5.139 sig.= 0.021 A 6 LEU N A - A 6 LEU CA A mod.= 1.467 id.= 0.970 dev= -0.497 sig.= 0.020 A 6 LEU N A - A 6 LEU HA A mod.= 2.005 id.= 0.970 dev= -1.035 sig.= 0.020 A 6 LEU N A - A 6 LEU CB A mod.= 2.497 id.= 1.530 dev= -0.967 sig.= 0.020 A 6 LEU N B - A 6 LEU CA B mod.= 1.469 id.= 0.970 dev= -0.499 sig.= 0.020 A 6 LEU N B - A 6 LEU HA B mod.= 2.032 id.= 0.970 dev= -1.062 sig.= 0.020 A 6 LEU N B - A 6 LEU CB B mod.= 2.446 id.= 1.530 dev= -0.916 sig.= 0.020 A 6 LEU CB A - A 6 LEU HB2 A mod.= 0.969 id.= 1.521 dev= 0.552 sig.= 0.020 A Rfree goes form 17 to 28 and R from 15 to 25. Coot map looks like a bunch of busted insect parts. I use the exact same input using ccp4 6.1.13 and Refmac 5.5 and all is good. I am forced to use the old ccp4 and refmac to publish. Rf 17 R 15. thanks -- Kenneth A. Satyshur, M.S.,Ph.D. Associate Scientist University of Wisconsin Madison, Wisconsin 53706 608-215-5207 - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOqluhUxlJ7aRr7hoRAjadAJ9Df2hbWjixDCdS3Z4DB7mm4ubRIACeOw6X 6JkjyzRUdxqjH/9b/oftBjE= =xRXE -END PGP SIGNATURE-
Re: [ccp4bb] raw data deposition
Hi Jacob, There is (very) BIG difference between depositing images for deposited structures and depositing all images ever recorded by any crystallographer on the planet. In the case you presented, A and B can settle the issue by looking at each other's images whether through the database or by exchanging data on their own initiative or even by writing a note to a journal that they completely disagree with one another and start a debate (in case one of them is not willing to exchange images). Besides, I thought that by now there are some standards on how data should be processed (this has been discussed on this BB once every few months, if I'm not mistaken). Isn't that part of the validation process that so many good people have established? Also, to the best of my knowledge (and experience) referees (at least of some journals) are instructed to look into those issues these days and comment about them, aren't they? 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 Jacob Keller [j-kell...@fsm.northwestern.edu] Sent: Friday, October 28, 2011 5:05 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] raw data deposition What about a case in which two investigators have differences about what cutoff to apply to the data, for example, A thinks that Rsym of 50 should be used regardless of I/sig, and B thinks that I/sig of 2 and Rpim should be used. Usually A would cut off the data at a lower resolution than B, especially with high multiplicity, so B would love to have the images to see what extra info could be gleaned from a higher-res cutoff. Or the converse, A is skeptical of B's cutoff, and wants to see whether the data according to A's cutoff justify B's conclusion. Don't these types of things happen a lot, and wouldn't images be helpful for this? JPK
Re: [ccp4bb] raw data deposition
I don't think anyone is considering archiving all images *as a first step*! I think the obvious first step is to try to get depositors of new structures to the PDB to deposit images at the same time, which to me seems trivially easy and has a reasonably high benefit:cost ratio. Let's just do it, maybe even making it optional at first. I don't even think that in the beginning a common image format would be required--most programs can use multiple formats. Anyway, that could be addressed down the line. Jacob 2011/10/28 Boaz Shaanan bshaa...@exchange.bgu.ac.il: Hi Jacob, There is (very) BIG difference between depositing images for deposited structures and depositing all images ever recorded by any crystallographer on the planet. In the case you presented, A and B can settle the issue by looking at each other's images whether through the database or by exchanging data on their own initiative or even by writing a note to a journal that they completely disagree with one another and start a debate (in case one of them is not willing to exchange images). Besides, I thought that by now there are some standards on how data should be processed (this has been discussed on this BB once every few months, if I'm not mistaken). Isn't that part of the validation process that so many good people have established? Also, to the best of my knowledge (and experience) referees (at least of some journals) are instructed to look into those issues these days and comment about them, aren't they? 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 Jacob Keller [j-kell...@fsm.northwestern.edu] Sent: Friday, October 28, 2011 5:05 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] raw data deposition What about a case in which two investigators have differences about what cutoff to apply to the data, for example, A thinks that Rsym of 50 should be used regardless of I/sig, and B thinks that I/sig of 2 and Rpim should be used. Usually A would cut off the data at a lower resolution than B, especially with high multiplicity, so B would love to have the images to see what extra info could be gleaned from a higher-res cutoff. Or the converse, A is skeptical of B's cutoff, and wants to see whether the data according to A's cutoff justify B's conclusion. Don't these types of things happen a lot, and wouldn't images be helpful for this? JPK -- *** Jacob Pearson Keller Northwestern University Medical Scientist Training Program email: j-kell...@northwestern.edu ***
Re: [ccp4bb] refmac 5.6 ccp4 6.2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, If those hydrogens are in riding position, their coordinates are calculated and should not be refined at all, isn't it? Hence they should appear in the list of deviations at all. Are the hydrogens present in the PDB file? Does it work to delete them all? Tim On 10/28/2011 03:48 AM, Kenneth A. Satyshur wrote: Has anyone had problems with Refmac 5.6? I tried refining our stucture at 1.24 A, aniso with H in riding position and it just exploded! I get error in distances such as Standard External All Bonds: 3270 0 3270 Angles: 4923 0 4923 Chirals: 214 0 214 Planes: 368 0 368 Torsions: 957 0 957 --- Number of reflections in file 90428 Number of reflections read 90428 CGMAT cycle number = 1 Bond distance outliers Bond distance deviations from the ideal 10.000Sigma will be monitored A 5 PRO C A - A 5 PRO HB1 A mod.= 3.344 id.= 1.329 dev= -2.015 sig.= 0.014 A 5 PRO C B - A 5 PRO HB1 B mod.= 2.997 id.= 1.329 dev= -1.668 sig.= 0.014 A 5 PRO HB1 A - A 5 PRO HG1 A mod.= 2.292 id.= 1.458 dev= -0.834 sig.= 0.021 A 5 PRO HB1 A - A 6 LEU HD23A mod.= 7.407 id.= 0.860 dev= -6.547 sig.= 0.020 A 5 PRO HB1 B - A 5 PRO HG1 B mod.= 2.247 id.= 1.458 dev= -0.789 sig.= 0.021 A 5 PRO HB1 B - A 6 LEU HD23B mod.= 6.529 id.= 0.860 dev= -5.669 sig.= 0.020 A 5 PRO HG1 A - A 5 PRO HD1 A mod.= 2.267 id.= 0.980 dev= -1.287 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU N A mod.= 4.860 id.= 1.530 dev= -3.330 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU HD21A mod.= 6.129 id.= 1.525 dev= -4.604 sig.= 0.021 A 5 PRO HG1 B - A 5 PRO HD1 B mod.= 2.236 id.= 0.980 dev= -1.256 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU N B mod.= 4.922 id.= 1.530 dev= -3.392 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU HD21B mod.= 6.664 id.= 1.525 dev= -5.139 sig.= 0.021 A 6 LEU N A - A 6 LEU CA A mod.= 1.467 id.= 0.970 dev= -0.497 sig.= 0.020 A 6 LEU N A - A 6 LEU HA A mod.= 2.005 id.= 0.970 dev= -1.035 sig.= 0.020 A 6 LEU N A - A 6 LEU CB A mod.= 2.497 id.= 1.530 dev= -0.967 sig.= 0.020 A 6 LEU N B - A 6 LEU CA B mod.= 1.469 id.= 0.970 dev= -0.499 sig.= 0.020 A 6 LEU N B - A 6 LEU HA B mod.= 2.032 id.= 0.970 dev= -1.062 sig.= 0.020 A 6 LEU N B - A 6 LEU CB B mod.= 2.446 id.= 1.530 dev= -0.916 sig.= 0.020 A 6 LEU CB A - A 6 LEU HB2 A mod.= 0.969 id.= 1.521 dev= 0.552 sig.= 0.020 A Rfree goes form 17 to 28 and R from 15 to 25. Coot map looks like a bunch of busted insect parts. I use the exact same input using ccp4 6.1.13 and Refmac 5.5 and all is good. I am forced to use the old ccp4 and refmac to publish. Rf 17 R 15. thanks -- Kenneth A. Satyshur, M.S.,Ph.D. Associate Scientist University of Wisconsin Madison, Wisconsin 53706 608-215-5207 - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOqsyaUxlJ7aRr7hoRAlSNAJ99GaOsMUiCpIOhWLd+lBVAqeX+LwCg4pLN 7T4lJXXTQX8LbeyFuGTrQIc= =QdmF -END PGP SIGNATURE-
Re: [ccp4bb] RE : [ccp4bb] refmac 5.6 ccp4 6.2.0
Hi my two cents ...
At I would use full anisotropic refinement only with
relaxed weights on B values. Weight 50 seems to me very
very loose (but I haven't seen the log file). I would use
weight auto and then look at the refmac log file. The Log
file tells you what is the weight matrix being used. For
the next refmac run - use half of THAT weight matrix from
the weight auto run before !
cheers
Stefan
On Fri, 28 Oct 2011 15:22:49 +
LEGRAND Pierre pierre.legr...@synchrotron-soleil.fr
wrote:
Dear Ed,
Not in my case. I still do *restrained* refinement.
I use:
refi type REST -
resi MLKF -
meth CGMAT -
bref MIXED
ncyc 10
blim 0.1 200.0
With both: weight MATRIX 50 or weight AUTO it gives the
same problem.
I have also tested the latest refmac5 version
(Refmac_5.6.0119) and latest dictionaries
(refmac_dictionary_v5.31), but it still produce the same
error, directly from the first cycle.
I can give more details and files off-list if requested.
Cheers,
Pierre
De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la
part de Ed Pozharski [epozh...@umaryland.edu]
Date d'envoi : vendredi 28 octobre 2011 16:00
À : CCP4BB@JISCMAIL.AC.UK
Objet : Re: [ccp4bb] refmac 5.6 ccp4 6.2.0
Just to verify, is this by any chance *unrestrained*
refinement?
On Fri, 2011-10-28 at 09:37 +0200, Tim Gruene wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Kenneth A. Satyshur,
what is your weight set to? If it is set to 'auto', try
setting it to a
specific value and lower that value until the explosion
stops.
If this happens at low matrix values (at 1.24A it
should be way above 5
or 10 for a well refined structure), your resolution
might not be 1.24A,
i.e., you may have integrated noise (check I/sigI over
resolution shells).
Tim
P.S.: I wonder what power somebody might have to
_force_ you use a
specific software version...
On 10/28/2011 03:48 AM, Kenneth A. Satyshur wrote:
Has anyone had problems with Refmac 5.6? I tried
refining our stucture at 1.24 A,
aniso with H in riding position and it just exploded!
I get error in distances such as
Standard External All
Bonds: 3270 0 3270
Angles: 4923 0 4923
Chirals: 214 0 214
Planes: 368 0 368
Torsions: 957 0 957
---
Number of reflections in file 90428
Number of reflections read 90428
CGMAT cycle number = 1
Bond distance
outliers
Bond distance deviations from the ideal 10.000Sigma
will be monitored
A 5 PRO C A - A 5 PRO HB1 A mod.= 3.344
id.= 1.329 dev= -2.015 sig.= 0.014
A 5 PRO C B - A 5 PRO HB1 B mod.= 2.997
id.= 1.329 dev= -1.668 sig.= 0.014
A 5 PRO HB1 A - A 5 PRO HG1 A mod.= 2.292
id.= 1.458 dev= -0.834 sig.= 0.021
A 5 PRO HB1 A - A 6 LEU HD23A mod.= 7.407
id.= 0.860 dev= -6.547 sig.= 0.020
A 5 PRO HB1 B - A 5 PRO HG1 B mod.= 2.247
id.= 1.458 dev= -0.789 sig.= 0.021
A 5 PRO HB1 B - A 6 LEU HD23B mod.= 6.529
id.= 0.860 dev= -5.669 sig.= 0.020
A 5 PRO HG1 A - A 5 PRO HD1 A mod.= 2.267
id.= 0.980 dev= -1.287 sig.= 0.020
A 5 PRO HG1 A - A 6 LEU N A mod.= 4.860
id.= 1.530 dev= -3.330 sig.= 0.020
A 5 PRO HG1 A - A 6 LEU HD21A mod.= 6.129
id.= 1.525 dev= -4.604 sig.= 0.021
A 5 PRO HG1 B - A 5 PRO HD1 B mod.= 2.236
id.= 0.980 dev= -1.256 sig.= 0.020
A 5 PRO HG1 B - A 6 LEU N B mod.= 4.922
id.= 1.530 dev= -3.392 sig.= 0.020
A 5 PRO HG1 B - A 6 LEU HD21B mod.= 6.664
id.= 1.525 dev= -5.139 sig.= 0.021
A 6 LEU N A - A 6 LEU CA A mod.= 1.467
id.= 0.970 dev= -0.497 sig.= 0.020
A 6 LEU N A - A 6 LEU HA A mod.= 2.005
id.= 0.970 dev= -1.035 sig.= 0.020
A 6 LEU N A - A 6 LEU CB A mod.= 2.497
id.= 1.530 dev= -0.967 sig.= 0.020
A 6 LEU N B - A 6 LEU CA B mod.= 1.469
id.= 0.970 dev= -0.499 sig.= 0.020
A 6 LEU N B - A 6 LEU HA B mod.= 2.032
id.= 0.970 dev= -1.062 sig.= 0.020
A 6 LEU N B - A 6 LEU CB B mod.= 2.446
id.= 1.530 dev= -0.916 sig.= 0.020
A 6 LEU CB A - A 6 LEU HB2 A mod.= 0.969
id.= 1.521 dev= 0.552 sig.= 0.020
A
Rfree goes form 17 to 28 and R from 15 to 25.
Coot map looks like a bunch of busted insect parts.
I use the exact same input using ccp4 6.1.13 and
Refmac 5.5 and all is good. I am forced to use the
old ccp4 and refmac to publish. Rf 17 R 15.
thanks
--
Kenneth A. Satyshur, M.S.,Ph.D.
Associate Scientist
University of Wisconsin
Madison,
[ccp4bb] Herbert Hauptman Memorial Date Venue Set
A memorial to honor the life of Herb Hauptman, co-winner of the 1985 Nobel Prize in Chemistry for the development of mathematical methods that would become the basis of direct methods, will be held on Monday 21 November 2011 at 4PM in the UB Center for the Arts on the UB north campus. The scientific community is invited. If you plan to attend from out of town or out of country please give us a heads-up by mailing to Walter Pangborn (pangb...@hwi.buffalo.edumailto:pangb...@hwi.buffalo.edu). You can also check the HWI web site (see below for link) for further details and updates. George T. DeTitta, Ph.D. Principal Research Scientist Hauptman-Woodward Institute Professor Department of Structural Biology SUNY at Buffalo 700 Ellicott Street Buffalo NY 14203-1102 USA (716) 898-8611 (voice) (716) 898-8660 (fax) deti...@hwi.buffalo.edumailto:deti...@hwi.buffalo.edu www.hwi.buffalo.eduhttp://www.hwi.buffalo.edu
[ccp4bb] Fwd: Re: [ccp4bb] refmac 5.6 ccp4 6.2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry, should NOT appear in the list of deviations, of course! - Original Message Subject: Re: [ccp4bb] refmac 5.6 ccp4 6.2.0 Date: Fri, 28 Oct 2011 17:39:06 +0200 From: Tim Gruene t...@shelx.uni-ac.gwdg.de Reply-To: Tim Gruene t...@shelx.uni-ac.gwdg.de To: CCP4BB@JISCMAIL.AC.UK Dear all, If those hydrogens are in riding position, their coordinates are calculated and should not be refined at all, isn't it? Hence they should appear in the list of deviations at all. Are the hydrogens present in the PDB file? Does it work to delete them all? Tim On 10/28/2011 03:48 AM, Kenneth A. Satyshur wrote: Has anyone had problems with Refmac 5.6? I tried refining our stucture at 1.24 A, aniso with H in riding position and it just exploded! I get error in distances such as Standard External All Bonds: 3270 0 3270 Angles: 4923 0 4923 Chirals: 214 0 214 Planes: 368 0 368 Torsions: 957 0 957 --- Number of reflections in file 90428 Number of reflections read 90428 CGMAT cycle number = 1 Bond distance outliers Bond distance deviations from the ideal 10.000Sigma will be monitored A 5 PRO C A - A 5 PRO HB1 A mod.= 3.344 id.= 1.329 dev= -2.015 sig.= 0.014 A 5 PRO C B - A 5 PRO HB1 B mod.= 2.997 id.= 1.329 dev= -1.668 sig.= 0.014 A 5 PRO HB1 A - A 5 PRO HG1 A mod.= 2.292 id.= 1.458 dev= -0.834 sig.= 0.021 A 5 PRO HB1 A - A 6 LEU HD23A mod.= 7.407 id.= 0.860 dev= -6.547 sig.= 0.020 A 5 PRO HB1 B - A 5 PRO HG1 B mod.= 2.247 id.= 1.458 dev= -0.789 sig.= 0.021 A 5 PRO HB1 B - A 6 LEU HD23B mod.= 6.529 id.= 0.860 dev= -5.669 sig.= 0.020 A 5 PRO HG1 A - A 5 PRO HD1 A mod.= 2.267 id.= 0.980 dev= -1.287 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU N A mod.= 4.860 id.= 1.530 dev= -3.330 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU HD21A mod.= 6.129 id.= 1.525 dev= -4.604 sig.= 0.021 A 5 PRO HG1 B - A 5 PRO HD1 B mod.= 2.236 id.= 0.980 dev= -1.256 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU N B mod.= 4.922 id.= 1.530 dev= -3.392 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU HD21B mod.= 6.664 id.= 1.525 dev= -5.139 sig.= 0.021 A 6 LEU N A - A 6 LEU CA A mod.= 1.467 id.= 0.970 dev= -0.497 sig.= 0.020 A 6 LEU N A - A 6 LEU HA A mod.= 2.005 id.= 0.970 dev= -1.035 sig.= 0.020 A 6 LEU N A - A 6 LEU CB A mod.= 2.497 id.= 1.530 dev= -0.967 sig.= 0.020 A 6 LEU N B - A 6 LEU CA B mod.= 1.469 id.= 0.970 dev= -0.499 sig.= 0.020 A 6 LEU N B - A 6 LEU HA B mod.= 2.032 id.= 0.970 dev= -1.062 sig.= 0.020 A 6 LEU N B - A 6 LEU CB B mod.= 2.446 id.= 1.530 dev= -0.916 sig.= 0.020 A 6 LEU CB A - A 6 LEU HB2 A mod.= 0.969 id.= 1.521 dev= 0.552 sig.= 0.020 A Rfree goes form 17 to 28 and R from 15 to 25. Coot map looks like a bunch of busted insect parts. I use the exact same input using ccp4 6.1.13 and Refmac 5.5 and all is good. I am forced to use the old ccp4 and refmac to publish. Rf 17 R 15. thanks -- Kenneth A. Satyshur, M.S.,Ph.D. Associate Scientist University of Wisconsin Madison, Wisconsin 53706 608-215-5207 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOqtB3UxlJ7aRr7hoRAq4bAKCQXz5E7KdEFw/Xvg6QhYlap42GhwCgnPJz 9g5GY7ZKW33r2Ejy06thT2M= =8E40 -END PGP SIGNATURE-
Re: [ccp4bb] RE : [ccp4bb] refmac 5.6 ccp4 6.2.0
Dear Pierre Resolution seems to be good enough for full anisotropic refinement. Why don't you try this and see if it stabilises refinement. regards Garib On 28 Oct 2011, at 16:22, LEGRAND Pierre wrote: Dear Ed, Not in my case. I still do *restrained* refinement. I use: refi type REST - resi MLKF - meth CGMAT - bref MIXED ncyc 10 blim 0.1 200.0 With both: weight MATRIX 50 or weight AUTO it gives the same problem. I have also tested the latest refmac5 version (Refmac_5.6.0119) and latest dictionaries (refmac_dictionary_v5.31), but it still produce the same error, directly from the first cycle. I can give more details and files off-list if requested. Cheers, Pierre De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Ed Pozharski [epozh...@umaryland.edu] Date d'envoi : vendredi 28 octobre 2011 16:00 À : CCP4BB@JISCMAIL.AC.UK Objet : Re: [ccp4bb] refmac 5.6 ccp4 6.2.0 Just to verify, is this by any chance *unrestrained* refinement? On Fri, 2011-10-28 at 09:37 +0200, Tim Gruene wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Kenneth A. Satyshur, what is your weight set to? If it is set to 'auto', try setting it to a specific value and lower that value until the explosion stops. If this happens at low matrix values (at 1.24A it should be way above 5 or 10 for a well refined structure), your resolution might not be 1.24A, i.e., you may have integrated noise (check I/sigI over resolution shells). Tim P.S.: I wonder what power somebody might have to _force_ you use a specific software version... On 10/28/2011 03:48 AM, Kenneth A. Satyshur wrote: Has anyone had problems with Refmac 5.6? I tried refining our stucture at 1.24 A, aniso with H in riding position and it just exploded! I get error in distances such as Standard External All Bonds: 3270 0 3270 Angles: 4923 0 4923 Chirals: 214 0 214 Planes: 368 0 368 Torsions: 957 0 957 --- Number of reflections in file 90428 Number of reflections read 90428 CGMAT cycle number = 1 Bond distance outliers Bond distance deviations from the ideal 10.000Sigma will be monitored A 5 PRO C A - A 5 PRO HB1 A mod.= 3.344 id.= 1.329 dev= -2.015 sig.= 0.014 A 5 PRO C B - A 5 PRO HB1 B mod.= 2.997 id.= 1.329 dev= -1.668 sig.= 0.014 A 5 PRO HB1 A - A 5 PRO HG1 A mod.= 2.292 id.= 1.458 dev= -0.834 sig.= 0.021 A 5 PRO HB1 A - A 6 LEU HD23A mod.= 7.407 id.= 0.860 dev= -6.547 sig.= 0.020 A 5 PRO HB1 B - A 5 PRO HG1 B mod.= 2.247 id.= 1.458 dev= -0.789 sig.= 0.021 A 5 PRO HB1 B - A 6 LEU HD23B mod.= 6.529 id.= 0.860 dev= -5.669 sig.= 0.020 A 5 PRO HG1 A - A 5 PRO HD1 A mod.= 2.267 id.= 0.980 dev= -1.287 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU N A mod.= 4.860 id.= 1.530 dev= -3.330 sig.= 0.020 A 5 PRO HG1 A - A 6 LEU HD21A mod.= 6.129 id.= 1.525 dev= -4.604 sig.= 0.021 A 5 PRO HG1 B - A 5 PRO HD1 B mod.= 2.236 id.= 0.980 dev= -1.256 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU N B mod.= 4.922 id.= 1.530 dev= -3.392 sig.= 0.020 A 5 PRO HG1 B - A 6 LEU HD21B mod.= 6.664 id.= 1.525 dev= -5.139 sig.= 0.021 A 6 LEU N A - A 6 LEU CA A mod.= 1.467 id.= 0.970 dev= -0.497 sig.= 0.020 A 6 LEU N A - A 6 LEU HA A mod.= 2.005 id.= 0.970 dev= -1.035 sig.= 0.020 A 6 LEU N A - A 6 LEU CB A mod.= 2.497 id.= 1.530 dev= -0.967 sig.= 0.020 A 6 LEU N B - A 6 LEU CA B mod.= 1.469 id.= 0.970 dev= -0.499 sig.= 0.020 A 6 LEU N B - A 6 LEU HA B mod.= 2.032 id.= 0.970 dev= -1.062 sig.= 0.020 A 6 LEU N B - A 6 LEU CB B mod.= 2.446 id.= 1.530 dev= -0.916 sig.= 0.020 A 6 LEU CB A - A 6 LEU HB2 A mod.= 0.969 id.= 1.521 dev= 0.552 sig.= 0.020 A Rfree goes form 17 to 28 and R from 15 to 25. Coot map looks like a bunch of busted insect parts. I use the exact same input using ccp4 6.1.13 and Refmac 5.5 and all is good. I am forced to use the old ccp4 and refmac to publish. Rf 17 R 15. thanks -- Kenneth A. Satyshur, M.S.,Ph.D. Associate Scientist University of Wisconsin Madison, Wisconsin 53706 608-215-5207 - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOqluhUxlJ7aRr7hoRAjadAJ9Df2hbWjixDCdS3Z4DB7mm4ubRIACeOw6X 6JkjyzRUdxqjH/9b/oftBjE= =xRXE -END PGP
Re: [ccp4bb] raw data deposition
I have said my piece of the issue of depositing but there is one comment I would like to address. Besides, I thought that by now there are some standards on how data should be processed (this has been discussed on this BB once every few months, if I'm not mistaken). Isn't that part of the validation process that so many good people have established? Also, to the best of my knowledge (and experience) referees (at least of some journals) are instructed to look into those issues these days and comment about them, aren't they? There is a big difference between data that is processed correctly and data that is processed well. I'm reminded of a Yogi Berra quote In theory, theory and practice are the same. In practice, they are not. Every year our grad level crystallography course would take the same lysozyme data set and break into groups of two to process them independently in HKL2000 and every year we'd get a vastly different array of statistics. All of the processing would produce valid structure factors that were essentially the same and all would pass SFCHECK. The difference in the numbers varied for many reasons including the choice of reference image, initial spot number picking, profile fitting radius, spot size, the use of 3D profile fitting, choice of scaling factors and whether appropriate sacrifices had been made to the Denzo gods. And though the overall backbone and structure remained mostly the same there were clearly some who had better maps than the others. So yes there is a standard protocol in place and it can identify and correct gross error but by no means does that indicate the data was processed well. Sincerely, Katherine
Re: [ccp4bb] raw data deposition
On Oct 27, 2011, at 11:56 PM, James Stroud wrote: This is a poor criterion on which to base any conclusions or decisions. We can blame the lack of examples on unavailability of the data. Agreed. Reprocessing the data resulting in a a different biological result is my personal reason and motivates me to support raw data deposition. However, I'm not the one that needs convincing.. it's the other PI's/graduate students/postdocs (who may see MX as a simple tool to get an answer for some larger question), who need to see the value of depositing raw MX images. The point of my email is to elicit other people's reasons why raw data deposition is necessary. Right now, I'd love to get my hands on the raw images for a particular cryoEM data set, but they are not available--only the maps. But the maps assume one symmetry and I have a hypothesis that the true symmetry is different. I could test my hypothesis by reprocessing the data were it available. and thank you for providing yours . F - Francis E. Reyes M.Sc. 215 UCB University of Colorado at Boulder
[ccp4bb] RE : [ccp4bb] RE : [ccp4bb] refmac 5.6 ccp4 6.2.0
Thanks all for your suggestions,
Here's a little summary of my recent tests.
I am currently using WEIGHT AUTO and BREF MIXED with a pdb file that contains
ANISOU definition for all atoms except hydrogens.
Final results for BREF MIXED refinement :
InitialFinal
R factor0.0880 0.0867
R free0.0932 0.0925
Rms BondLength0.0174 0.0189
Rms BondAngle2.8613 2.8740
Rms ChirVolume0.1076 0.1146
Final results for BREF ANISO refinement:
InitialFinal
R factor0.0880 0.0874
R free0.0932 0.0956
Rms BondLength0.0174 0.0189
Rms BondAngle2.8613 2.8683
Rms ChirVolume0.1076 0.1151
In the WEIGHT AUTO run refmac5 uses: Weight matrix137.7641
Final results for WEIGHT MATRIX 60 refinement:
InitialFinal
R factor0.0880 0.0872
R free0.0932 0.0922
Rms BondLength0.0174 0.0181
Rms BondAngle2.8613 2.8632
Rms ChirVolume0.1076 0.1134
I have just sent Garib different data files so that he can reproduce the
problem one can have with H naming/dictionaries definitions.
When it happens, from the same initial pdb with WEIGHT AUTO and BREF MIXED
but a differente cif definition (from the latest refmac_dictionary_v5.31) here
what it gives:
InitialFinal
R factor0.0880 0.1820
R free0.0932 0.1869
Rms BondLength2.8573 2.3884
Rms BondAngle 35.7010 34.7547
Rms ChirVolume 10.5335 4.2429
I hope it helps to clarify the situation,
Cheers,
Pierre
De : Garib Murshudov [garib.murshu...@gmail.com] de la part de Garib N
Murshudov [ga...@mrc-lmb.cam.ac.uk]
Date d'envoi : vendredi 28 octobre 2011 17:49
À : LEGRAND Pierre
Cc : CCP4BB@JISCMAIL.AC.UK
Objet : Re: [ccp4bb] RE : [ccp4bb] refmac 5.6 ccp4 6.2.0
Dear Pierre
Resolution seems to be good enough for full anisotropic refinement. Why don't
you try this and see if it stabilises refinement.
regards
Garib
On 28 Oct 2011, at 16:22, LEGRAND Pierre wrote:
Dear Ed,
Not in my case. I still do *restrained* refinement.
I use:
refi type REST -
resi MLKF -
meth CGMAT -
bref MIXED
ncyc 10
blim 0.1 200.0
With both: weight MATRIX 50 or weight AUTO it gives the same problem.
I have also tested the latest refmac5 version (Refmac_5.6.0119) and latest
dictionaries (refmac_dictionary_v5.31), but it still produce the same error,
directly from the first cycle.
I can give more details and files off-list if requested.
Cheers,
Pierre
De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Ed Pozharski
[epozh...@umaryland.edu]
Date d'envoi : vendredi 28 octobre 2011 16:00
À : CCP4BB@JISCMAIL.AC.UKmailto:CCP4BB@JISCMAIL.AC.UK
Objet : Re: [ccp4bb] refmac 5.6 ccp4 6.2.0
Just to verify, is this by any chance *unrestrained* refinement?
On Fri, 2011-10-28 at 09:37 +0200, Tim Gruene wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Kenneth A. Satyshur,
what is your weight set to? If it is set to 'auto', try setting it to a
specific value and lower that value until the explosion stops.
If this happens at low matrix values (at 1.24A it should be way above 5
or 10 for a well refined structure), your resolution might not be 1.24A,
i.e., you may have integrated noise (check I/sigI over resolution shells).
Tim
P.S.: I wonder what power somebody might have to _force_ you use a
specific software version...
On 10/28/2011 03:48 AM, Kenneth A. Satyshur wrote:
Has anyone had problems with Refmac 5.6? I tried refining our stucture at 1.24
A,
aniso with H in riding position and it just exploded! I get error in distances
such as
Standard External All
Bonds: 3270 0 3270
Angles: 4923 0 4923
Chirals: 214 0 214
Planes: 368 0 368
Torsions: 957 0 957
---
Number of reflections in file 90428
Number of reflections read 90428
CGMAT cycle number = 1
Bond distance outliers
Bond distance deviations from the ideal 10.000Sigma will be monitored
A 5 PRO C A - A 5 PRO HB1 A mod.= 3.344 id.= 1.329 dev= -2.015
sig.= 0.014
A 5 PRO C B - A 5 PRO HB1 B mod.= 2.997 id.= 1.329 dev= -1.668
sig.= 0.014
A 5 PRO HB1 A - A 5 PRO HG1 A mod.= 2.292 id.= 1.458 dev= -0.834
sig.= 0.021
A 5 PRO HB1 A - A 6 LEU HD23A mod.= 7.407 id.= 0.860 dev= -6.547
sig.= 0.020
A 5 PRO HB1 B - A 5 PRO HG1 B mod.= 2.247 id.= 1.458 dev= -0.789
sig.= 0.021
A 5 PRO HB1 B - A 6 LEU HD23B mod.= 6.529 id.= 0.860 dev= -5.669
Re: [ccp4bb] raw data deposition
On Friday, October 28, 2011 08:29:46 am Boaz Shaanan wrote: Besides, I thought that by now there are some standards on how data should be processed (this has been discussed on this BB once every few months, if I'm not mistaken). If this is true, I must not have got the memo! I hear differences of opinion among senior crystallographers, even just considering discussions at our local research meetings, let alone in the context of world-wide practice. - Where to set a resolution cutoff? - Use or not use a criterion on Rmerge (or Rpim or maximum scale factor or completeness in shell)? - Use all images in a run, or limit them to some maximal amount of decay? - Empirical absorption correction during scaling? - XDS? HKL? mosflm? Isn't that part of the validation process that so many good people have established? Also, to the best of my knowledge (and experience) referees (at least of some journals) are instructed to look into those issues these days and comment about them, aren't they? Cheers, Boaz As to what reviewers have access to, at best one sees a Table 1 with summary statistics. But rarely if ever do we see the protocol or decisions that went into the processing that yielded those statistics. And more to the point of the current issue, a reviewer without access to the original diffraction images cannot possibly comment on - Were there unexplained spots that might have indicated a supercell or other strangeness with the lattice? - Evidence of non-merohedral twinning in the diffraction pattern? - Was the integration box size chosen appropriately? - Did the diffraction data clearly extend beyond the resolution limit chosen by the authors? I hasten to add that I am not advocating for a requirement that the diffraction images be sent to reviewers of a manuscript! But these are all examples of points where current opinion differs, and standard practice in the future may differ even more. If the images are saved, then the quality of the data extracted from them may improve using those not-yet-developed programs and protocols. So there is, to me, clearly some value in saving them. How to balance of that value against the cost? - that's another question. Ethan -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742
[ccp4bb] Seeded rescreening with robot?
Hi all, I am trying to optimize crystals and have heard of a technique where one can prepare a seedstock from existing crystals and use it to broadly re-screen from scratch for hits in new conditions. I have access to a mosquito robot and was wondering if anyone has a protocol or recommendations on how to go about doing this using a robot for screening. Thank you! Randy Watson
[ccp4bb] Phaser: ensemble not set
Subject: Phaser: ensemble not set Hello: I try to use Phaser under MR. The program complain: ensemble not set. The ensemble box keeps blank and does not allow to click. I use: ccp4-6.2.0 Window Vista Business Thanks for advice ROS
Re: [ccp4bb] raw data deposition
Hi Francis, Even though they are not published, there are enough models in the PDB for which reevaluation of the crystallographic data leads to new biological insight. Unfortunately, a lot of the insight is of the type that ligand doesn't really bind, or at least not in that pose. Another nice one is a sequencing error in a Uniprot entry that became obvious after critically looking at the structure and the maps (the authors, of both structure and sequence, acknowledge the problem, but the entry is not yet fixed, so no names). Yesterday, I had a case where I didn't so much mistrust the model, but I would still have liked to have access to the images. There was something weird in the maps that was also clearly there in pictures of the maps in the linked publication, but it was not discussed. Needless to say, I'm in favour of depositing images. At least for published structure models. There is still a lot of interesting things to find in current and future PDB entries. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of James Stroud Sent: Friday, October 28, 2011 07:57 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] raw data deposition On Oct 27, 2011, at 5:22 PM, Francis E Reyes wrote: So I ask again, are there literature examples where reevaluation of the crystallographic data has directly resulted in new biological insights into the system being modeled? This is a poor criterion on which to base any conclusions or decisions. We can blame the lack of examples on unavailability of the data. Right now, I'd love to get my hands on the raw images for a particular cryoEM data set, but they are not available--only the maps. But the maps assume one symmetry and I have a hypothesis that the true symmetry is different. I could test my hypothesis by reprocessing the data were it available. James
Re: [ccp4bb] Seeded rescreening with robot?
I would be glad to share ours. Artem On Oct 28, 2011 1:29 PM, Watson, Randy ewats...@uthsc.edu wrote: Hi all, I am trying to optimize crystals and have heard of a technique where one can prepare a seedstock from existing crystals and use it to broadly re-screen from scratch for hits in new conditions. I have access to a mosquito robot and was wondering if anyone has a protocol or recommendations on how to go about doing this using a robot for screening. Thank you! Randy Watson
[ccp4bb] shuttered vs continuous data collection
Changed the subject line to try and keep the original thread on-topic. George is right that the acceleration/decelleration introduces error, but only in what I like to call standing start mode. These days I think most facilities use running starts where the spindle is brought up to the degrees/second required by the the exposure just before opening the shutter at the desired starting phi position, and then closing the shutter at the ending phi with the sample still moving at full speed, allowing it to decelerate afterward. The overhead for achieving a stable velocity depends on the speed, of course, but this prep time is generally not more than a few hundred milliseconds. This is NOT the same thing as the shutter jitter! In fact, the opening time of the shutter is also not the jitter. Even if the shutter takes 100 ms to open, as long as that is reproducible, it won't hurt the data quality. Shutter jitter is the rms deviation of all the true opening times from the average. I have not measured this on any beamline other than my own, but here the shutter jitter is rms ~0.6 millisecond, which translates to 0.0006 degrees at 1 degree/s. Assuming a mosaic spread of 0.5 degrees, this introduces an error as large as 0.3%. I say as large as because only partials are affected by shutter jitter, not fulls. All that said, however, if Rmerge is 3%, then sqrt(3%^2-0.3%^2)= 2.985% error is due to something other than the shutter. We thought ourselves quite clever here at ALS 10 years ago when we implemented the running-starts for exposures on these new-fangled (at the time) air bearing spindles. Only to find that they didn't really make all that much difference when compared side-by-side with standing starts. Unless, of course, we started doing REALLY short exposures, like 0.08s or less. Then the noise power spectrum of the beam (flicker noise) starts to become important. This is actually easier to measure than you might think: just put up a photodiode and record samples of the beam intensity as fast as you can. The rms variation in the recorded intensity, divided by the square root of the sampling rate is the flicker noise. I typically get 0.15%/sqrt(Hz), which means that the average variation in integrated beam intensity over a 1s exposure is 0.15%, and that of a 0.01s exposure is 1.5%. That is, the longer you average, the more the flicker noise of the beam is averaged out. The trick with flicker noise, however, is that the relevant exposure time is the time it takes the relp to transit the Ewald sphere, and not the commanded exposure time of the image. This means that low-mosaic crystal data collections are more sensitive to beam instability. An important property of flicker noise is that sampling more finely and averaging afterward does not change the signal-to-noise ratio (by definition, actually). You can try this by generating random numbers with a mean of 100 and rms error 10% each. If you average them in groups of 100, the result will be 100 +/- 1%, and if you take them in groups of 10 and then average 10 of those groups at a time, you still get the same answer no matter what: 1% error. However, if you attenuate the beam 10 fold and collect 10x more data points (averaging 1000 values of 10 +/- 10%) you will get 10 +/- 0.3%, reducing the flicker noise by a factor of ~3. This may seem magical if you are used to thinking about photon-counting noise because photon-counting noise does not depend on how much time you take to collect the photons, but every other kind of noise does! It is therefore important not to forget that counting detectors introduce a new kind of error: pile-up. The Lambert omega function can be used to correct for pile-up (and that is was Pilatus does), but this correction relies on the assumption that the true intensity over a given acquisition time was constant (Poisson statistics). This is definitely not the case with spots moving quickly through the Ewald sphere, and that is why Dectris recommends fine phi-slicing. Fine slicing has advantages on any detector (Pflugrath, 1999), but it is an absolute requirement for getting good data from any counting device, including the Pilatus. Of course, this does not mean you can't add up fine-sliced images after they are acquired to form a coarser-sliced data set, but that is a form of lossy compression. Formally, pile-up, beam flicker and shutter jitter fall into what I call the % error category, as does the noise induced by crystal vibration (usually buffeting in the cryostream) or simply a noisy velocity control on the spindle motor. But since continuous-readout detectors are not immune to beam flicker, sample vibration nor velocity control instability, I decided not to mention them earlier. -James Holton MAD Scientist On 10/27/2011 6:36 AM, George M. Sheldrick wrote: There are two further complications. In non-continuous mode, the goniometer
[ccp4bb] NCS 2-fold perpendicular to crystal 2-fold
Hello Everyone, I have data sets that scaled fairly welll in C2 2 21, but intensity statistics suggested twinning. I was able to solve the structure in P1 21 1 (Rwork0.19/Rfree0.24 at 2.3A) with OK looking maps. I notice that I have 2-fold NCS that is paralell to the crystallographic A axis, perpendicular to my crystallographic 2-fold B axis. Can anyone ellaborate on the effect of this on the data (indexing/scaling and refining)? Best,
[ccp4bb] To archive or not to archive, that's the question!
Hi all, It appears that during my time here at Cold Spring Harbor, I have missed a small debate on CCP4BB (in which my name has been used in vain to boot). I have not yet had time to read all the contributions, but would like to make a few points that hopefully contribute to the discussion and keep it with two feet on Earth (as opposed to La La Land where the people live who think that image archiving can be done on a shoestring budget... more about this in a bit). Note: all of this is on personal title, i.e. not official wwPDB gospel. Oh, and sorry for the new subject line, but this way I can track the replies more easily. It seems to me that there are a number of issues that need to be separated: (1) the case for/against storing raw data (2) implementation and resources (3) funding (4) location I will say a few things about each of these issues in turn: --- (1) Arguments in favour and against the concept of storing raw image data, as well as possible alternative solutions that could address some of the issues at lower cost or complexity. I realise that my views carry a weight=1.0 just like everybody else's, and many of the arguments and counter-arguments have already been made, so I will not add to these at this stage. --- (2) Implementation details and required resources. If the community should decide that archiving raw data would be scientifically useful, then it has to decide how best to do it. This will determine the level of resources required to do it. Questions include: - what should be archived? (See Jim H's list from (a) to (z) or so.) An initial plan would perhaps aim for the images associated with the data used in the final refinement of deposited structures. - how much data are we talking about per dataset/structure/year? - should it be stored close to the source (i.e., responsibility and costs for depositors or synchrotrons) or centrally (i.e., costs for some central resource)? If it is going to be stored centrally, the cost will be substantial. For example, at the EBI -the European Bioinformatics Institute- we have 15 PB of storage. We pay about 1500 GBP (~2300 USD) per TB of storage (not the kind you buy at Dixons or Radio Shack, obviously). For stored data, we have a data-duplication factor of ~8, i.e. every file is stored 8 times (at three data centres, plus back-ups, plus a data-duplication centre, plus unreleased versus public versions of the archive). (Note - this is only for the EBI/PDBe! RCSB and PDBj will have to acquire storage as well.) Moreover, disks have to be housed in a building (not free!), with cooling, security measures, security staff, maintenance staff, electricity (substantial cost!), rental of a 1-10 Gb/s connection, etc. All hardware has a life-cycle of three years (barring failures) and then needs to be replaced (at lower cost, but still not free). - if the data is going to be stored centrally, how will it get there? Using ftp will probably not be feasible. - if it is not stored centrally, how will long-term data availability be enforced? (Otherwise I could have my data on a public server until my paper comes out in print, and then remove it.) - what level of annotation will be required? There is no point in having zillions of files lying around if you don't know which structure/crystal/sample they belong to, at what wavelength they were recorded, if they were used in refinement or not, etc. - an issue that has not been raised yet, I think: who is going to validate that the images actually correspond to the structure factor amplitudes or intensities that were used in the refinement? This means that the data will have to be indexed, integrated, scaled, merged, etc. and finally compared to the deposited Fobs or Iobs. This will have to be done for *10,000 data sets a year*... And I can already imagine the arguments that will follow between depositors and re-processors about what software to use, what resolution cut-off, what outlier-rejection criteria, etc. How will conflicts and discrepancies be resolved? This could well end up taking a day of working time per data set, i.e. with 200 working days per year, one would need 50 *new* staff for this task alone. For comparison: worldwide, there is currently a *total* of ~25 annotators working for the wwPDB partners... Not many of you know that (about 10 years ago) I spent probably an entire year of my life sorting out the mess that was the PDB structure factor files pre-EDS... We were apparently the first people to ever look at the tens of thousands of structure factor files and try to use all of them to calculate maps for the EDS server. (If there were others who attempted this before us, they had probably run away screaming.) This went well for many files, but there were many, many files that had problems. There were dozens of different kinds of issues: non-CIF files, CIF files with wrong headers, Is instead of Fs,
Re: [ccp4bb] To archive or not to archive, that's the question!
Gerard I said in INCREASING order of influence/power i.e. you are in first place. The joke comes from I used to think if there was reincarnation, I wanted to come back as the President or the Pope or a .400 baseball hitter. But now I want to come back as the bond market. You can intimidate everyone. --James Carville, Clinton campaign strategist Thanks for the comprehensive reply Regards Colin -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Gerard DVD Kleywegt Sent: 28 October 2011 22:03 To: ccp4bb Subject: [ccp4bb] To archive or not to archive, that's the question! Hi all, It appears that during my time here at Cold Spring Harbor, I have missed a small debate on CCP4BB (in which my name has been used in vain to boot). I have not yet had time to read all the contributions, but would like to make a few points that hopefully contribute to the discussion and keep it with two feet on Earth (as opposed to La La Land where the people live who think that image archiving can be done on a shoestring budget... more about this in a bit). Note: all of this is on personal title, i.e. not official wwPDB gospel. Oh, and sorry for the new subject line, but this way I can track the replies more easily. It seems to me that there are a number of issues that need to be separated: (1) the case for/against storing raw data (2) implementation and resources (3) funding (4) location I will say a few things about each of these issues in turn: --- (1) Arguments in favour and against the concept of storing raw image data, as well as possible alternative solutions that could address some of the issues at lower cost or complexity. I realise that my views carry a weight=1.0 just like everybody else's, and many of the arguments and counter-arguments have already been made, so I will not add to these at this stage. --- (2) Implementation details and required resources. If the community should decide that archiving raw data would be scientifically useful, then it has to decide how best to do it. This will determine the level of resources required to do it. Questions include: - what should be archived? (See Jim H's list from (a) to (z) or so.) An initial plan would perhaps aim for the images associated with the data used in the final refinement of deposited structures. - how much data are we talking about per dataset/structure/year? - should it be stored close to the source (i.e., responsibility and costs for depositors or synchrotrons) or centrally (i.e., costs for some central resource)? If it is going to be stored centrally, the cost will be substantial. For example, at the EBI -the European Bioinformatics Institute- we have 15 PB of storage. We pay about 1500 GBP (~2300 USD) per TB of storage (not the kind you buy at Dixons or Radio Shack, obviously). For stored data, we have a data-duplication factor of ~8, i.e. every file is stored 8 times (at three data centres, plus back-ups, plus a data-duplication centre, plus unreleased versus public versions of the archive). (Note - this is only for the EBI/PDBe! RCSB and PDBj will have to acquire storage as well.) Moreover, disks have to be housed in a building (not free!), with cooling, security measures, security staff, maintenance staff, electricity (substantial cost!), rental of a 1-10 Gb/s connection, etc. All hardware has a life-cycle of three years (barring failures) and then needs to be replaced (at lower cost, but still not free). - if the data is going to be stored centrally, how will it get there? Using ftp will probably not be feasible. - if it is not stored centrally, how will long-term data availability be enforced? (Otherwise I could have my data on a public server until my paper comes out in print, and then remove it.) - what level of annotation will be required? There is no point in having zillions of files lying around if you don't know which structure/crystal/sample they belong to, at what wavelength they were recorded, if they were used in refinement or not, etc. - an issue that has not been raised yet, I think: who is going to validate that the images actually correspond to the structure factor amplitudes or intensities that were used in the refinement? This means that the data will have to be indexed, integrated, scaled, merged, etc. and finally compared to the deposited Fobs or Iobs. This will have to be done for *10,000 data sets a year*... And I can already imagine the arguments that will follow between depositors and re-processors about what software to use, what resolution cut-off, what outlier-rejection criteria, etc. How will conflicts and discrepancies be resolved? This could well end up taking a day of working time per data set, i.e. with 200 working days per year, one would need 50 *new* staff for this task alone. For comparison: worldwide, there is currently a *total* of ~25 annotators working for the wwPDB partners...
Re: [ccp4bb] To archive or not to archive, that's the question!
Gerard I said in INCREASING order of influence/power i.e. you are in first place. Ooo! *Now* it makes sense! :-) --Gerard The joke comes from I used to think if there was reincarnation, I wanted to come back as the President or the Pope or a .400 baseball hitter. But now I want to come back as the bond market. You can intimidate everyone. --James Carville, Clinton campaign strategist Thanks for the comprehensive reply Regards Colin -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Gerard DVD Kleywegt Sent: 28 October 2011 22:03 To: ccp4bb Subject: [ccp4bb] To archive or not to archive, that's the question! Hi all, It appears that during my time here at Cold Spring Harbor, I have missed a small debate on CCP4BB (in which my name has been used in vain to boot). I have not yet had time to read all the contributions, but would like to make a few points that hopefully contribute to the discussion and keep it with two feet on Earth (as opposed to La La Land where the people live who think that image archiving can be done on a shoestring budget... more about this in a bit). Note: all of this is on personal title, i.e. not official wwPDB gospel. Oh, and sorry for the new subject line, but this way I can track the replies more easily. It seems to me that there are a number of issues that need to be separated: (1) the case for/against storing raw data (2) implementation and resources (3) funding (4) location I will say a few things about each of these issues in turn: --- (1) Arguments in favour and against the concept of storing raw image data, as well as possible alternative solutions that could address some of the issues at lower cost or complexity. I realise that my views carry a weight=1.0 just like everybody else's, and many of the arguments and counter-arguments have already been made, so I will not add to these at this stage. --- (2) Implementation details and required resources. If the community should decide that archiving raw data would be scientifically useful, then it has to decide how best to do it. This will determine the level of resources required to do it. Questions include: - what should be archived? (See Jim H's list from (a) to (z) or so.) An initial plan would perhaps aim for the images associated with the data used in the final refinement of deposited structures. - how much data are we talking about per dataset/structure/year? - should it be stored close to the source (i.e., responsibility and costs for depositors or synchrotrons) or centrally (i.e., costs for some central resource)? If it is going to be stored centrally, the cost will be substantial. For example, at the EBI -the European Bioinformatics Institute- we have 15 PB of storage. We pay about 1500 GBP (~2300 USD) per TB of storage (not the kind you buy at Dixons or Radio Shack, obviously). For stored data, we have a data-duplication factor of ~8, i.e. every file is stored 8 times (at three data centres, plus back-ups, plus a data-duplication centre, plus unreleased versus public versions of the archive). (Note - this is only for the EBI/PDBe! RCSB and PDBj will have to acquire storage as well.) Moreover, disks have to be housed in a building (not free!), with cooling, security measures, security staff, maintenance staff, electricity (substantial cost!), rental of a 1-10 Gb/s connection, etc. All hardware has a life-cycle of three years (barring failures) and then needs to be replaced (at lower cost, but still not free). - if the data is going to be stored centrally, how will it get there? Using ftp will probably not be feasible. - if it is not stored centrally, how will long-term data availability be enforced? (Otherwise I could have my data on a public server until my paper comes out in print, and then remove it.) - what level of annotation will be required? There is no point in having zillions of files lying around if you don't know which structure/crystal/sample they belong to, at what wavelength they were recorded, if they were used in refinement or not, etc. - an issue that has not been raised yet, I think: who is going to validate that the images actually correspond to the structure factor amplitudes or intensities that were used in the refinement? This means that the data will have to be indexed, integrated, scaled, merged, etc. and finally compared to the deposited Fobs or Iobs. This will have to be done for *10,000 data sets a year*... And I can already imagine the arguments that will follow between depositors and re-processors about what software to use, what resolution cut-off, what outlier-rejection criteria, etc. How will conflicts and discrepancies be resolved? This could well end up taking a day of working time per data set, i.e. with 200 working days per year, one would need 50 *new* staff for this task alone. For comparison: worldwide, there is currently a *total* of ~25 annotators working for the wwPDB partners...
Re: [ccp4bb] To archive or not to archive, that's the question!
On Friday, October 28, 2011 02:02:46 pm Gerard DVD Kleywegt wrote: I'm a tad disappointed to be only in fourth place, Colin! What has the Pope ever done for crystallography? http://covers.openlibrary.org/b/id/5923051-L.jpg -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742
Re: [ccp4bb] To archive or not to archive, that's the question!
On Friday, October 28, 2011 02:02:46 pm Gerard DVD Kleywegt wrote: I'm a tad disappointed to be only in fourth place, Colin! What has the Pope ever done for crystallography? http://covers.openlibrary.org/b/id/5923051-L.jpg Fock'n'Pope! Great find, Ethan! So maybe he deserves fourth place after all. --Gerard ** Gerard J. Kleywegt http://xray.bmc.uu.se/gerard mailto:ger...@xray.bmc.uu.se ** The opinions in this message are fictional. Any similarity to actual opinions, living or dead, is purely coincidental. ** Little known gastromathematical curiosity: let z be the radius and a the thickness of a pizza. Then the volume of that pizza is equal to pi*z*z*a ! **
[ccp4bb] Computational Systems Biology Postdoctoral Position
Computational Systems Biology Postdoctoral Position Postdoctoral applicants are sought in Computational Systems Biology to work with Professor Jeffrey Skolnick. Specific areas include the development and application of novel algorithms for the: * Structure prediction of GPCRs followed by virtual ligand screening * Prediction of protein-protein and protein-DNA interactions * Proteome scale virtual ligand screening * Development of algorithms to minimize drug side effects * Development of multiscale modeling approaches for the simulation of virtual cells Highly creative and outstanding individuals are sought with the following qualifications: * Extensive experience in developing computer code in languages such as Fortran, C, C++, Perl. * Previous experience doing international quality research in structural modeling, virtual ligand screening, bioinformatics, or computational genomics would be major advantages. * A track record of publication in high quality, international journals. * Ability to work in a team, yet think independently. To apply, please email your CV to : skoln...@gatech.edu
[ccp4bb] Computational Systems Biology Postdoctoral Position in Macromolecular Modeling and Protein Structure Prediction
Computational Systems Biology Postdoctoral Position in Macromolecular Modeling and Protein Structure Prediction Outstanding Postdoctoral applicants are sought in Computational Systems Biology to work with Professor Jeffrey Skolnick at the Georgia Tech Center for the Study of Systems Biology in the following areas: * Development of algorithms for the prediction of protein tertiary structure using both template based and template free approaches based on both knowledge and physics based force fields. * Development of algorithms for the prediction and refinement of GPCR structures. * Development of approaches to predict RNA-protein interactions. * Development of algorithms to minimize drug side effects * Application of the above to assist in the structure based annotation of proteomes Highly creative, outstanding individuals with a background in biophysics, computational physics, or bioinformatics are sought with the following qualifications: * Demonstrated ability to do high quality research in protein structure prediction, RNA modeling, large scale biological simulations, Brownian Dynamics, bioinformatics, or computational genomics. * A track record of publication in high quality, international journals. * Ability to work in a team, yet think independently. * Extensive computer code development experience using languages such as Fortran, C, C++, and/or Perl. To apply, please email your CV to : skoln...@gatech.edu
[ccp4bb] Experimental Postdoctoral Position in High Throughput Small Molecule Ligand Screening
Experimental Postdoctoral Position in High Throughput Small Molecule Ligand Screening Outstanding postdoctoral applicants to work jointly with Drs. Julia Kubanek, Mark Hay and Jeffrey Skolnick are sought with the following qualifications: * Extensive experience in enzyme kinetics studies, enzyme purification or other aspects of protein biology and enzyme activity. Experience in handling multiple protein systems would be a plus. * A background in high throughput small molecule ligand screening is strongly preferred. * Experience with or a desire to learn computational biology and molecular modeling of protein-ligand interactions. * The ideal candidate is someone who gets satisfaction out of methods development and working through large data sets to see broad-scale patterns. To apply, please email your CV to : skoln...@gatech.edu
Re: [ccp4bb] To archive or not to archive, that's the question!
Dear Gerard, I think that a major achievement of this online debate will have been to actually get you to carry out a constructive analysis (an impressive one, I will be the first to say) of this question, instead of dismissing it right away. It is almost as great an achievement as getting the Pope to undergo psychoanalysis! (I am thinking here of the movie Habemus Papam.) It is very useful to have the facts and figures you mention for the costs of full PDB officialdom for the storage of raw data. I think one could describe the first stage towards that, in the form I have been mentioning as the IUCr DDDWG pilot project, as first trying to see how to stop those raw images from disappearing, pending the mobilisation of more resources towards eventually putting them up in five-star accommodation (if they are thought to be earning their keep). I am again hopeful that anticipated difficulties at the five-star stage (with today's cost estimates) will not stop us from trying to do what is possible today in this pilot project, and I also hope that enough synchrotrons and depositors will volunteer to take part in it. The extra logistical load on checking that submitted raw images sets do correspond to the deposited structure should be something that can be pushed down towards the synchrotron sources, as was mentioned for the proper book-keeping of metadata, as part of keeping tidy records linking user project databases to datasets, and towards enhancements in data processing and structure determination pipelines to keep track of all stages of the derivation of the deposited results from the raw data. Not trivial, but not insuperable, and fully in the direction of more automation and more associated record keeping. This is just to say that it needs not all land on the PDB's shoulders in an initially amorphous state. In any case, thank you for devoting so much time and attention to this nuts-and-bolts discussion when there are so many tempting forms of high octane entertainment around! With best wishes, Gerard (B.) -- On Fri, Oct 28, 2011 at 11:02:46PM +0200, Gerard DVD Kleywegt wrote: Hi all, It appears that during my time here at Cold Spring Harbor, I have missed a small debate on CCP4BB (in which my name has been used in vain to boot). I have not yet had time to read all the contributions, but would like to make a few points that hopefully contribute to the discussion and keep it with two feet on Earth (as opposed to La La Land where the people live who think that image archiving can be done on a shoestring budget... more about this in a bit). Note: all of this is on personal title, i.e. not official wwPDB gospel. Oh, and sorry for the new subject line, but this way I can track the replies more easily. It seems to me that there are a number of issues that need to be separated: (1) the case for/against storing raw data (2) implementation and resources (3) funding (4) location I will say a few things about each of these issues in turn: --- (1) Arguments in favour and against the concept of storing raw image data, as well as possible alternative solutions that could address some of the issues at lower cost or complexity. I realise that my views carry a weight=1.0 just like everybody else's, and many of the arguments and counter-arguments have already been made, so I will not add to these at this stage. --- (2) Implementation details and required resources. If the community should decide that archiving raw data would be scientifically useful, then it has to decide how best to do it. This will determine the level of resources required to do it. Questions include: - what should be archived? (See Jim H's list from (a) to (z) or so.) An initial plan would perhaps aim for the images associated with the data used in the final refinement of deposited structures. - how much data are we talking about per dataset/structure/year? - should it be stored close to the source (i.e., responsibility and costs for depositors or synchrotrons) or centrally (i.e., costs for some central resource)? If it is going to be stored centrally, the cost will be substantial. For example, at the EBI -the European Bioinformatics Institute- we have 15 PB of storage. We pay about 1500 GBP (~2300 USD) per TB of storage (not the kind you buy at Dixons or Radio Shack, obviously). For stored data, we have a data-duplication factor of ~8, i.e. every file is stored 8 times (at three data centres, plus back-ups, plus a data-duplication centre, plus unreleased versus public versions of the archive). (Note - this is only for the EBI/PDBe! RCSB and PDBj will have to acquire storage as well.) Moreover, disks have to be housed in a building (not free!), with cooling, security measures, security staff, maintenance staff, electricity (substantial cost!), rental of a 1-10 Gb/s connection, etc. All hardware has a
Re: [ccp4bb] To archive or not to archive, that's the question!
As the poster who mentioned the $1000 - $3000 per terabyte per year figure, I should point out that the figure originated not from La La land but from an NSF RDLM workshop in Princeton last summer. Certainly the actual costs may be higher or lower depending on economies/diseconomies of scale and required ancilary task to be performed. The base figure itself seems consistent with the GBP 1500 figure cited for EBI. That aside, the list presented seems very useful to the discussion. I would suggest adding to it the need to try to resolve the complex intellectual property issues involved. This might be a good time to try to get a consensus of the scientific community of what approach to IP law would best serve our interests going forward. The current situation seems a bit messy. Regards, Herbert = Herbert J. Bernstein, Professor of Computer Science Dowling College, Kramer Science Center, KSC 121 Idle Hour Blvd, Oakdale, NY, 11769 +1-631-244-3035 y...@dowling.edu = On Fri, 28 Oct 2011, Gerard DVD Kleywegt wrote: Gerard I said in INCREASING order of influence/power i.e. you are in first place. Ooo! *Now* it makes sense! :-) --Gerard The joke comes from I used to think if there was reincarnation, I wanted to come back as the President or the Pope or a .400 baseball hitter. But now I want to come back as the bond market. You can intimidate everyone. --James Carville, Clinton campaign strategist Thanks for the comprehensive reply Regards Colin -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Gerard DVD Kleywegt Sent: 28 October 2011 22:03 To: ccp4bb Subject: [ccp4bb] To archive or not to archive, that's the question! Hi all, It appears that during my time here at Cold Spring Harbor, I have missed a small debate on CCP4BB (in which my name has been used in vain to boot). I have not yet had time to read all the contributions, but would like to make a few points that hopefully contribute to the discussion and keep it with two feet on Earth (as opposed to La La Land where the people live who think that image archiving can be done on a shoestring budget... more about this in a bit). Note: all of this is on personal title, i.e. not official wwPDB gospel. Oh, and sorry for the new subject line, but this way I can track the replies more easily. It seems to me that there are a number of issues that need to be separated: (1) the case for/against storing raw data (2) implementation and resources (3) funding (4) location I will say a few things about each of these issues in turn: --- (1) Arguments in favour and against the concept of storing raw image data, as well as possible alternative solutions that could address some of the issues at lower cost or complexity. I realise that my views carry a weight=1.0 just like everybody else's, and many of the arguments and counter-arguments have already been made, so I will not add to these at this stage. --- (2) Implementation details and required resources. If the community should decide that archiving raw data would be scientifically useful, then it has to decide how best to do it. This will determine the level of resources required to do it. Questions include: - what should be archived? (See Jim H's list from (a) to (z) or so.) An initial plan would perhaps aim for the images associated with the data used in the final refinement of deposited structures. - how much data are we talking about per dataset/structure/year? - should it be stored close to the source (i.e., responsibility and costs for depositors or synchrotrons) or centrally (i.e., costs for some central resource)? If it is going to be stored centrally, the cost will be substantial. For example, at the EBI -the European Bioinformatics Institute- we have 15 PB of storage. We pay about 1500 GBP (~2300 USD) per TB of storage (not the kind you buy at Dixons or Radio Shack, obviously). For stored data, we have a data-duplication factor of ~8, i.e. every file is stored 8 times (at three data centres, plus back-ups, plus a data-duplication centre, plus unreleased versus public versions of the archive). (Note - this is only for the EBI/PDBe! RCSB and PDBj will have to acquire storage as well.) Moreover, disks have to be housed in a building (not free!), with cooling, security measures, security staff, maintenance staff, electricity (substantial cost!), rental of a 1-10 Gb/s connection, etc. All hardware has a life-cycle of three years (barring failures) and then needs to be replaced (at lower cost, but still not free). - if the data is going to be stored centrally, how will it get there? Using ftp will probably not be feasible. - if it is not stored centrally, how will long-term data availability be enforced? (Otherwise I could have my data
Re: [ccp4bb] Seeded rescreening with robot?
By popular request here's my favorite version of the in-screen seeding. We use a Mosquito but it doesn't have to be a specific robot as long as it can dispense relatively tiny volumes of seed stock. Caveats: (1) if I am desperate enough to do this, then the situation is pretty bad indeed and I don't mind wasting some protein (2) my success rate is not hugely favorable but this does work on occasion when other things have failed (1) identify a few likely conditions. Ideally they have microcrystals but desperation has made me try 'lovable precipitates' in the past, with a modest degree of success. (2) harvest entire drop using a few ul of mother liquor as diluent (3) break the existing crystals using your favorite method (sead beed, etc.) mine involves swirling a pipette tip in the mixture, running it along the walls, with rapid pipetting up and down. Dilute seed stock to useful volume (enough for screening). (4) I do not normally centrifuge the resulting seed stock, but some people do (5) dispense your screen as always with the usual protein/reservoir ratio. Let's say you like drops of the 0.2ul+0.2ul variety - add 25 nanoliters of the seed stock *last*. Optional mixing of the condition is a fun thing to try but it seems not to matter very much. Note that I typically use the same tips to dispense seed stock, fully aware that this causes cross-contamination of conditions. I don't mind :) (5a) variation - add seed stock to protein, then dispense ASAP. Surprisingly not a bad option, practically speaking. (5b) variation - crosslink seed stock very gently in solution (with trace of glutaraldehyde) before use. Buffers/additives with primary or secondary amine groups do interfere, of course. (5c) variation - mix seeds from SEVERAL initial hit conditions, then use as one seed stock. Be ready for fireworks as they may not be compatible! (6) endure nail-biting wait for results :) As noted earlier, it's not a sure-fire way to get new hit conditions but it does seem to work and it's a fun way to put to use a remainder of otherwise useless protein (when you've tried all other tricks you like to try). Comments and suggestions are always welcome! Artem On Fri, Oct 28, 2011 at 1:55 PM, Artem Evdokimov artem.evdoki...@gmail.comwrote: I would be glad to share ours. Artem On Oct 28, 2011 1:29 PM, Watson, Randy ewats...@uthsc.edu wrote: Hi all, I am trying to optimize crystals and have heard of a technique where one can prepare a seedstock from existing crystals and use it to broadly re-screen from scratch for hits in new conditions. I have access to a mosquito robot and was wondering if anyone has a protocol or recommendations on how to go about doing this using a robot for screening. Thank you! Randy Watson
