- Chimera-users - RBVI Mailing Lists

Re: [Chimera-users] Intersurf, protein interface display
by Thomas Goddard 14 Mar '05

14 Mar '05

Miguel suggests another coloring for protein interface surfaces based on surface complementarity judged by looking at surface normals. Tom ------- Start of forwarded message ------- Date: Sat, 12 Mar 2005 17:25:29 +0000 From: =?ISO-8859-15?Q?Miguel_Ortiz_Lombard=EDa?= <mol1(a)york.ac.uk> To: Thomas Goddard <goddard(a)cgl.ucsf.edu> Subject: Re: [Chimera-users] Intersurf, protein interface display - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tom, With regard to your very interesting message, I would like to add another useful way of studying the surfaces of protein-protein (or protein-whatever) interactions. This way involves the concept of "surface complementarity", where the buried surfaces are scanned to see how parallel are the normals to them at every point (in a grid). It is shown that specific or high-affinity interactions have usually higher complementarity. There is a paper by Lawrence and Colman (http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=pubmed&dopt=A…) and a program by the same authors in the CCP4 suite called "sc" that performs such calculation. The "sc" program is also able to add the "surface complementarity value" to the vertexes of the interacting surfaces calculated in GRASP. I currently have a little program (modified by me from a Raster3D jiffy) to colour such a modified surface according to those values and render it with the render program from Raster3D. But I don't like GRASP and would like to have this analysis as a possibility in chimera. Such analysis have been very useful for me in the past, especially to study protein-protein interactions. If this is also interesting for you I would be glad to be of help. Cheers, Miguel Thomas Goddard wrote: > Hi Conrad, > > I read the paper > > Intersurf: dynamic interface between proteins > Nicolas Ray, Xavier Cavin, Jean-Claude Paul, Bernard Maigret > Journal of Molecular Graphics and Modelling, 23 (205) 347-354 > > It addresses 3 problems: how to find a surface interface between 2 proteins, > ways to color such a surface, and how to flatten that surface into two > dimensions. > > The surface calculation was a neat algorithm -- take the > Delauney tetrahedralization of all atom positions from both proteins, > then find tetrehedra with vertices from both proteins and cut those > tetrahedra in half. The tetrahedra are cut in half with one or 2 > triangles using vertices on tetrahedron edges that connect an atom > in one protein to an atom in the other protein. The vertices are > placed midway between the atoms moved in by their vdw radii. > > They proposed 2 ways of coloring the surface. One colored vertices > by how far apart the atoms were in the two proteins that were used to > create that vertex. Red to blue shows short to long distances. The > other coloring shows types of possible interactions between the two > residues associated with the two atoms for the tetrahedron edge that > the surface vertex splits. They gave different colors for predicted > hydrogen bonding, hydrophobic packing, pi ... X, pi ... pi, same charges, > opposite charges. Not sure what the pi bonding notation means. > > They also described how to flatten the 3-dimensional to a 2-dimensional > surface with one to one correspondence between vertices and edges. > Their method tried to come as close as possible to a conformal map. > Conformal means the angles of the triangles stay the same to the extent > possible. > > These calculations took a few seconds on 2000-5000 atom proteins. > > Here's my assessment. I think the concept of showing a protein interaction > interface and coloring it to show interactions sounds useful for protein- > protein interaction people. I think the flattening into 2 dimensions > is probably not useful. Conformal maps greatly distort the area of > the surface if it has curvature (you've seen the maps where Greenland > is bigger than Africa, Americas, Asia and Europe combined). So the flattened > surface is going to be hard to recognize as the interface, unless it > is already pretty flat. If it is already pretty flat you might as > weill just look at the 3-d surface. > > If we wanted to do something with interface surfaces I would suggest > talking to Tanya Korteme. We already have all the infra-structure to > create the surfaces. I would not use the Delauney surfaces, instead > just use MSMS surfaces on both proteins showing only the parts associated > with atoms in one protein that are within 5 angstroms of atoms in the > other protein. The zone calculation code I wrote for multiscale could > do that fast. We could offer a range of atom colorings that map onto > the surface (hydrogen bonds, distance to nearest atom in other protein, > charge complementarity, etc...). > > I don't have time or enough interest to work on this project. But > perhaps someone else will. We have talked about collaborating with > Tanya Korteme in the past and this would be a good opportunity. > > Tom > > > _______________________________________________ > Chimera-users mailing list > Chimera-users(a)cgl.ucsf.edu > http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users - - -- correo-e: mol1(a)york.ac.uk http://www.ysbl.york.ac.uk/~mol - - ----------------------------------------------------------------------- Et ainsi ne pouvant faire que ce qui est juste fût fort, on a fait que ce qui est fort fût juste. Blaise Pascal, Pensées - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMyYJF6oOrDvhbQIRAttkAJ0frREWIEA7IYDE2LY38jdcyfuRoACgkHLn M9VEY8TEz8HnR3F763pws0A= =zoYa - -----END PGP SIGNATURE----- ------- End of forwarded message -------

1 0

Intersurf, protein interface display
by Thomas Goddard 09 Mar '05

09 Mar '05

Hi Conrad, I read the paper Intersurf: dynamic interface between proteins Nicolas Ray, Xavier Cavin, Jean-Claude Paul, Bernard Maigret Journal of Molecular Graphics and Modelling, 23 (205) 347-354 It addresses 3 problems: how to find a surface interface between 2 proteins, ways to color such a surface, and how to flatten that surface into two dimensions. The surface calculation was a neat algorithm -- take the Delauney tetrahedralization of all atom positions from both proteins, then find tetrehedra with vertices from both proteins and cut those tetrahedra in half. The tetrahedra are cut in half with one or 2 triangles using vertices on tetrahedron edges that connect an atom in one protein to an atom in the other protein. The vertices are placed midway between the atoms moved in by their vdw radii. They proposed 2 ways of coloring the surface. One colored vertices by how far apart the atoms were in the two proteins that were used to create that vertex. Red to blue shows short to long distances. The other coloring shows types of possible interactions between the two residues associated with the two atoms for the tetrahedron edge that the surface vertex splits. They gave different colors for predicted hydrogen bonding, hydrophobic packing, pi ... X, pi ... pi, same charges, opposite charges. Not sure what the pi bonding notation means. They also described how to flatten the 3-dimensional to a 2-dimensional surface with one to one correspondence between vertices and edges. Their method tried to come as close as possible to a conformal map. Conformal means the angles of the triangles stay the same to the extent possible. These calculations took a few seconds on 2000-5000 atom proteins. Here's my assessment. I think the concept of showing a protein interaction interface and coloring it to show interactions sounds useful for protein- protein interaction people. I think the flattening into 2 dimensions is probably not useful. Conformal maps greatly distort the area of the surface if it has curvature (you've seen the maps where Greenland is bigger than Africa, Americas, Asia and Europe combined). So the flattened surface is going to be hard to recognize as the interface, unless it is already pretty flat. If it is already pretty flat you might as weill just look at the 3-d surface. If we wanted to do something with interface surfaces I would suggest talking to Tanya Korteme. We already have all the infra-structure to create the surfaces. I would not use the Delauney surfaces, instead just use MSMS surfaces on both proteins showing only the parts associated with atoms in one protein that are within 5 angstroms of atoms in the other protein. The zone calculation code I wrote for multiscale could do that fast. We could offer a range of atom colorings that map onto the surface (hydrogen bonds, distance to nearest atom in other protein, charge complementarity, etc...). I don't have time or enough interest to work on this project. But perhaps someone else will. We have talked about collaborating with Tanya Korteme in the past and this would be a good opportunity. Tom

