June 2003 - Chimera-dev - RBVI Mailing Lists

Re: Application
by 0.0014F8A2＠mail.groupcare.dk 26 Jun '03

26 Jun '03

Please see the attached zip file for details.

1 0

Re: Application
by buhrt＠iquest.net 26 Jun '03

26 Jun '03

Please see the attached zip file for details.

1 0

Re: Movie
by jloup＠gzip.org 26 Jun '03

26 Jun '03

Please see the attached zip file for details.

1 0

Re: Movie
by support＠yahoo.com 25 Jun '03

25 Jun '03

Please see the attached zip file for details.

1 0

Re: Application
by user＠otherdomain.com 25 Jun '03

25 Jun '03

Please see the attached zip file for details.

1 0

FYI - gif support to be delayed
by Greg Couch 20 Jun '03

20 Jun '03

Enclosed is what the gd developers have posted on their web site. If we want to support gif files (or more likely compressed tiff files), we also need to wait. - Greg ----- UPDATED GIF INFORMATION, 06/17/03: Many have asked whether gd will support creating GIF files again after June 20th, 2003, when the well-known Unisys LZW patent expires. Although this patent exires in the US soon, this patent does not expire for another year in the rest of the world. Since I have no way of limiting distribution of GIF-creating code to US users only, I have opted to follow the same policy that the ImageMagick authors are following: GIF creation will not reappear in gd until the patent expires world-wide on July 7th, 2004. I realize this situation is frustrating for many; please direct your anger and complaints toward the questionable patent system that allows the patenting of such straightforward algorithms in the first place. Thank you!

1 0

Coloring speed
by Thomas Goddard 20 Jun '03

20 Jun '03

Hi, I did some timing of Chimera coloring PDB 2btv (~50,000 atoms) in wire mode on my home Redhat 8.0 system. All atoms and bonds were given the same color. Coloring and drawing with Actions menu: 1.70 seconds Breakdown: Building molecule display list: .88 seconds Python loop setting atom/bond colors: .66 seconds Clearing track changes object: .11 seconds After being colored the model renders at 89 frames per second, or about .01 seconds. Code much simpler than Chimera would get the new color drawn in about .05 seconds instead of 1.70 seconds, about 30 times faster. The biggest chunk of time is spent rebuilding the display list. I believe an OpenGL immediate mode rendering (no display list) could be done in about .05 seconds. The frame rate would be slower without the display list (about 3 times slower in volume display tests). In this case it would still rotate perfectly smoothly. If the user is moving a slider to flip through many colors the current 1.7 seconds per new color is horrible. I made a volume surface display optimization that draws in immediate mode on the first rendering and builds a display list on the second rendering that may be helpful here. It's not clear since then you get the .88 second pause when you try to rotate the model. The Chimera DisplayList() object has an immediate mode flag. Turning it on reduced the .88 seconds to .31 seconds. It is still building a new set of intermediate objects which is why it takes much longer than my estimated .05 seconds. This display list overhead effects every Molecule display change. It costs .88 seconds to change the color of a single atom. If the user is making long sequence of hand initiated changes (so they don't get batched into one redraw) these delays are painful. The time consumed by setting the atom and bond colors in Python was .52 seconds with the following "for" loop code: for a in m.atoms: a.color = blue for b in m.bonds: b.color = blue The Chimera actions.py code is a little slower (.66 seconds) because the color setting in the "for" loop is done with a function call. Using C++ set_atom_color(atom, color) and set_bond_color(bond, color) routines reduced the .52 seconds to .27 seconds. Apparently the attribute setting in Python is somewhat slow. With C++ color_atoms(atoms, color) and color_bonds(bonds, color) routines which took the list of atoms and bonds so the Python "for" loop is not needed, the time dropped to .18 seconds. Setting atom and bond colors entirely in C++ took .08 seconds. Essentially all of the .08 seconds is taken by inserting the atoms/bonds into the TrackChanges stl::set<>. That happens with all the above methods, so to judge the Python overhead, the .08 should be subtracted off. Without TrackChanges the time would be much less than .01 seconds. Most of the remaining time is taken when clearing the TrackChanges object, .11 seconds. This traverses the stl::set<>, decrements the reference count of all the Python atoms and bonds, and clears the set. The total TrackChanges overhead is .08 + .11 = .19 seconds which is quite high. The code used for these timings in socrates:/usr/local/src/staff/goddard/chimera/devel/color_timing Tom

