From: Thomas S. <tho...@gm...> - 2010-02-27 16:34:44
|
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 <ha...@st...> 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 > <tho...@gm...> 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 <ha...@st...> > 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 > <tho...@gm...> 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 <ha...@st...> > 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 > <tho...@gm...> 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 <ha...@st...> > 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 > Jmo...@li... > 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 > Jmo...@li... > 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 > Jmo...@li... > 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 > Jmo...@li... > 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 > Jmo...@li... > 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 > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users |