1 0

Re: mdmovie/1508: instantaneous segmentation fault after clicking OK to multiple PDB molecular dynamics movie
by Sabuj Pattanayek 09 Mar '05

09 Mar '05

Hi, Thanks for looking into the problem. It would be nice to be able to read trr/xtc trajectories, but then would you also need to add functionality to read the gro file as well? Perhaps other Chimera users would also find these features useful. Thanks, Sabuj Pattanayek Eric Pettersen wrote: > Hi Sabuj, > I understand the problem now. My code is not expecting the > individual PDB files to have MODEL/ENDMDL records in them (the code is > placing these records around each file as it collates them). The > result is a mess. I will work on making my code more robust in this > regard. > There is a fairly easy workaround for you though: don't give the > -sep flag to trjconv. You will get a single file containing the > frames bracketed by MODEL/ENDMDL records (which is what Chimera would > have had to assemble anyhow), which you can read by using the "single > file" option of the PDB format trajectory reader. One caveat is that > the MD code expects the model numbers to start at 1, not 0, so you > will either have to renumber the MODEL records somehow, or delete > MODEL 0 from the file. I will also work on handling files where the > numbering starts at zero. > Do you work with Gromacs trajectories a lot? If you do, I could > put reading Gromacs trajectories directly on my to-do list. > > --Eric >