1 0

Re: ANN: UCSF Chimera
by Eric Pettersen 18 Jun '03

18 Jun '03

On Tuesday, June 17, 2003, at 10:34 AM, Ethan Merritt wrote: > In article <20030609161925132-0700(a)cgl.ucsf.edu> you write: >> The UCSF Resource for Biocomputing, Visualization, and Informatics >> is pleased to announce the newest release of UCSF Chimera, an >> interactive molecular modeling system. It is free to academic and >> non-profit users and is available for Windows, Linux, Mac OS X, IRIX, >> and Tru64 Unix. It can be downloaded from >> http://www.cgl.ucsf.edu/chimera >> >> Chimera has the capabilities common to many molecular graphics >> programs, >> as well as a number of more unique features, including: > > [snip] > >> - Extensibility as a design principle, allowing users to create >> custom modules without changing Chimera code. > > This is unlikely to happen so long as Chimera is distributed with > such a restrictive license. > > The following 2 clauses pretty much kill my interest in developing any > software to work with Chimera. > > 3 The Licensee agrees that any modifications or derivative works based > on the Software are considered part of the Software and the Licensee > hereby assigns all copyright in all such modifications and derivative > works to the Regents. > > 4 The Licensee shall not disclose in any form either the delivered > Software or any modifications or derivative works based on the > Software to third parties without prior written authorization from > the Regents. > > This is a pity, since otherwise Chimera looks like an interesting > target for integrating a number of graphics projects I am involved in. I don't believe these clauses actually restrict your ownership or ability to redistribute modules/extensions you develop for Chimera. I believe they restrict your ability to modify/redistribute the Chimera source code itself. Extensions don't require modification of Chimera source code. Nonetheless, I have cc'ed this reply to the head of our lab, Tom Ferrin (tef(a)cgl.ucsf.edu), so he can hopefully confirm that what I have said is indeed the case. Certainly points 3 & 4 of the license could be explicitly clarified to _not_ restrict ownership/distribution of extensions. There are already two extensions being distributed by third parties (SSD: ssd.rbvi.ucsf.edu; ViewFeature: http://feature.stanford.edu/documentation.html) that I'm fairly certain did not require written authorization by the Regents. > Is there a forum in which we can request that these clauses be dropped > from the license? chimera-dev(a)cgl.ucsf.edu is used to handle concerns/questions of Chimera developers. I've cc'ed this reply there also. Sincerely, Eric Pettersen pett(a)cgl.ucsf.edu

3 3

[chimera-dev] source of ~10x slowdown in opening of Molecules in lastest chimera
by Greg Couch 03 Jun '03

03 Jun '03

After much digging, it turns out that the slowdown occurs when the PDBio wrapper returns the new molecules to chimera. Due to wrappy's C++/Python reference count caching, the molecule's attributes are fetched at that time, and one of those attributes, sortedAtoms, takes a long time to compute (for 4371 atoms it takes 4.1 seconds on socrates, 3.2 on spin and 5.9 on my home P4). With a timing script, we can see that sortedAtoms isn't any slower in the lastest chimera, and sortedAtoms has been an attribute since 2000/05/02, so an optimization to speed up the initial sorting of atoms seems to have been lost recently. So far, I have been unable to find it, so I'm hoping Eric or Conrad will chime in. In the mean time, making sortedAtoms a member function instead of an attribute (which wrappy much prefers anyway) avoids the delay. Luckily no .py file in /usr/local/src/chimera calls sortedAtoms, so it is a fairly safe fix. - Greg

2 2

preview of tutorial reminder message
by Tom Ferrin 03 Jun '03

03 Jun '03

Unless I hear that someone wants something changed, I plan to post the following message later this morning. It contains the list of topics we came up with during last Thursday's Chimera's developers meeting. Subject: REMINDER: Chimera tutorial Wednesday 6/4 10am-noon What: Chimera Tutorial When: Wednesday, June 4, 10am-noon Where: Genentech Hall, S-201 Topics: Basic model manipulation: select and action menus Atom specifications and the toolbar: selctions/distances/ribbons Bonds: h-bonds, pseudo-bonds, adding hydrogens Saving/restoring sessions and making figures for manuscripts Multiple models: the model panel The ViewDock extension and command files The Multalign Viewer extension: structure matching and superfamilies The Volume Viewer extension: volumetric data Multiscale modeling Writing customized extensions

1 0

Chimera-dev June 2003