OK. great. Uploading now and revising documentation.
On Sat, Feb 27, 2010 at 10:34 AM, Thomas Stout <[email protected]>wrote:
> That's great -- the DNS6 format is only the root of all maps at EDS. EDS
> was created by the same people that were behind O development so it is their
> preferred format. You're quite correct that it is severely limited in
> magnitude range - that coupled w/ the lack of a magic integer and
> informative header makes this a fairly unappealing format to me. However,
> for initiatives like Proteopedia there is currently no alternative. No where
> else is providing density maps for all entries in the PDB. The only other
> approach would be the use the structure factors in the PDB and calculate
> maps, but that presents HUGE sanity problems ... Most of which are handled
> by EDS.
>
> I would agree that Eric et al. are taking the best available approach by
> using the EDS maps converted to CCP4 format for use in Jmol. These maps
> will inherit the limitations of the O format, but for their purposes that
> should rarely be an issue.
>
> -Tom
>
>
> Sent from a tiny virtual keyboard.
>
> On Feb 27, 2010, at 6:36 AM, Robert Hanson <[email protected]> wrote:
>
> OK, so Jmol 11.9.31 will read DSN6/O map files now.
>
> Is it really true that the "root" format for all the map types is O at
> Uppsala? This seems curious to me. That format only allows a range of 255
> values for electron density values. Wouldn't you think that there could be a
> finer resolution than that? In addition, the format only allows for data
> sets with a (max-min) range greater than about 0.4 and sets a pretty severe
> limitation on the magnitude of the minimum value.
>
> It if is possible to calculate the RMSD from the file data, I'd like to
> know how to do that.
>
> Bob
>
>
> On Fri, Feb 26, 2010 at 4:54 PM, Thomas Stout < <[email protected]>
> [email protected]> wrote:
>
>>
>> Ah - Good find! And yes, that's the "modern" version of the format - the
>> DSN2 or Frodo-style map has been relegated to the dustbins of history.
>> There are no other useful map formats listed on that web site. My opinion
>> would be that the triad of CCP4/MRC, CNS/XPLOR and DSN6 (O-style) covers
>> 99+% of the electron density maps in general use in macromolecular X-ray
>> crystallography.
>>
>> -Tom
>>
>>
>> On Fri, Feb 26, 2010 at 2:47 PM, Robert Hanson < <[email protected]>
>> [email protected]> wrote:
>>
>>> Looks like it is here:
>>> <http://www.uoxray.uoregon.edu/tnt/manual/node104.html>
>>> http://www.uoxray.uoregon.edu/tnt/manual/node104.html
>>> Alas, sadly, a binary file that does not identify itself. Too bad not
>>> everyone thinks of adding a "magic number" at the beginning. Still, we might
>>> be able to do something with this.
>>>
>>> Bob
>>>
>>>
>>>
>>> On Fri, Feb 26, 2010 at 1:55 PM, Thomas Stout < <[email protected]>
>>> [email protected]> wrote:
>>>
>>>>
>>>> Ha! Yeah, I don't think Google was a consideration when this program
>>>> was named back in the 70's...
>>>>
>>>> "O" was written and is still maintained by T. Alwyn Jones of Uppsala
>>>> University in Sweden. His central clearing house can be found at:
>>>> <http://xray.bmc.uu.se/alwyn/>http://xray.bmc.uu.se/alwyn/
>>>>
>>>> I have already written to him and inquired about where to locate the
>>>> format of the DSN6 maps... I'll let you know what I find out.
>>>>
>>>> -Tom
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Feb 26, 2010 at 11:33 AM, Robert Hanson < <[email protected]>
>>>> [email protected]> wrote:
>>>>
>>>>> Thanks, Tom. Sounds fine to me.
>>>>>
>>>>> I'd like to know more about the O format. We have other binary readers,
>>>>> and if this would be of interest, why not? It's easy enough to set up a
>>>>> new
>>>>> reader. I couldn't find anything about it myself, because it's basically
>>>>> unGooglable.
>>>>>
>>>>> Bob
>>>>>
>>>>>
>>>>> On Wed, Feb 24, 2010 at 10:48 AM, Thomas Stout <<[email protected]>
>>>>> [email protected]> wrote:
>>>>>
>>>>>>
>>>>>> Regarding EDS CNS format.... I wrote to Gerard Klegveyt, one of the
>>>>>> principal authors of EDS, and asked about the CNS map format issue.
>>>>>> Here is
>>>>>> his response, which I think further nullifies CNS as a viable streaming
>>>>>> format:
>>>>>>
>>>>>>
>>>>>> Hi Tom,
>>>>>>
>>>>>> No, it seems that Jmol and you made the same mistake that I made a
>>>>>> long time
>>>>>> ago in assuming that the last line contains the average and sigma - it
>>>>>> does
>>>>>> not! There was a bug in MAPMAN for many years because of this which
>>>>>> wasn't
>>>>>> fixed until 2006:
>>>>>>
>>>>>> 061124 -7.8.2- fixed bug in writing ASCII CNS maps (last line should
>>>>>> contain 0
>>>>>> and 1 instead of the actual average and st. dev. of the density, since
>>>>>> the
>>>>>> maps are not scaled)
>>>>>>
>>>>>> The reason why nobody picked up on this previously was probably that
>>>>>> most
>>>>>> programs simply ignore the last line. So: the two numbers are a scale
>>>>>> and an
>>>>>> offset in case you have scaled the values in the map, and they should
>>>>>> be
>>>>>> applied to the density values upon reading the map if you want to do
>>>>>> things
>>>>>> properly.
>>>>>>
>>>>>> Hope this helps,
>>>>>>
>>>>>> --Gerard
>>>>>>
>>>>>>
>>>>>> We could certainly ask for RMS and other map stats to be added to the
>>>>>> header, but then it would no longer be CNS/XPLOR format & EDS would
>>>>>> undoubtedly not be willing to risk breaking other people's use of the CNS
>>>>>> format maps served by EDS. If CCP4 format is working, then I don't see
>>>>>> much need to pursue the CNS format. The "root" format that EDS is using
>>>>>> is
>>>>>> DSN6 ("O" format), but since that is a binary file format I'm guessing
>>>>>> that's not preferred for "on demand" slice reading either.
>>>>>>
>>>>>> -Tom
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 24, 2010 at 5:06 AM, Robert Hanson < <[email protected]>
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> resending -- message was too long for list.
>>>>>>>
>>>>>>> <snip for length>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>>
>>>>>>> OK, progress! Good job, Thomas.
>>>>>>>
>>>>>>> Well, it wouldn't be the first time that we have found errors in
>>>>>>> other systems while working on Jmol. Still proud of finding the bug in
>>>>>>> ORTEP!
>>>>>>>
>>>>>>> Right, so here is where we are:
>>>>>>>
>>>>>>> a) Then I have Jmol working correctly now for MRC/CCP4 files, and
>>>>>>> Eric should be telling us soon that all is to his liking, even with the
>>>>>>> default of not specifying sigma, since that will go in as sigma=1.0,
>>>>>>> which
>>>>>>> is what he wants, I think.
>>>>>>>
>>>>>>> b) If you can look into the Uppsala problem, that would be great.
>>>>>>> Unless I'm way off base there, that needs to be fixed. I just can't see
>>>>>>> how
>>>>>>> it can have essentially the same min, max, and mean as the MRC data
>>>>>>> from the
>>>>>>> same server and not have those reported in the file. Should be pretty
>>>>>>> easy
>>>>>>> for them to check out.
>>>>>>>
>>>>>>> c) That said, the CNS/Xplor format very disappointingly is not
>>>>>>> designed with streaming in mind. One of Jmol's newer features is that it
>>>>>>> never has to actually load all the volumetric data (the way PyMOL
>>>>>>> does). It
>>>>>>> just streams the data in slice by slice and creates the surface on the
>>>>>>> fly.
>>>>>>> This is far faster and far more memory efficient and allows Jmol now to
>>>>>>> display huge surfaces that it never could before.
>>>>>>>
>>>>>>> Well, for that to work, you clearly have to have the cutoff initially
>>>>>>> set. But if it comes at the end of a file -- that's fine for reading a
>>>>>>> file
>>>>>>> off the hard drive, but over the web -- where you don't have the
>>>>>>> equivalent
>>>>>>> of "file.seek()" to jump to the end first, get the info, and then come
>>>>>>> back
>>>>>>> -- that's just not possible. That's too bad.
>>>>>>>
>>>>>>> So the point is that while I think it's important that that gets
>>>>>>> fixed, if it really is in error, fixing that is not going to allow Jmol
>>>>>>> to
>>>>>>> read those files efficiently. I hate to think that we would have to read
>>>>>>> them twice just to do the job. I suppose we could do that.... In any
>>>>>>> case,
>>>>>>> the MRC/CCP4 files should be scaling properly now.
>>>>>>>
>>>>>>> d) Thomas, if you could look into the electron microscopy business,
>>>>>>> that would be great as well.
>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>> Great. Thanks, Tom.
>>>>>>>
>>>>>>> Sigma -- This all makes good sense. It explains why 2sigma was a
>>>>>>> better match to the EM data, which was the original reason I
>>>>>>> implemented the
>>>>>>> MRC format. But it also seems to me to be quite reasonable to just set
>>>>>>> sigma=1 to be the default and let people who want to display EM data
>>>>>>> set the
>>>>>>> sigma explicitly.
>>>>>>>
>>>>>>> EDS CNS -- Perhaps we could lobby for also including an indication of
>>>>>>> RMSD in the header comment.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
> ------------------------------------------------------------------------------
> 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
