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]> 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]>
wrote:
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
---
---
---
---------------------------------------------------------------------
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
