-----BEGIN PGP SIGNED MESSAGE-----
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.
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)
> <[log in to unmask]> 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.
>> 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
>>> 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)
>> nHIAnjOFiAkb6JbuIGWRWkBFDG5Xgc2K =hrPT -----END PGP
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
-----END PGP SIGNATURE-----