Re: [ccp4bb] 1.95A, different phases, maps look the same, R/Rfree 22/24, wrong space group?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Napo, to illustrate Felix Frolow's comment, take Solution-1 and the new data to refmac5 and run 'rigid body refinement'. I would not be surprised if you get a reasonable map with nearly the same R/Rfree as your MR solution, which means that this solution and the one from MR are equivalent (because of the freedom of choice for the origin some space groups allow you). Tim On 11/20/2011 06:42 AM, Napoleão Valadares wrote: Hello, I'm observing a very strange phenomena (at least to me, I'm a beginner). It is related to symmetry (I think). I got a data set at 1.95A (I/Sigma 3.5, R-Factor and R-meas 35% in the last shell) and a partially refined solution with R/Rfree 22/24, 166 aminoacids observed and around 30 solvent molecules. I'll call this Solution-1. The refinement was smooth, the densities were very clearly asking for the correct missing side chains and the map looks good. The space group I'm using is P212121, pointless and XDS agree with that (but me and pointless both have a long history of being wrong about space groups). Phenix.xtriage says there's no twinning. I took Solution-1 and used it as a template in a molecular replacement in the same space group (P212121) using the same mtz as the one used to refine the template. I got a different (not superposed in space) solution (called Solution-2, scores by Phaser RFZ=24.2 TFZ=33.0 PAK=0 LLG=1413 LLG=1899) that was readily refined in Phenix to R/Rfree 24/26 without any solvent molecule. - The solutions are not superposed in space, although they are near-identical and can be superposed yielding a C-alpha rmd =0.001. - Both structures present VERY similar density maps. The maps are not superposed in space, but when you run the chain in one map in Coot and do the same in the other it they the present exactly the same features. It is impossible to ignore their similarities. - Both structures and maps present the same origin and unit cell. - If I add to Solution-2 the equivalent solvent molecules of Solution-1 (I did this by superposing Solution-1 to Solution-2 then copy/pasting the solvent molecules), the R/Rfree become 22/24. This is a clear indication that the solutions are related. - I can't find any MR solutions using the same template and space groups P222, P2221 and P21212. How two different sets of phases can yield maps with the same features? What is happening, wrong space group? I have a feeling my lack of experience is the problem. Thank you. Regards, Napo - -- 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/ iD8DBQFOyQOaUxlJ7aRr7hoRAlw3AJ0WPwflZKAi2yX3ZDyx7XGO4DSrEACg0gPU nEaSCfvVXGz9+EdhevHwQGU= =llUi -END PGP SIGNATURE-
Re: [ccp4bb] 1.95A, different phases, maps look the same, R/Rfree 22/24, wrong space group? - No alternative origin
Thank you all for the replies. Felix Frolow, Dan Leahy, Hans Brandstetter, Boaz Shaanan and Tim Gruene you really helped a lot. I think I understand it now, I always thought the one ring to rule them all translated in the crystallography realms to one origin to rule them all. That probably means I have a long road in front of me. I'm still half confused, I definitely need to read more, as much as I read about symmetry and space groups I never seem to improve or get a better understanding, but I'll keep trying. About the same origin: The pdbs of both Solution-1 and Solution-2 present the same space group and cell, as observed opening the pdbs as text files or in pymol. When I open both maps on coot they are not superposed but present the same cell and origin. If I open both solutions on pymol they clash. If I generate the symmetry mates of both solutions none of them are superposed, instead they clash. But I think they are related as you all pointed, I'll check it out. Thank you all for your kind answers and your patience with a beginner. Regards from a sunny Brazil, Napo On 11/20/2011 2:58 AM, Felix Frolow wrote: Napoleao, It is so called alternative origins play a game with you. You do not change your structure by shifting 1/2 translation (or even combination of these translations) into directions of the main axes of your unit cell. Structure factors after this operation stay the same, however phases change systematically, producing however the same map features. Would I be a begin crystallographer now, I would read a bit more old fashioned books on crystallography such as probably Jensen and Stout… FF Dr Felix Frolow Professor of Structural Biology and Biotechnology Department of Molecular Microbiology and Biotechnology Tel Aviv University 69978, Israel Acta Crystallographica F, co-editor e-mail: mbfro...@post.tau.ac.il mailto:mbfro...@post.tau.ac.il Tel: ++972-3640-8723 Fax: ++972-3640-9407 Cellular: 0547 459 608 On Nov 20, 2011, at 07:42 , Napoleão Valadares wrote: Hello, I'm observing a very strange phenomena (at least to me, I'm a beginner). It is related to symmetry (I think). I got a data set at 1.95A (I/Sigma 3.5, R-Factor and R-meas 35% in the last shell) and a partially refined solution with R/Rfree 22/24, 166 aminoacids observed and around 30 solvent molecules. I'll call this Solution-1. The refinement was smooth, the densities were very clearly asking for the correct missing side chains and the map looks good. The space group I'm using is P212121, pointless and XDS agree with that (but me and pointless both have a long history of being wrong about space groups). Phenix.xtriage says there's no twinning. I took Solution-1 and used it as a template in a molecular replacement in the same space group (P212121) using the same mtz as the one used to refine the template. I got a different (not superposed in space) solution (called Solution-2, scores by Phaser RFZ=24.2 TFZ=33.0 PAK=0 LLG=1413 LLG=1899) that was readily refined in Phenix to R/Rfree 24/26 without any solvent molecule. - The solutions are not superposed in space, although they are near-identical and can be superposed yielding a C-alpha rmd =0.001. - Both structures present VERY similar density maps. The maps are not superposed in space, but when you run the chain in one map in Coot and do the same in the other it they the present exactly the same features. It is impossible to ignore their similarities. - Both structures and maps present the same origin and unit cell. - If I add to Solution-2 the equivalent solvent molecules of Solution-1 (I did this by superposing Solution-1 to Solution-2 then copy/pasting the solvent molecules), the R/Rfree become 22/24. This is a clear indication that the solutions are related. - I can't find any MR solutions using the same template and space groups P222, P2221 and P21212. How two different sets of phases can yield maps with the same features? What is happening, wrong space group? I have a feeling my lack of experience is the problem. Thank you. Regards, Napo
Re: [ccp4bb] 1.95A, different phases, maps look the same, R/Rfree 22/24, wrong space group? - No alternative origin
A source of confusion is that we are using two different definitions of origin. In the a graphics program sense (coot, pymol), the origin is always at xyz coordinate (0, 0, 0). I think that's what Napo means by present the same cell and origin. However, imagine a crystal upon which we put a unit cell box with one corner labelled (0, 0, 0) and the opposite corner labelled (1, 1, 1) in fractional coordinates. We can use the unit cell box as a ruler to read out positions in the crystal. Within the crystal are our molecules in a repeating lattice. Now suppose we move our unit cell box around the crystal while keeping the molecules fixed in the lattice. Do you see how the relative coordinates of the molecules with respect to that unit cell box will change even though the crystal does not change nor do the molecules in the crystal? I know this doesn't explain everything about origins as not every point in most crystal lattices can be an origin, but I will save that concept for another day. I just wanted to note the apparently different definitions of origin in this thread. Jim From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Napoleão Valadares [n...@if.sc.usp.br] Sent: Sunday, November 20, 2011 9:57 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] 1.95A, different phases, maps look the same, R/Rfree 22/24, wrong space group? - No alternative origin About the same origin: The pdbs of both Solution-1 and Solution-2 present the same space group and cell, as observed opening the pdbs as text files or in pymol. When I open both maps on coot they are not superposed but present the same cell and origin.
Re: [ccp4bb] adxv
Dear Tim, Thanks. Your suggestion of adding to PATH works and its not completely functional may be due to the Ximg/ssh or some thing to do with display.All three windows opened but couldn't open any image as it didn't display in the list of autoload window. Pattern shows *.0. $adxv pin8_1_180.img (standard_in) 1: parse error(standard_in) 1: parse error(standard_in) 1: parse errorbeam_center x = pixels , mmbeam_center y = pixels , mmdistance = mmoverload = countspixelsize = 0.172 mmwavelength = Angstroem Adxv Version 1.9.4-betaCopyright (C) 1994-2007 by Andrew Arvai, Area Detector Systems CorporationUsing 24-bit TrueColor visualWarning: translation table syntax error: Unknown keysym name: osfActivateWarning: ... found while parsing ':KeyosfActivate:ManagerParentActivate()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfBeginLineWarning: ... found while parsing ':KeyosfBeginLine: ManagerGadgetTraverseHome()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfHelpWarning: ... found while parsing ':KeyosfHelp:ManagerGadgetHelp()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfActivateWarning: ... found while parsing ':KeyosfActivate:ManagerParentActivate()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfActivateWarning: ... found while parsing ':KeyosfActivate:PrimitiveParentActivate()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfHelpWarning: ... found while parsing ':KeyosfHelp:Help()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfActivateWarning: ... found while parsing ':KeyosfActivate: PrimitiveParentActivate()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfCancelWarning: ... found while parsing ':KeyosfCancel: MenuEscape()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfSelectWarning: ... found while parsing ':KeyosfSelect: ArmAndActivate()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfActivateWarning: ... found while parsing ':KeyosfActivate: PrimitiveParentActivate()'Warning: String to TranslationTable conversion encountered errorsWarning: Locale not supported for XmbTextListToTextPropertyWarning: Cannot convert XmString to compound textWarning: translation table syntax error: Unknown keysym name: osfPrimaryPasteWarning: ... found while parsing ':m KeyosfPrimaryPaste:cut-primary()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfActivateWarning: ... found while parsing ':KeyosfActivate: PrimitiveParentActivate()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfActivateWarning: ... found while parsing ':KeyosfActivate: PrimitiveParentActivate()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfSelectWarning: ... found while parsing ':KeyosfSelect: ArmAndActivate()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfPrimaryPasteWarning: ... found while parsing ':m KeyosfPrimaryPaste:cut-primary()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfSelectWarning: ... found while parsing ':KeyosfSelect: ManagerGadgetSelect()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfSelectWarning: ... found while parsing ':KeyosfSelect: MenuBarGadgetSelect()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfActivateWarning: ... found while parsing ':KeyosfActivate: ManagerParentActivate()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name: osfHelpWarning: ... found while parsing ':KeyosfHelp: MenuHelp()'Warning: String to TranslationTable conversion encountered errorsWarning: translation table syntax error: Unknown keysym name:
[ccp4bb] dark progression of radiation damage
Mark's comment below reminded me of a quandary that is starting to develop in the rad dam field. The idea of the free radical cascade continuing to damage protein crystals even after the beam has been turned off seems to have originated on page 253 of Blundell and Johnson (1976), and I think most of us have had the unpleasant experience of loosing diffraction after a delay in data collection. However, can one be sure that the incident beam alignment was the same if the delay in data collection was due to a storage ring dump, or a filament change? Can one be sure that a crystal stored under cryo never ever got warmed up (like during mounts and dismounts, or perhaps a colleague making an undocumented late-night rummage through the storage dewar)? Can one be sure that a crystal at room temperature wasn't just drying up? Can one be sure that the damage didn't all occur during the first shot (and the image we saw is just the sum over the decay)? I ask because many systematic studies have now been made to try and quantify the dark progression phenomenon, only to find it doesn't seem to really exist, either under cryo (Garman McSweeney, 2007; Sliz et al., 2003; Leiros et al., 2006; Owen et al., 2006), or at room temperature (Southworth-Davies et al. Structure 2007; Warkentin et al. Acta D 2011), except at temperatures that are almost never used for data collection (Warkentin et al. Acta D 2011). Now, there are observations of radiochemical reactions progressing for several minutes in the dark (Weik et al., 2002, Southworth-Davies Gaman Acta D 2007 McGeehen et al., 2009 ), but I don't personally know of anyone (other than Warkentin et al. 2011) who has demonstrated that _diffraction_ continues to decay in the dark. So, my question is: does anyone out there have an example system where one can reproducibly demonstrate dark progression of diffraction spot fading? That is, you can mount the crystal, store it in its mount for at least a few days (to prove that its not just drying up), take at least two low-dose shots to get an idea of the expected rate of decay, then wait for a while and start shooting again. Do you see significantly worse diffraction? -James Holton MAD Scientist On 11/18/2011 1:50 AM, Mark J van Raaij wrote: I.e. if you collect one image and then wait until the orientation and strategy is calculated, the crystal is probably already dead.
Re: [ccp4bb] adxv
Dear Rajesh, Are you using the Openmotif library? If so, do you have an XKeysymDB file installed? In as shell, issue: $ locate XKeysymDB You may need to symlink it to /usr/X11R6/lib/X11/XKeysymDB if it is elsewhere [1]. I suspect you're not the only one to have seen this [2]. I hope this helps. Mark [1] ftp://ftp.parallelgeo.com/SPW_Products/Linux/Current_Release/ReadMe_for_recent_Linux_distributions.txt [2] http://sbgrid.org/news/newsletters/2009/06 (search for the string adxv) On 20 November 2011 19:45, Rajesh kumar ccp4...@hotmail.com wrote: Dear Tim, Thanks. Your suggestion of adding to PATH works and its not completely functional may be due to the Ximg/ssh or some thing to do with display. All three windows opened but couldn't open any image as it didn't display in the list of autoload window. Pattern shows *.0. $adxv pin8_1_180.img (standard_in) 1: parse error (standard_in) 1: parse error (standard_in) 1: parse error beam_center x = pixels , mm beam_center y = pixels , mm distance = mm overload = counts pixelsize = 0.172 mm wavelength = Angstroem Adxv Version 1.9.4-beta Copyright (C) 1994-2007 by Andrew Arvai, Area Detector Systems Corporation Using 24-bit TrueColor visual Warning: translation table syntax error: Unknown keysym name: osfActivate Warning: ... found while parsing ':KeyosfActivate: ManagerParentActivate()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfBeginLine Warning: ... found while parsing ':KeyosfBeginLine: ManagerGadgetTraverseHome()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfHelp Warning: ... found while parsing ':KeyosfHelp: ManagerGadgetHelp()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfActivate Warning: ... found while parsing ':KeyosfActivate: ManagerParentActivate()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfActivate Warning: ... found while parsing ':KeyosfActivate: PrimitiveParentActivate()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfHelp Warning: ... found while parsing ':KeyosfHelp: Help()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfActivate Warning: ... found while parsing ':KeyosfActivate: PrimitiveParentActivate()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfCancel Warning: ... found while parsing ':KeyosfCancel: MenuEscape()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfSelect Warning: ... found while parsing ':KeyosfSelect: ArmAndActivate()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfActivate Warning: ... found while parsing ':KeyosfActivate: PrimitiveParentActivate()' Warning: String to TranslationTable conversion encountered errors Warning: Locale not supported for XmbTextListToTextProperty Warning: Cannot convert XmString to compound text Warning: translation table syntax error: Unknown keysym name: osfPrimaryPaste Warning: ... found while parsing ':m KeyosfPrimaryPaste:cut-primary()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfActivate Warning: ... found while parsing ':KeyosfActivate: PrimitiveParentActivate()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfActivate Warning: ... found while parsing ':KeyosfActivate: PrimitiveParentActivate()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfSelect Warning: ... found while parsing ':KeyosfSelect: ArmAndActivate()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfPrimaryPaste Warning: ... found while parsing ':m KeyosfPrimaryPaste:cut-primary()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfSelect Warning: ... found while parsing ':KeyosfSelect: ManagerGadgetSelect()' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym
Re: [ccp4bb] dark progression of radiation damage
Hi James, I don't think the comment you referenced meant to imply dark progression of radiation damage. If I remember from the recent thread, it was to say that if you can only collect few (3?) shots from one crystal before it's too dead and you use 1st of these shots to devise the strategy, then you are wasting your crystals and will never get you data. Of course, you don't have to use so much flux for the image which is meant only for defining the orientation but it was omitted from that comment. Now back to the rest of your message. I can add another warning observation: If a cryo-cooled crystal was exposed long enough (i.e. for data collection) then stored (by a robot) and then mounted again, some times one sees that it had exploded. Such an explosion, presumably a hydrogen gas escape, can be seen almost always if a crystal is wormed up after long data collection. The fact that robot-stored crystals sometimes display same behavior, indicates that a crystal in the arms of the robot can worm up somewhat. Therefore, comparing diffraction before and after storage is not always valid. Also beware of comparing diffraction quality from different parts of the crystal as large crystals are almost never homogeneous. Cheers, Nukri -Original Message- From: CCP4 bulletin board on behalf of James Holton Sent: Sun 11/20/2011 2:31 PM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] dark progression of radiation damage Mark's comment below reminded me of a quandary that is starting to develop in the rad dam field. The idea of the free radical cascade continuing to damage protein crystals even after the beam has been turned off seems to have originated on page 253 of Blundell and Johnson (1976), and I think most of us have had the unpleasant experience of loosing diffraction after a delay in data collection. However, can one be sure that the incident beam alignment was the same if the delay in data collection was due to a storage ring dump, or a filament change? Can one be sure that a crystal stored under cryo never ever got warmed up (like during mounts and dismounts, or perhaps a colleague making an undocumented late-night rummage through the storage dewar)? Can one be sure that a crystal at room temperature wasn't just drying up? Can one be sure that the damage didn't all occur during the first shot (and the image we saw is just the sum over the decay)? I ask because many systematic studies have now been made to try and quantify the dark progression phenomenon, only to find it doesn't seem to really exist, either under cryo (Garman McSweeney, 2007; Sliz et al., 2003; Leiros et al., 2006; Owen et al., 2006), or at room temperature (Southworth-Davies et al. Structure 2007; Warkentin et al. Acta D 2011), except at temperatures that are almost never used for data collection (Warkentin et al. Acta D 2011). Now, there are observations of radiochemical reactions progressing for several minutes in the dark (Weik et al., 2002, Southworth-Davies Gaman Acta D 2007 McGeehen et al., 2009 ), but I don't personally know of anyone (other than Warkentin et al. 2011) who has demonstrated that _diffraction_ continues to decay in the dark. So, my question is: does anyone out there have an example system where one can reproducibly demonstrate dark progression of diffraction spot fading? That is, you can mount the crystal, store it in its mount for at least a few days (to prove that its not just drying up), take at least two low-dose shots to get an idea of the expected rate of decay, then wait for a while and start shooting again. Do you see significantly worse diffraction? -James Holton MAD Scientist On 11/18/2011 1:50 AM, Mark J van Raaij wrote: I.e. if you collect one image and then wait until the orientation and strategy is calculated, the crystal is probably already dead.
[ccp4bb] improve protein-DNA complex crystal
Hi all, I got a protein-DNA complex crystal,by running SDS-PAGE and nativePAGE,i prove that the crystal contain both protein and DNA.BUT it does not diffract. does anyone have suggestion to improve the diffraction ability ? Best wishes, deng
