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
