Re: [ccp4bb] PyMOL v. Coot map 'level'
Hi Emilia and Steven, (re-posting after accidentally replying to the coot mailing list) After off-list discussion with Steven, I updated: http://pymolwiki.org/index.php/Normalize_ccp4_maps If the goal is to match the display in Coot, this is what I would do: # load map into PyMOL but don't normalize set normalize_ccp4_maps, off load yourmap.ccp4 load yourpdb.pdb # create a mesh which matches Coot's level = 0.3462e/A^3 ( 1.00rmsd) isomesh mesh, yourmap, 0.3462, (yourpdb) PyMOL extends the map based on the symmetry information from the selection in the 4th argument. No need to create an extended map with MAPMASK as long as yourpdb.pdb has symmetry information. Same is true if the map came from an MTZ file. I also updated http://pymolwiki.org/index.php/Display_CCP4_Maps and changed cover 'all atoms in PDB file' to cover 'asymmetric unit'. That way PyMOL's normalization should be identical to Coot's. Regarding the question What does PyMOL's 1.0 mean in electrons/A^3?: After normalization (with normalize_ccp4_maps=on) PyMOL doesn't know about the original values anymore. I assume Coot takes the original values from the file as e/A^3, so if you don't normalize in PyMOL, you'll get e/A^3. Hope that helps. Cheers, Thomas On 05 Jun 2015, at 01:36, Emilia C. Arturo (Emily) ec...@drexel.edu wrote: Thomas, I tried to figure out the PyMOL vs. Coot normalization discrepancy a while ago. As far as I remember, PyMOL normalizes on the raw data array, while Coot normalizes across the unit cell. So if the data doesn't exactly cover the cell, the results might be different. I posted the same question to the Coot mailing list (the thread can be found here: https://goo.gl/YjVtTu) , and got the following reply from Paul Emsley; I highlight the questions that I think you could best answer, with '***': [ ...] I suspect that the issue is related to different answers to the rmsd of what? In Coot, we use all the grid points in the asymmetric unit - other programs make a selection of grid points around the protein (and therefore have less solvent). More solvent means lower rmsd. If one then contours in n-rmsd levels, then absolute level used in Coot will be lower - and thus seem to be noisier (perhaps). I suppose that if you want comparable levels from the same map/mtz file then you should use absolute levels, not rmsd. ***What does PyMOL's 1.0 mean in electrons/A^3?*** Regards, Paul. Regards, Emily. On 01 Jun 2015, at 11:37, Emilia C. Arturo (Emily) ec...@drexel.edu wrote: One cannot understand what is going on without knowing how this map was calculated. Maps calculated by the Electron Density Server have density in units of electron/A^3 if I recall, or at least its best effort to do so. This is what I was looking for! (i.e. what the units are) Thanks. :-) Yes, I'd downloaded the 2mFo-DFc map from the EDS, and got the same Coot v. PyMOL discrepancy whether or not I turned off the PyMOL map normalization feature. If you load the same map into Pymol and ask it to normalize the density values you should set your contour level to Coot's rmsd level. If you don't normalize you should use Coot's e/A^3 level. It is quite possible that they could differ by a factor of two. This was exactly the case. The map e/A^3 level (not the rmsd level) in Coot matched very well, visually, the map 'level' in PyMOL; they were roughly off by a factor of 2. I did end up also generating a 2mFo-DFc map using phenix, which fetched the structure factors of the model in which I was interested. The result was the same (i.e. PyMOL 'level' = Coot e/A^3 level ~ = 1/2 Coot's rmsd level) whether I used the CCP4 map downloaded from the EDS, or generated from the structure factors with phenix. Thanks All. Emily. Dale Tronrud On 5/29/2015 1:15 PM, Emilia C. Arturo (Emily) wrote: Hello. I am struggling with an old question--old because I've found several discussions and wiki bits on this topic, e.g. on the PyMOL mailing list (http://sourceforge.net/p/pymol/mailman/message/26496806/ and http://www.pymolwiki.org/index.php/Display_CCP4_Maps), but the suggestions about how to fix the problem are not working for me, and I cannot figure out why. Perhaps someone here can help: I'd like to display (for beauty's sake) a selection of a model with the map about this selection. I've fetched the model from the PDB, downloaded its 2mFo-DFc CCP4 map, loaded both the map and model into both PyMOL (student version) and Coot (0.8.2-pre EL (revision 5592)), and decided that I would use PyMOL to make the figure. I notice, though, that the map 'level' in PyMOL is not equivalent to the rmsd level in Coot, even when I set normalization off in PyMOL. I expected that a 1.0 rmsd level in Coot would look identical to a 1.0 level in PyMOL, but it does not; rather, a 1.0 rmsd level in
Re: [ccp4bb] PyMOL v. Coot map 'level'
Thomas, I tried to figure out the PyMOL vs. Coot normalization discrepancy a while ago. As far as I remember, PyMOL normalizes on the raw data array, while Coot normalizes across the unit cell. So if the data doesn't exactly cover the cell, the results might be different. I posted the same question to the Coot mailing list (the thread can be found here: https://goo.gl/YjVtTu) , and got the following reply from Paul Emsley; I highlight the questions that I think you could best answer, with '***': [ ...] I suspect that the issue is related to different answers to the rmsd of what? In Coot, we use all the grid points in the asymmetric unit - other programs make a selection of grid points around the protein (and therefore have less solvent). More solvent means lower rmsd. If one then contours in n-rmsd levels, then absolute level used in Coot will be lower - and thus seem to be noisier (perhaps). I suppose that if you want comparable levels from the same map/mtz file then you should use absolute levels, not rmsd. ***What does PyMOL's 1.0 mean in electrons/A^3?*** Regards, Paul. Regards, Emily. On 01 Jun 2015, at 11:37, Emilia C. Arturo (Emily) ec...@drexel.edu wrote: One cannot understand what is going on without knowing how this map was calculated. Maps calculated by the Electron Density Server have density in units of electron/A^3 if I recall, or at least its best effort to do so. This is what I was looking for! (i.e. what the units are) Thanks. :-) Yes, I'd downloaded the 2mFo-DFc map from the EDS, and got the same Coot v. PyMOL discrepancy whether or not I turned off the PyMOL map normalization feature. If you load the same map into Pymol and ask it to normalize the density values you should set your contour level to Coot's rmsd level. If you don't normalize you should use Coot's e/A^3 level. It is quite possible that they could differ by a factor of two. This was exactly the case. The map e/A^3 level (not the rmsd level) in Coot matched very well, visually, the map 'level' in PyMOL; they were roughly off by a factor of 2. I did end up also generating a 2mFo-DFc map using phenix, which fetched the structure factors of the model in which I was interested. The result was the same (i.e. PyMOL 'level' = Coot e/A^3 level ~ = 1/2 Coot's rmsd level) whether I used the CCP4 map downloaded from the EDS, or generated from the structure factors with phenix. Thanks All. Emily. Dale Tronrud On 5/29/2015 1:15 PM, Emilia C. Arturo (Emily) wrote: Hello. I am struggling with an old question--old because I've found several discussions and wiki bits on this topic, e.g. on the PyMOL mailing list (http://sourceforge.net/p/pymol/mailman/message/26496806/ and http://www.pymolwiki.org/index.php/Display_CCP4_Maps), but the suggestions about how to fix the problem are not working for me, and I cannot figure out why. Perhaps someone here can help: I'd like to display (for beauty's sake) a selection of a model with the map about this selection. I've fetched the model from the PDB, downloaded its 2mFo-DFc CCP4 map, loaded both the map and model into both PyMOL (student version) and Coot (0.8.2-pre EL (revision 5592)), and decided that I would use PyMOL to make the figure. I notice, though, that the map 'level' in PyMOL is not equivalent to the rmsd level in Coot, even when I set normalization off in PyMOL. I expected that a 1.0 rmsd level in Coot would look identical to a 1.0 level in PyMOL, but it does not; rather, a 1.0 rmsd level in Coot looks more like a 0.5 level in PyMOL. Does anyone have insight they could share about the difference between how Coot and PyMOL loads maps? Maybe the PyMOL 'level' is not a rmsd? is there some other normalization factor in PyMOL that I should set? Or, perhaps there is a mailing list post out there that I've missed, to which you could point me. :-) Alternatively, does anyone have instructions on how to use Coot to do what I'm trying to do in PyMOL? In PyMOL I displayed the mesh of the 2Fo-Fc map, contoured at 1.0 about a 3-residue-long 'selection' like so: isomesh map, My_2Fo-Fc.map, 1.0, selection, carve=2.0, and after hiding everything but the selection, I have a nice picture ... but with a map at a level I cannot interpret in PyMOL relative to Coot :-/ Regards, Emily. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iEYEARECAAYFAlVo1L4ACgkQU5C0gGfAG10YkwCfROYPVXBK/pDS4z/zi5MNY1D+ nHIAnjOFiAkb6JbuIGWRWkBFDG5Xgc2K =hrPT -END PGP SIGNATURE- -- Thomas Holder PyMOL Principal Developer Schrödinger, Inc.
Re: [ccp4bb] PyMOL v. Coot map 'level'
Hi James, carving and normalization in PyMOL are really independent things. Normalization happens during map loading (if normalize_ccp4_maps is on). Carving happens during mesh generation (it's an argument of the isomesh command) and is really just a way to limit mesh display to an area of interest. You can do a simple test and create a mesh of an entire map, and a carved mesh around a ligand or residue, and both should match perfectly. Example: fetch 1rx1, async=0 fetch 1rx1, async=0, type=2fofc isomesh meshfull, 1rx1_2fofc, 1.0 isomesh meshcarve, 1rx1_2fofc, 1.0, organic, 2.0, 1, 2.0 set grid_mode disable 1rx1 set_view (\ 0.929457247,0.368711948,0.012666196,\ -0.360624999,0.900760233,0.242035180,\ 0.077831753, -0.229529440,0.970184207,\ 0.16911,0.72468, -31.454853058,\ 26.290172577, 59.373352051, 15.045225143,\ 29.803743362, 33.103614807, -20.0 ) Expanding the map also happens during mesh generation and does nothing to the data, except replicating it. Using your tool of choice to normalize a map before loading into PyMOL is for sure a good practice and solves the issue that PyMOL doesn't normalize across the asymmetric unit, but the raw data (if raw data != integral number of asymmetric units). Cheers, Thomas On 03 Jun 2015, at 14:14, James Holton jmhol...@lbl.gov wrote: I have never trusted Pymol's normalization of maps, because it has never been clear to me if it does the normalization before or after the carve. If it is after, then you have a serious interpretation problem: the 1 sigma level will be MUCH lower than if the rest of the map were not set to zero. In this situation if you set the carve right the map will look a LOT more like the coordinates than it should. In fact, if you normalize a map using anything but an integral number of asymmetric units your 1 sigma level will not be the same as if it were done properly. With pymol you usually have to extend the map to cover the protein of interest, and this extended map is seldom an integral number of asymmetric units. So, I have always taken to normalizing the map myself (using mapmask) with a single ASU or single cell as the map extent, and THEN extending the map to cover the PDB (using a completely different run of mapmask) and only then load it into pymol. I always turn off map normalization in pymol. I have also never used carve, as my thesis adviser strongly disapproved of the practice. Mostly because of the potential for bias mentioned above. Do you really have to carve for your density to be clear? -James Holton MAD Scientist On 5/29/2015 1:15 PM, Emilia C. Arturo (Emily) wrote: Hello. I am struggling with an old question--old because I've found several discussions and wiki bits on this topic, e.g. on the PyMOL mailing list (http://sourceforge.net/p/pymol/mailman/message/26496806/ and http://www.pymolwiki.org/index.php/Display_CCP4_Maps), but the suggestions about how to fix the problem are not working for me, and I cannot figure out why. Perhaps someone here can help: I'd like to display (for beauty's sake) a selection of a model with the map about this selection. I've fetched the model from the PDB, downloaded its 2mFo-DFc CCP4 map, loaded both the map and model into both PyMOL (student version) and Coot (0.8.2-pre EL (revision 5592)), and decided that I would use PyMOL to make the figure. I notice, though, that the map 'level' in PyMOL is not equivalent to the rmsd level in Coot, even when I set normalization off in PyMOL. I expected that a 1.0 rmsd level in Coot would look identical to a 1.0 level in PyMOL, but it does not; rather, a 1.0 rmsd level in Coot looks more like a 0.5 level in PyMOL. Does anyone have insight they could share about the difference between how Coot and PyMOL loads maps? Maybe the PyMOL 'level' is not a rmsd? is there some other normalization factor in PyMOL that I should set? Or, perhaps there is a mailing list post out there that I've missed, to which you could point me. :-) Alternatively, does anyone have instructions on how to use Coot to do what I'm trying to do in PyMOL? In PyMOL I displayed the mesh of the 2Fo-Fc map, contoured at 1.0 about a 3-residue-long 'selection' like so: isomesh map, My_2Fo-Fc.map, 1.0, selection, carve=2.0, and after hiding everything but the selection, I have a nice picture ... but with a map at a level I cannot interpret in PyMOL relative to Coot :-/ Regards, Emily. -- Thomas Holder PyMOL Principal Developer Schrödinger, Inc.
Re: [ccp4bb] PyMOL v. Coot map 'level'
Tim is making a very good point (as usual!) The RMSD of the whole asymmetric unit is only a rough guide to a useful map contour - that depends on the relative B values of the feature you want to display. It is pretty obvious that features with lower than average B factors show up at higher Sig level than perfectly well defined features which have higher B values. One of the best COOT features is being able so easily to adjust the contour to something sensible .. Eleanor On 3 June 2015 at 19:14, James Holton jmhol...@lbl.gov wrote: I have never trusted Pymol's normalization of maps, because it has never been clear to me if it does the normalization before or after the carve. If it is after, then you have a serious interpretation problem: the 1 sigma level will be MUCH lower than if the rest of the map were not set to zero. In this situation if you set the carve right the map will look a LOT more like the coordinates than it should. In fact, if you normalize a map using anything but an integral number of asymmetric units your 1 sigma level will not be the same as if it were done properly. With pymol you usually have to extend the map to cover the protein of interest, and this extended map is seldom an integral number of asymmetric units. So, I have always taken to normalizing the map myself (using mapmask) with a single ASU or single cell as the map extent, and THEN extending the map to cover the PDB (using a completely different run of mapmask) and only then load it into pymol. I always turn off map normalization in pymol. I have also never used carve, as my thesis adviser strongly disapproved of the practice. Mostly because of the potential for bias mentioned above. Do you really have to carve for your density to be clear? -James Holton MAD Scientist On 5/29/2015 1:15 PM, Emilia C. Arturo (Emily) wrote: Hello. I am struggling with an old question--old because I've found several discussions and wiki bits on this topic, e.g. on the PyMOL mailing list ( http://sourceforge.net/p/pymol/mailman/message/26496806/ and http://www.pymolwiki.org/index.php/Display_CCP4_Maps), but the suggestions about how to fix the problem are not working for me, and I cannot figure out why. Perhaps someone here can help: I'd like to display (for beauty's sake) a selection of a model with the map about this selection. I've fetched the model from the PDB, downloaded its 2mFo-DFc CCP4 map, loaded both the map and model into both PyMOL (student version) and Coot (0.8.2-pre EL (revision 5592)), and decided that I would use PyMOL to make the figure. I notice, though, that the map 'level' in PyMOL is not equivalent to the rmsd level in Coot, even when I set normalization off in PyMOL. I expected that a 1.0 rmsd level in Coot would look identical to a 1.0 level in PyMOL, but it does not; rather, a 1.0 rmsd level in Coot looks more like a 0.5 level in PyMOL. Does anyone have insight they could share about the difference between how Coot and PyMOL loads maps? Maybe the PyMOL 'level' is not a rmsd? is there some other normalization factor in PyMOL that I should set? Or, perhaps there is a mailing list post out there that I've missed, to which you could point me. :-) Alternatively, does anyone have instructions on how to use Coot to do what I'm trying to do in PyMOL? In PyMOL I displayed the mesh of the 2Fo-Fc map, contoured at 1.0 about a 3-residue-long 'selection' like so: isomesh map, My_2Fo-Fc.map, 1.0, selection, carve=2.0, and after hiding everything but the selection, I have a nice picture ... but with a map at a level I cannot interpret in PyMOL relative to Coot :-/ Regards, Emily.
Re: [ccp4bb] PyMOL v. Coot map 'level'
I have never trusted Pymol's normalization of maps, because it has never been clear to me if it does the normalization before or after the carve. If it is after, then you have a serious interpretation problem: the 1 sigma level will be MUCH lower than if the rest of the map were not set to zero. In this situation if you set the carve right the map will look a LOT more like the coordinates than it should. In fact, if you normalize a map using anything but an integral number of asymmetric units your 1 sigma level will not be the same as if it were done properly. With pymol you usually have to extend the map to cover the protein of interest, and this extended map is seldom an integral number of asymmetric units. So, I have always taken to normalizing the map myself (using mapmask) with a single ASU or single cell as the map extent, and THEN extending the map to cover the PDB (using a completely different run of mapmask) and only then load it into pymol. I always turn off map normalization in pymol. I have also never used carve, as my thesis adviser strongly disapproved of the practice. Mostly because of the potential for bias mentioned above. Do you really have to carve for your density to be clear? -James Holton MAD Scientist On 5/29/2015 1:15 PM, Emilia C. Arturo (Emily) wrote: Hello. I am struggling with an old question--old because I've found several discussions and wiki bits on this topic, e.g. on the PyMOL mailing list (http://sourceforge.net/p/pymol/mailman/message/26496806/ and http://www.pymolwiki.org/index.php/Display_CCP4_Maps), but the suggestions about how to fix the problem are not working for me, and I cannot figure out why. Perhaps someone here can help: I'd like to display (for beauty's sake) a selection of a model with the map about this selection. I've fetched the model from the PDB, downloaded its 2mFo-DFc CCP4 map, loaded both the map and model into both PyMOL (student version) and Coot (0.8.2-pre EL (revision 5592)), and decided that I would use PyMOL to make the figure. I notice, though, that the map 'level' in PyMOL is not equivalent to the rmsd level in Coot, even when I set normalization off in PyMOL. I expected that a 1.0 rmsd level in Coot would look identical to a 1.0 level in PyMOL, but it does not; rather, a 1.0 rmsd level in Coot looks more like a 0.5 level in PyMOL. Does anyone have insight they could share about the difference between how Coot and PyMOL loads maps? Maybe the PyMOL 'level' is not a rmsd? is there some other normalization factor in PyMOL that I should set? Or, perhaps there is a mailing list post out there that I've missed, to which you could point me. :-) Alternatively, does anyone have instructions on how to use Coot to do what I'm trying to do in PyMOL? In PyMOL I displayed the mesh of the 2Fo-Fc map, contoured at 1.0 about a 3-residue-long 'selection' like so: isomesh map, My_2Fo-Fc.map, 1.0, selection, carve=2.0, and after hiding everything but the selection, I have a nice picture ... but with a map at a level I cannot interpret in PyMOL relative to Coot :-/ Regards, Emily.
Re: [ccp4bb] PyMOL v. Coot map 'level'
One cannot understand what is going on without knowing how this map was calculated. Maps calculated by the Electron Density Server have density in units of electron/A^3 if I recall, or at least its best effort to do so. This is what I was looking for! (i.e. what the units are) Thanks. :-) Yes, I'd downloaded the 2mFo-DFc map from the EDS, and got the same Coot v. PyMOL discrepancy whether or not I turned off the PyMOL map normalization feature. If you load the same map into Pymol and ask it to normalize the density values you should set your contour level to Coot's rmsd level. If you don't normalize you should use Coot's e/A^3 level. It is quite possible that they could differ by a factor of two. This was exactly the case. The map e/A^3 level (not the rmsd level) in Coot matched very well, visually, the map 'level' in PyMOL; they were roughly off by a factor of 2. I did end up also generating a 2mFo-DFc map using phenix, which fetched the structure factors of the model in which I was interested. The result was the same (i.e. PyMOL 'level' = Coot e/A^3 level ~ = 1/2 Coot's rmsd level) whether I used the CCP4 map downloaded from the EDS, or generated from the structure factors with phenix. Thanks All. Emily. Dale Tronrud On 5/29/2015 1:15 PM, Emilia C. Arturo (Emily) wrote: Hello. I am struggling with an old question--old because I've found several discussions and wiki bits on this topic, e.g. on the PyMOL mailing list (http://sourceforge.net/p/pymol/mailman/message/26496806/ and http://www.pymolwiki.org/index.php/Display_CCP4_Maps), but the suggestions about how to fix the problem are not working for me, and I cannot figure out why. Perhaps someone here can help: I'd like to display (for beauty's sake) a selection of a model with the map about this selection. I've fetched the model from the PDB, downloaded its 2mFo-DFc CCP4 map, loaded both the map and model into both PyMOL (student version) and Coot (0.8.2-pre EL (revision 5592)), and decided that I would use PyMOL to make the figure. I notice, though, that the map 'level' in PyMOL is not equivalent to the rmsd level in Coot, even when I set normalization off in PyMOL. I expected that a 1.0 rmsd level in Coot would look identical to a 1.0 level in PyMOL, but it does not; rather, a 1.0 rmsd level in Coot looks more like a 0.5 level in PyMOL. Does anyone have insight they could share about the difference between how Coot and PyMOL loads maps? Maybe the PyMOL 'level' is not a rmsd? is there some other normalization factor in PyMOL that I should set? Or, perhaps there is a mailing list post out there that I've missed, to which you could point me. :-) Alternatively, does anyone have instructions on how to use Coot to do what I'm trying to do in PyMOL? In PyMOL I displayed the mesh of the 2Fo-Fc map, contoured at 1.0 about a 3-residue-long 'selection' like so: isomesh map, My_2Fo-Fc.map, 1.0, selection, carve=2.0, and after hiding everything but the selection, I have a nice picture ... but with a map at a level I cannot interpret in PyMOL relative to Coot :-/ Regards, Emily. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iEYEARECAAYFAlVo1L4ACgkQU5C0gGfAG10YkwCfROYPVXBK/pDS4z/zi5MNY1D+ nHIAnjOFiAkb6JbuIGWRWkBFDG5Xgc2K =hrPT -END PGP SIGNATURE-
Re: [ccp4bb] PyMOL v. Coot map 'level'
Hi Emilia et al., I tried to figure out the PyMOL vs. Coot normalization discrepancy a while ago. As far as I remember, PyMOL normalizes on the raw data array, while Coot normalizes across the unit cell. So if the data doesn't exactly cover the cell, the results might be different. Cheers, Thomas On 01 Jun 2015, at 11:37, Emilia C. Arturo (Emily) ec...@drexel.edu wrote: One cannot understand what is going on without knowing how this map was calculated. Maps calculated by the Electron Density Server have density in units of electron/A^3 if I recall, or at least its best effort to do so. This is what I was looking for! (i.e. what the units are) Thanks. :-) Yes, I'd downloaded the 2mFo-DFc map from the EDS, and got the same Coot v. PyMOL discrepancy whether or not I turned off the PyMOL map normalization feature. If you load the same map into Pymol and ask it to normalize the density values you should set your contour level to Coot's rmsd level. If you don't normalize you should use Coot's e/A^3 level. It is quite possible that they could differ by a factor of two. This was exactly the case. The map e/A^3 level (not the rmsd level) in Coot matched very well, visually, the map 'level' in PyMOL; they were roughly off by a factor of 2. I did end up also generating a 2mFo-DFc map using phenix, which fetched the structure factors of the model in which I was interested. The result was the same (i.e. PyMOL 'level' = Coot e/A^3 level ~ = 1/2 Coot's rmsd level) whether I used the CCP4 map downloaded from the EDS, or generated from the structure factors with phenix. Thanks All. Emily. Dale Tronrud On 5/29/2015 1:15 PM, Emilia C. Arturo (Emily) wrote: Hello. I am struggling with an old question--old because I've found several discussions and wiki bits on this topic, e.g. on the PyMOL mailing list (http://sourceforge.net/p/pymol/mailman/message/26496806/ and http://www.pymolwiki.org/index.php/Display_CCP4_Maps), but the suggestions about how to fix the problem are not working for me, and I cannot figure out why. Perhaps someone here can help: I'd like to display (for beauty's sake) a selection of a model with the map about this selection. I've fetched the model from the PDB, downloaded its 2mFo-DFc CCP4 map, loaded both the map and model into both PyMOL (student version) and Coot (0.8.2-pre EL (revision 5592)), and decided that I would use PyMOL to make the figure. I notice, though, that the map 'level' in PyMOL is not equivalent to the rmsd level in Coot, even when I set normalization off in PyMOL. I expected that a 1.0 rmsd level in Coot would look identical to a 1.0 level in PyMOL, but it does not; rather, a 1.0 rmsd level in Coot looks more like a 0.5 level in PyMOL. Does anyone have insight they could share about the difference between how Coot and PyMOL loads maps? Maybe the PyMOL 'level' is not a rmsd? is there some other normalization factor in PyMOL that I should set? Or, perhaps there is a mailing list post out there that I've missed, to which you could point me. :-) Alternatively, does anyone have instructions on how to use Coot to do what I'm trying to do in PyMOL? In PyMOL I displayed the mesh of the 2Fo-Fc map, contoured at 1.0 about a 3-residue-long 'selection' like so: isomesh map, My_2Fo-Fc.map, 1.0, selection, carve=2.0, and after hiding everything but the selection, I have a nice picture ... but with a map at a level I cannot interpret in PyMOL relative to Coot :-/ Regards, Emily. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iEYEARECAAYFAlVo1L4ACgkQU5C0gGfAG10YkwCfROYPVXBK/pDS4z/zi5MNY1D+ nHIAnjOFiAkb6JbuIGWRWkBFDG5Xgc2K =hrPT -END PGP SIGNATURE- -- Thomas Holder PyMOL Principal Developer Schrödinger, Inc.
Re: [ccp4bb] PyMOL v. Coot map 'level'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You are correct about this. The magnitude of this effect depends on the amount of solvent in your crystal (which tends to be flatter) but it rarely reaches a factor of two. This does point out a serious flaw with contouring a map relative to its rms (one of many). If you calculate a map that just covers the interesting part, it probably contains a lot of features. The rms calculated from that region of the map alone will be larger and your features will look smaller. If you set a contour level relative to e/A^3 the appearance of the image will not depend on the region of space covered by your map nor the percentage of solvent in the crystal. Dale Tronrud On 6/1/2015 9:16 AM, Thomas Holder wrote: Hi Emilia et al., I tried to figure out the PyMOL vs. Coot normalization discrepancy a while ago. As far as I remember, PyMOL normalizes on the raw data array, while Coot normalizes across the unit cell. So if the data doesn't exactly cover the cell, the results might be different. Cheers, Thomas On 01 Jun 2015, at 11:37, Emilia C. Arturo (Emily) ec...@drexel.edu wrote: One cannot understand what is going on without knowing how this map was calculated. Maps calculated by the Electron Density Server have density in units of electron/A^3 if I recall, or at least its best effort to do so. This is what I was looking for! (i.e. what the units are) Thanks. :-) Yes, I'd downloaded the 2mFo-DFc map from the EDS, and got the same Coot v. PyMOL discrepancy whether or not I turned off the PyMOL map normalization feature. If you load the same map into Pymol and ask it to normalize the density values you should set your contour level to Coot's rmsd level. If you don't normalize you should use Coot's e/A^3 level. It is quite possible that they could differ by a factor of two. This was exactly the case. The map e/A^3 level (not the rmsd level) in Coot matched very well, visually, the map 'level' in PyMOL; they were roughly off by a factor of 2. I did end up also generating a 2mFo-DFc map using phenix, which fetched the structure factors of the model in which I was interested. The result was the same (i.e. PyMOL 'level' = Coot e/A^3 level ~ = 1/2 Coot's rmsd level) whether I used the CCP4 map downloaded from the EDS, or generated from the structure factors with phenix. Thanks All. Emily. Dale Tronrud On 5/29/2015 1:15 PM, Emilia C. Arturo (Emily) wrote: Hello. I am struggling with an old question--old because I've found several discussions and wiki bits on this topic, e.g. on the PyMOL mailing list (http://sourceforge.net/p/pymol/mailman/message/26496806/ and http://www.pymolwiki.org/index.php/Display_CCP4_Maps), but the suggestions about how to fix the problem are not working for me, and I cannot figure out why. Perhaps someone here can help: I'd like to display (for beauty's sake) a selection of a model with the map about this selection. I've fetched the model from the PDB, downloaded its 2mFo-DFc CCP4 map, loaded both the map and model into both PyMOL (student version) and Coot (0.8.2-pre EL (revision 5592)), and decided that I would use PyMOL to make the figure. I notice, though, that the map 'level' in PyMOL is not equivalent to the rmsd level in Coot, even when I set normalization off in PyMOL. I expected that a 1.0 rmsd level in Coot would look identical to a 1.0 level in PyMOL, but it does not; rather, a 1.0 rmsd level in Coot looks more like a 0.5 level in PyMOL. Does anyone have insight they could share about the difference between how Coot and PyMOL loads maps? Maybe the PyMOL 'level' is not a rmsd? is there some other normalization factor in PyMOL that I should set? Or, perhaps there is a mailing list post out there that I've missed, to which you could point me. :-) Alternatively, does anyone have instructions on how to use Coot to do what I'm trying to do in PyMOL? In PyMOL I displayed the mesh of the 2Fo-Fc map, contoured at 1.0 about a 3-residue-long 'selection' like so: isomesh map, My_2Fo-Fc.map, 1.0, selection, carve=2.0, and after hiding everything but the selection, I have a nice picture ... but with a map at a level I cannot interpret in PyMOL relative to Coot :-/ Regards, Emily. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iEYEARECAAYFAlVo1L4ACgkQU5C0gGfAG10YkwCfROYPVXBK/pDS4z/zi5MNY1D+ nHIAnjOFiAkb6JbuIGWRWkBFDG5Xgc2K =hrPT -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iEYEARECAAYFAlVskp8ACgkQU5C0gGfAG12urQCfQs1pkluJuYXVtULqNrBcBLE8 vykAoJ8fOqU2BnmGmNj+qspFX4/7Jo4T =LMS8 -END PGP SIGNATURE-
Re: [ccp4bb] PyMOL v. Coot map 'level'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 One cannot understand what is going on without knowing how this map was calculated. Maps calculated by the Electron Density Server have density in units of electron/A^3 if I recall, or at least its best effort to do so. There are many problems with getting this exact and I don't think the server does anything fancy to overcome them. When Coot reads the file it calculates the rms deviation from 0.0 and reports the contour level both relative to that rmsd and in raw units (whatever they were, Coot could care less). Some programs normalize the maps they calculate so the rmsd will be equal to 1.0. When Coot reads such a map its two contour level indicators will be the same. If you load the same map into Pymol and ask it to normalize the density values you should set your contour level to Coot's rmsd level. If you don't normalize you should use Coot's e/A^3 level. It is quite possible that they could differ by a factor of two. Dale Tronrud On 5/29/2015 1:15 PM, Emilia C. Arturo (Emily) wrote: Hello. I am struggling with an old question--old because I've found several discussions and wiki bits on this topic, e.g. on the PyMOL mailing list (http://sourceforge.net/p/pymol/mailman/message/26496806/ and http://www.pymolwiki.org/index.php/Display_CCP4_Maps), but the suggestions about how to fix the problem are not working for me, and I cannot figure out why. Perhaps someone here can help: I'd like to display (for beauty's sake) a selection of a model with the map about this selection. I've fetched the model from the PDB, downloaded its 2mFo-DFc CCP4 map, loaded both the map and model into both PyMOL (student version) and Coot (0.8.2-pre EL (revision 5592)), and decided that I would use PyMOL to make the figure. I notice, though, that the map 'level' in PyMOL is not equivalent to the rmsd level in Coot, even when I set normalization off in PyMOL. I expected that a 1.0 rmsd level in Coot would look identical to a 1.0 level in PyMOL, but it does not; rather, a 1.0 rmsd level in Coot looks more like a 0.5 level in PyMOL. Does anyone have insight they could share about the difference between how Coot and PyMOL loads maps? Maybe the PyMOL 'level' is not a rmsd? is there some other normalization factor in PyMOL that I should set? Or, perhaps there is a mailing list post out there that I've missed, to which you could point me. :-) Alternatively, does anyone have instructions on how to use Coot to do what I'm trying to do in PyMOL? In PyMOL I displayed the mesh of the 2Fo-Fc map, contoured at 1.0 about a 3-residue-long 'selection' like so: isomesh map, My_2Fo-Fc.map, 1.0, selection, carve=2.0, and after hiding everything but the selection, I have a nice picture ... but with a map at a level I cannot interpret in PyMOL relative to Coot :-/ Regards, Emily. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iEYEARECAAYFAlVo1L4ACgkQU5C0gGfAG10YkwCfROYPVXBK/pDS4z/zi5MNY1D+ nHIAnjOFiAkb6JbuIGWRWkBFDG5Xgc2K =hrPT -END PGP SIGNATURE-
[ccp4bb] PyMOL v. Coot map 'level'
Hello. I am struggling with an old question--old because I've found several discussions and wiki bits on this topic, e.g. on the PyMOL mailing list ( http://sourceforge.net/p/pymol/mailman/message/26496806/ and http://www.pymolwiki.org/index.php/Display_CCP4_Maps), but the suggestions about how to fix the problem are not working for me, and I cannot figure out why. Perhaps someone here can help: I'd like to display (for beauty's sake) a selection of a model with the map about this selection. I've fetched the model from the PDB, downloaded its 2mFo-DFc CCP4 map, loaded both the map and model into both PyMOL (student version) and Coot (0.8.2-pre EL (revision 5592)), and decided that I would use PyMOL to make the figure. I notice, though, that the map 'level' in PyMOL is not equivalent to the rmsd level in Coot, even when I set normalization off in PyMOL. I expected that a 1.0 rmsd level in Coot would look identical to a 1.0 level in PyMOL, but it does not; rather, a 1.0 rmsd level in Coot looks more like a 0.5 level in PyMOL. Does anyone have insight they could share about the difference between how Coot and PyMOL loads maps? Maybe the PyMOL 'level' is not a rmsd? is there some other normalization factor in PyMOL that I should set? Or, perhaps there is a mailing list post out there that I've missed, to which you could point me. :-) Alternatively, does anyone have instructions on how to use Coot to do what I'm trying to do in PyMOL? In PyMOL I displayed the mesh of the 2Fo-Fc map, contoured at 1.0 about a 3-residue-long 'selection' like so: isomesh map, My_2Fo-Fc.map, 1.0, selection, carve=2.0, and after hiding everything but the selection, I have a nice picture ... but with a map at a level I cannot interpret in PyMOL relative to Coot :-/ Regards, Emily.
Re: [ccp4bb] PyMOL v. Coot map 'level'
Hi Emilia, Did you construct the map at the same sampling rate as COOT uses? This makes a big difference. You can also just use CCP4mg. You can make very nice pictures with that and you can do all the map things there. CCP4mg supports mtz files directly, so no mucking about with map files. If you want to show a PDB entry, you can get the mtz file straight from EDS or (shameless plug) PDB_REDO without having to manually download stuff. Also a very nice feature is that whenever you make a picture, CCP4mg writes out the scene information so you can reconstruct and modify the scene at some later point. You don’t need to remember to do that yourself. Cheers, Robbie From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Emilia C. Arturo (Emily) Sent: Friday, May 29, 2015 22:16 To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] PyMOL v. Coot map 'level' Hello. I am struggling with an old question--old because I've found several discussions and wiki bits on this topic, e.g. on the PyMOL mailing list (http://sourceforge.net/p/pymol/mailman/message/26496806/ and http://www.pymolwiki.org/index.php/Display_CCP4_Maps), but the suggestions about how to fix the problem are not working for me, and I cannot figure out why. Perhaps someone here can help: I'd like to display (for beauty's sake) a selection of a model with the map about this selection. I've fetched the model from the PDB, downloaded its 2mFo-DFc CCP4 map, loaded both the map and model into both PyMOL (student version) and Coot (0.8.2-pre EL (revision 5592)), and decided that I would use PyMOL to make the figure. I notice, though, that the map 'level' in PyMOL is not equivalent to the rmsd level in Coot, even when I set normalization off in PyMOL. I expected that a 1.0 rmsd level in Coot would look identical to a 1.0 level in PyMOL, but it does not; rather, a 1.0 rmsd level in Coot looks more like a 0.5 level in PyMOL. Does anyone have insight they could share about the difference between how Coot and PyMOL loads maps? Maybe the PyMOL 'level' is not a rmsd? is there some other normalization factor in PyMOL that I should set? Or, perhaps there is a mailing list post out there that I've missed, to which you could point me. :-) Alternatively, does anyone have instructions on how to use Coot to do what I'm trying to do in PyMOL? In PyMOL I displayed the mesh of the 2Fo-Fc map, contoured at 1.0 about a 3-residue-long 'selection' like so: isomesh map, My_2Fo-Fc.map, 1.0, selection, carve=2.0, and after hiding everything but the selection, I have a nice picture ... but with a map at a level I cannot interpret in PyMOL relative to Coot :-/ Regards, Emily.
