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/
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]> 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]>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]>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
>>> 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
>> _______________________________________________
>> 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
>
>
------------------------------------------------------------------------------
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
