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 > > > 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.
