Looks like it is here: 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]>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/
>
> 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
>
>
--
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