1 0

Registration and VRML output for molecules
by Thomas Goddard 09 Mar '05

09 Mar '05

Julio Ortiz asks about registration behind a fire wall, and VRML output for molecules (ribbons, sticks, spheres). Tom ------- Start of forwarded message ------- Date: Wed, 09 Mar 2005 09:09:04 +0100 From: Julio Otiz <ortiz(a)biochem.mpg.de> To: Thomas Goddard <goddard(a)cgl.ucsf.edu> Subject: Registration-VRML-Chimera Hi Thomas: A couple of question: 1) Chimera registration: When I try to register from our institute, behind a firewall, I can not register, I received an error message as there were not internet connection. For my personal computer is not a problem. I can do it from home, but for other computers at the institute, it could be a problem. I would like to update all our versions from chimera, so..how to deal with the registration problem afterwards? 2) VRML export of pdb file representations: As far as I know Chimera can export surfaces of density maps to VRML format. It is possible to export some representation of a pdb files, like ribbons, sphere or sticks also to VRML?. There are some programs that do it, so maybe could be a nice feature to introduce in Chimera (if is not already possible). Greetings, Julio ------- End of forwarded message -------

3 2

Combining ribbons and ball-n-stick using neon
by Todd Weaver 09 Mar '05

09 Mar '05

Dear Chimera- Wondering if there is a way to combine ball-n-stick rendered with neon and displaying distances as dashed lines with ribbons for other parts of the protein. I have attached an image captured with save, all looks good except the distances are not displayed as black lines because it has not gone through neon. If I run neon the ribbons do not show up. I would like to have both in the final image. Warmest regards, TOdd -- Todd M. Weaver, Ph.D. UW-La Crosse 1725 State Street Chemistry Department 4020 Cowley Hall La Crosse, WI 54601 Ph. (608)785-8269 Fax (608)785-8281

3 2

suggestion
by Esther Garcia-Rodriguez 07 Mar '05

07 Mar '05

Hi, I am working with structure superposition and I have noticed that labelling relevant residues when two structures or more are superimposed is a bit of a nightmare. As the labels go to C-alpha in all cases it is very difficult to see anything. I would suggest to allow the user to change the default and be able to establish particular positions for labels, as well as the distance from the relevant atom. For example, label all selected residues in one chain at 0.1 angstroms from the CG atom and all of the second chain at 0.2 (in X or Y). Or maybe just been able to change the minimum distance between labels in all directions. Thanks, Esther Esther Garcia Rodriguez Henry Wellcome Building for Biocatalysis University of Exeter Stocker Road Exeter EX4 4QD United Kingdom

2 1

HELIX/SHEET/CONECT records for non-existent bonds/atoms are being inserted into file.pdb when pdbrun nouser cat > file.pdb is run
by Sabuj Pattanayek 07 Mar '05

07 Mar '05

Hi, If I load a pdb, display only selected atoms/bonds, then do pdbrun nouser cat > file.pdb, the outputted pdb file also has HELIX/SHEET/CONECT records for non-existent bonds/atoms (as if the pdb file in its entirety was written out). Is this a bug or a feature? Is there some way to completely turn off output of HELIX/SHEET/CONECT records? Thanks, Sabuj Pattanayek

2 1

"add-vertex" button volume viewer
by Andrew Jewett 02 Mar '05

02 Mar '05

