That would be great, Thomas. Here's what I know:
- The MRC/CCP4 files include records that are called dmin, dmax, dmean, and
rms.
- Jmol tracks min, max, and mean, and those values agree reasonably well
with those in the file. For example, for the Uppsala file for 3hyd.ccp4 that
Eric has been using, we have:
MRC header: dmin,dmax,dmean: -1.1890318,4.998787,-0.014114891
MRC header: rms: 0.74718976
and then from Jmol tracking these values: data min/max/mean = -1.1890318,
4.998787, -0.01760154
I can't explain the slight difference in the mean there, but it's not
exactly 0.
- Though referred to as "RMS" in the code, the documentation for the MRC
format clearly identifies this value as "rms deviation" and not actual
"rms". http://ami.scripps.edu/software/mrctools/mrc_specification.php
This makes me think that the proper way to present the data is to add in the
mean. Otherwise, the mean could be anything, and the cutoff value would be
meaningless.
- What I implemented in Jmol 11.9.30 is "mean + rmsd*sigma". In previous
versions of Jmol I had found that a default of 2 there for "sigma" better
fit electron microscopy data.
- Jmol needs to be able to represent a broad range of data, including both
X-ray and electron microscopy data. Both these fields use the MRC/CCP4
format. So, for example, from EMDB I can get
http://emsearch.rutgers.edu/atlas/1003_downloads.html:
MRC header: dmin,dmax,dmean: -141.97543,339.987,1.8575257
MRC header: rms: 38.04587
MRC header: labels: CONVERTED FROM SPIDER TO CCP4 USING SPIDER
Cutoff set to sigma 1.0 or (mean + rmsDeviation) = 39.903397
Again, the mean isn't 0.
I had used 2 sigma because that was the best ad hoc visual fit to what I was
seeing in the electron microscopy literature. So I'm wondering now if
different fields have different standards.
Bob
On Mon, Feb 22, 2010 at 1:38 AM, Thomas Stout <[email protected]>wrote:
> I will try and track down the actual algorithm used - CCP4, O, PyMOL,
> MAPMAN, XPLOR/CNS, SOLVE and Phenix (and others) all read and/or write
> electron density maps with the same understanding of "sigma" levels, so it
> is well standardized in the field. I'm fairly certain that it is just RMSD
> but will need to confirm that... If -- in the map that you and Eric are
> looking at -- 1 rmsd happens to correspond to the mean, would that account
> for the factor of 2 if you are using "mean + rmsd*sigma"?
>
> -Tom
>
> Sent from a tiny virtual keyboard.
>
> On Feb 21, 2010, at 8:56 PM, Robert Hanson <[email protected]> wrote:
>
> Eric, it looks like the sigma values associated with Pymol are just 1/2 the
> default cutoffs of Jmol. So, for example, the one you say has 0.75 for the
> best fit has a default Jmol cutoff of 1.4803, and the one with best fit 0.33
> has a default Jmol cutoff of 0.67.
>
> Maybe Thomas can explain how sigma is related in this way. What we can do
> is create a new sigma parameter for the Jmol isosurface command that will
> match Pymol's sigma -- at least for (some) ccp4 files. Worth a shot.
>
> Bob
>
>
> On Sun, Feb 21, 2010 at 10:09 PM, Robert Hanson < <[email protected]>
> [email protected]> wrote:
>
>> That sounds about right.
>>
>> We need to track down the definition of "sigma" that pymol is using.
>> Jmol's definition of "cutoff" is straightforward -- just the actual
>> isovalue. Not having any familiarity at all with python, I haven't been able
>> to find this in the Pymol code.
>>
>> Perhaps someone else can spot that....
>>
>> Bob
>>
>>
>>
>> On Sun, Feb 21, 2010 at 7:59 AM, Eric Martz < <[email protected]>
>> [email protected]> wrote:
>>
>>> OK, I misinterpreted the scaling differences in my previous report. The
>>> problem appears to be a simple scaling factor difference between Jmol's
>>> isomesh cutoff value and PyMOL's isomesh sigma value. (Contrary to my
>>> previous interpretation, I don't think the scaling varies from the center of
>>> the molecule.)
>>>
>>> However, I now notice that the scale factor (cutoff vs. sigma ratio that
>>> makes the two isomeshes the same) varies with the size of the molecule
>>> loaded.
>>>
>>> Detailed demonstrations are at the top link on this list:
>>> <http://www.umass.edu/molvis/tests/>http://www.umass.edu/molvis/tests/
>>>
>>> -Eric
>>>
>>> --- On Fri, 2/19/10, Robert Hanson < <[email protected]>
>>> [email protected]> wrote:
>>>
>>> > From: Robert Hanson < <[email protected]>[email protected]>
>>> > Subject: Re: [Jmol-users] Problem w/ electron dens. maps
>>> > To: <[email protected]>[email protected]
>>> > Date: Friday, February 19, 2010, 7:40 PM
>>> > Exactly the problem. We have wildly
>>> > different data sets -- from electron diffraction to X-ray
>>> > data. Where did we end up with that discussion about sigma?
>>> > I can certainly look at the Pymol code and see what Warren
>>> > did there.
>>> >
>>> >
>>> > Bob
>>> >
>>> > On Fri, Feb 19, 2010 at 11:37 AM,
>>> > Thomas Stout < <[email protected]>[email protected]>
>>> > wrote:
>>> >
>>> >
>>> > But electron density maps can be on arbitrary scales, so
>>> > the value "1.0" may very well be meaningless
>>> > (except in the particular case where normalization has made
>>> > 1.0=1e-/A**3), and will certainly produce wildly different
>>> > results from dataset to dataset depending on the provenance
>>> > of each particular dataset (scale factors, etc). The
>>> > "standard" in macromolecular crystallography is to
>>> > view density maps at 1.0sigma & "difference
>>> > maps" at 3.0sigma.
>>> >
>>> >
>>> >
>>> > -Tom
>>> >
>>> >
>>> > On
>>> > Fri, Feb 19, 2010 at 7:49 AM, Robert Hanson < <[email protected]>
>>> [email protected]>
>>> > wrote:
>>> >
>>> >
>>> > Eric, I think this is just that Pymol has a different
>>> > definition -- 1.0 sigma is not 1.0 value. Jmol uses actual
>>> > value 1.0, not "sigma" 1.0.
>>> >
>>> > Bob
>>> >
>>> >
>>> > On Fri, Feb 19, 2010 at 7:26 AM, Eric Martz < <[email protected]>
>>> [email protected]>
>>> > wrote:
>>> >
>>> > Dear Bob,
>>> >
>>> >
>>> >
>>> > I'm sorry to report that Jmol 11.9.29 is not displaying
>>> > ccp4 electron density maps correctly as isomeshes. I have
>>> > demonstrated a major problem here (hopefully not major to
>>> > fix):
>>> >
>>> >
>>> >
>>> > <http://www.umass.edu/molvis/tests/jmol_edm_test5/>
>>> http://www.umass.edu/molvis/tests/jmol_edm_test5/
>>> >
>>> >
>>> >
>>> > -Eric
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> <http://p.sf.net/sfu/intel-sw-dev>http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Jmol-users mailing list
>>> <[email protected]>[email protected]
>>> <https://lists.sourceforge.net/lists/listinfo/jmol-users>
>>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>>
>>
>>
>>
>> --
>> Robert M. Hanson
>> Professor of Chemistry
>> St. Olaf College
>> 1520 St. Olaf Ave.
>> Northfield, MN 55057
>> <http://www.stolaf.edu/people/hansonr>
>> http://www.stolaf.edu/people/hansonr
>> phone: 507-786-3107
>>
>>
>> If nature does not answer first what we want,
>> it is better to take what answer we get.
>>
>> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>>
>
>
>
> --
> Robert M. Hanson
> Professor of Chemistry
> St. Olaf College
> 1520 St. Olaf Ave.
> Northfield, MN 55057
> <http://www.stolaf.edu/people/hansonr>http://www.stolaf.edu/people/hansonr
> phone: 507-786-3107
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
>
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>
> _______________________________________________
> Jmol-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Jmol-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
