So the balance here will be with what Jmol will do and what people want to customize it to do (at web pages, for example).
Mauricio Carrillo Tripp wrote: > This is great Bob, and is exactly what I was after last month > (http://www.mail-archive.com/[email protected]/msg10041.html), > my apologies if I was not clear enough then ;) > Now, as for an spherical capsids 'user' at VIPERdb, I would like to be > able to: > > 1) have the option to show/hide any of the biomolecules in the PDB > file, in spherical capsids there's always 60. This doesn't mean all 60 > biomolecules should be loaded initially by default, but only when the > user chooses to. The default will always be to load and show > biomolecule number one. As I understand it, every time the user wants > to display another biomolecule in the biounit, the PDB file needs to > be (down)loaded again and read using a different filter? If so, I > think it would be more practical (but perhaps more trouble to > implement) to load the PDB file once, save all the biomats > corresponding to all the biomolecules in the biounit, and then use > them latter as needed? (this might save a lot of HTTP requests ;) I'm > thinking about buttons to show 1/4, 1/2 or full capsid. But also an > option to show biomols 1,6 and 7 (or any combination), to present an > specific interface. > By default, Jmol will simply load the coordinates -- that's not negotiable. We could imagine a script "set" flag, though, that would direct Jmol to some other behavior. The PDB file does not need to be downloaded again in terms of a browser -- the browser will cache the file, and it will load very fast from the hard drive. Right now the biomolecules (each including biomt matrix array and chain list) are being saved, and in principle they could be accessed later. We can look into this option. In the mean time you will need to do a re-load. But we have load APPEND, and it is very fast with reasonably sized systems, so that might work better than you think. Buttons to show "1/4, 1/2, or full capsid" would have to be set up by a user (you). There are ways to customize the Jmol popup menu -- with a simple small file on disk that expands a menu item. Or if using a web page, it would be an HTML button, perhaps. The different sets of atoms created by individual BIOMT transformations are selectable using the "symop" selection option: select symop=3 select symop<6 etc. (There is a bug there -- symop=1 specifically is not selectable in 11.5.32) > 2) have the option to apply symmetry to any number of chains in the > ASU (many capsids have more than one chain in the ASU), I believe one > can do that with the filter as is, right? I'm thinking of the option > to show chain A of biomol 1 and chain C of biomol 7 (or any > combination), again, to present an specific interface. > So tell me more about what it means when there are multiple biomolecules. What would that indicate? The way you would do this currently would be to load biomolecule 1 into one Jmol frame and biomolecule 7 into another frame. Sounds like you would like to be able to display these independently or together - not a problem. I'm thinking this would be a menu option to load or to load APPEND. > 3) have the option to apply symmetry just to a segment of an specific > chain in the ASU, I believe one can do that with the filter as is, > right? I'm thinking about the option to show only the residues > involved in an specific quaternary structure, beta annulus for > example, around an icosahedral symmetry axis, comprised from a few > residues of chain B of biomol 1, a few from chain C of biomol 6, and > so on ... > Is your interest the applet? This sounds like what Jmol.js is for. > I'm thinking on implementing an ad hoc UI for the above, so I don't > know about the Jmol menu. Although I guess for other systems it would > be nice to have a list of all biomols available. > > 4) have all the biomolecules (as whole or parts, as explained above) > as different model/frame to apply different representations to them. > So, "load append" works? > oh, yes. load append is great. Well tested. The big issue is going to be memory. > Some, or all, of the points above might be valid for other systems > too. As you said Bob, this is huge, and I'm very exited about it, will > certainly simplify the scripts we use, and more importantly, the way > people interact with these structures and learn from them. > > Thanks again for the great work! > my pleasure! -- Robert M. Hanson Professor of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr 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 ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