Please forgive and ignore my earlier post. I should have read the manual first. These features are already implemented. I'm sorry. However there are some user-interface issues... In particular, the method for adding and deleting points to the transfer function that determines voxel opacity and color could be more intuitive. (CTRL-click) This can have a big impact. I suggest putting small add-vertex, cut-vertex buttons near the histogram graph (see attatchment #1). (I stole these icons from xv) The results of using multiple vertices to control colors and or brightness-levels are strikingly better than using just two points. It would be good to make it obvious from the user interface that this option is available. Also, each time the user adds another vertex, a new color should be chosen, not the default white, in order to clue the user that the color can be changed. Similarly, it would be good to explicitly have an "add surface" "delete surface" buttons in solid or mesh mode. (No icon necessary, just write the names out in the buttons themselves itself). So go ahead and leave CTRL-Click in, but add buttons to make it explicit, and make the default color change each time a new vertex (or isosurface) is added. I've played with volume-viewer for quite a while, without realizing these options were available. (RTFM, I know...) And these features are _cool_. For example, attatchment#2 is an image of the same phage-T4 shown in the chimera image gallery using multiple colors. I like it a little better than the static grey image that Steve McQuinn made for the image gallery. http://www.cgl.ucsf.edu/chimera/ImageGallery/entries/phageT4/phageT4c.jpg Again, I apologize for my earlier email. Anyway, cheers Andrew okay, back to work...

2 2

colormap -and- opacity functions for voxels
by Andrew Jewett 01 Mar '05

01 Mar '05

Hi. I've asked a lot of questions, and I keep getting these long thoughtful and technical replies. Thanks. It's nice to get these replies However don't feel obligated to reply at all, at least when I post a question. The other features I mentioned are more important to me at least. I don't want you to be kept busy replying to emails. The question is: why not have a simultaneous independent opacity-map and color-maps for voxel-rendering? (...and I suppose, why do they have to be linear functions? Is piecewise linear hard to implement?) It seems unnecessary that the voxel values should only determine the opacity of the voxel. It seems reasonable to allow the color to be determined by the volxel value in addition to the opacity (for example, a cold-to-warm-to-hot color scheme). It looks like some kind of colormap user interface has been implemented in chimera. (Nice T4-phage slab image, by the way..) Would this be hard? This way, one could distinguish the DNA inside the T4 phage from the within capsid shell. Currently, 3-D volumetric rendering is cool, but it needs ...something. Since the demand for voxel rendering is probably low, I would understand if you choose to delay to ignore these issues. Andrew ------- That's the end of my question, but I included ------- some pictures at the end, for comparison. ------- You can skip this part. ------- They are not in color, but they do look ...pretty. ------- I wonder what they are doing? http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F5 http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F19 http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F13A http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F13B http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F8B http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F16A http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F17 Probably the main reason it looks so nice I think is because their data is manifestly much less bumpy than electron microscopy data. Also I'm suspect that increadibly expensive 3-D hardware doesn't hurt either. However there is something else interesting going on in these pictures. It seems that what appear to be fully opaque objects have a range of brightnesses/colors. In chimera, fully opaque objects are solid white (or blue or whatever color is set by the user) and they have no features except their somewhat fuzzy silhouette. The source of these pictures is a paper published at: http://radiographics.rsnajnls.org/cgi/content/full/19/3/745 One thing they talked about in the article was that they use separate brightness and opacity functions as a function of voxel value. They also use more general piecewise-linear functions instead of linear ones ("percentage classification"). The combination of those two features might explain something. Anyway, I wonder what they are doing. No need to reply. I'd rather you work on other stuff right now. Cheers! Andrew

1 0

per-model-clipping needs "all models" option
by Andrew Jewett 01 Mar '05

01 Mar '05

Hi. Please forgive me for sending this message twice. In the first version, I forgot to include a subject line, so I'm sending it again. --------------- On Fri, 25 Feb 2005, Thomas Goddard wrote: > chimera-users(a)cgl.ucsf.edu When using the Per-Model-Clipping tool and selecting which model to apply the clipping to, there should be an option "All Models", and it should be the default option. Without this feature, some unintended results can happen. Suppose the user generates a surface either with MSMS or multiscale. If the user then uses the menu to select Tools->Graphics->Per-Model-Clipping The default model is the one with the atoms and bonds, not the surface model. When the user moves the clipping plane it will seem like nothing is hapenning. The user has to be quite attentive to realize that they have to select the surface model from the list. It would be better to have an "all models" option that is the default. Thanks Cheers! Andrew

3 4