Visualizing and Discriminating Atom Intersections Within the Spiegel Visualization Framework

Transcription

1 Visualizing and Discriminating Atom Intersections Within the Spiegel Visualization Framework Ian McIntosh May 19, 2006

2 Contents Abstract. 3 Overview 1.1 Spiegel Atom Intersections... 3 Intersections 2.1 Visual Metrics Results. 5 Amino Acids 3.1 Overview Extraction Intersections Visualization 6 Bond Visualization 4.1 Objective Results. 8 Picking 5.1 Objective Results. 9 Conclusions 6.1 Spiegel Unresolved Issues 11 Future Work 7.1 Bonding Rules Point-and-Show

3 List of Figures 1 Basic Spiegel Pipeline Intersections Shown with Size & Color. 4 3 Acid Pipeline Plan Intersection Visualization with Backbone Rules 6 5 Amino Acid Visualization Non-Acid Member Visualization 7 7 A Ball & Stick Model in Spiegel 8 8 Ambiguous Intersection Spheres 9 9 Circular Atom Pick Pipeline Complex & Confusing Pipeline. 11 2

4 Abstract Overview Spiegel is a pipeline structured visualization framework used to build three dimensional scenes. It can be used to visualize anything from galaxies of stars to atomic structures. Spiegel was used for this project to investigate atom intersections occurring when building models from Protein Data Bank files. New bonding rules were created to accurately show these intersections and visual metrics such as size, color and shape were used in plotting overlaps in three dimensional space. Bonds were also shown as cylindrical connectors that created traditional ball-and-stick models. Methods of selecting specific elements of the three dimensional structure were also investigated to provide a tool for examining the intersections in a visual context. Significant progress was made in creating meaningful visual representations of atomic overlaps but there remain areas to continue work. More time must be spent developing algorithms that accurately follow known atomic bonding rules so that intersections in the three dimensional representations can be validated or examined further. The ability to click on atoms in the visualization and show information about it also proved unsuccessful in the short term, but has shows potential to be fully implemented and useful in the process of intersection discrimination. 1.1 Spiegel The Spiegel Visualization Framework [gra] was used to construct the visualizations of the atom structures. It uses a pipeline structure that encourages the building of small functions that can be connected together to create more powerful programs (Figure 1). This architecture made it easy to extend the existing work done on this topic as well as combine existent functions with new ones to provide greater functionality. Figure 1 - Basic Spiegel Pipeline 1.2 Atom Intersections A previous study [sco] was done on atom intersections resulting from building three dimensional models from Protein Data Bank Files (PDB). Initially it was 3

5 Intersections thought that there would be no intersections in the models since it s physically impossible for any two atoms to occupy the same space at the same time. Upon examination though, many intersections were found (~1700). No conclusive reasoning was found for this. This project was aimed at exploring these occurrences further and developing some explanations. If some valid reasons for the intersections can be determined, then an algorithm can be developed to create more realistic atom structures. 2.1 Visual Metrics The first step was to get a better sense of the nature of the intersections. At the time, intersections were shown via spheres of equal size at the point of the overlap. It was decided that it would be more helpful to know the size of these intersections. The magnitude of the overlap could be visualized with different sized spheres depending on the volume of the intersection. This was accomplished fairly easily thanks to the BoundingSphere class method intersect( ). The method examines the overlap between two spheres and assigns a new BoundingSphere to a position at the center of the intersection with a diameter equal to that of the greatest diameter achieved in the intersection. These spheres could then be visualized to show the size of the intersection. In addition to size, color was also added in to show the magnitude of the intersection. The color of the sphere ranges from green to orange as the size of the intersection increases (Figure 2). This made it easier to find the larger intersections in the atom structure. Figure 2 - Intersections Shown with Size & Color Lastly, the intersections can be shown as a variety of shapes. By supplying a String parameter to the intersection visual function, an intersection can be 4

6 shown as a sphere, cylinder, cube or cone. This feature has proved to be limited in its usefulness. 2.2 Results With this additional functionality in place the domain expert, Paul Craig, was consulted. He emphasized the necessity to discriminate valid bonds from invalid bonds in the structure. The structure we were examining contained a series of amino acids and it was decided that the next step would be to extract these acids as groups of atoms rather than extract each atom individually. Having the correct amino acid information would make it easier to begin validating any intersections. Amino Acids 3.1 Overview The first suggestion made was to consider all bonds within an amino acid valid. Since the atoms are members of the same amino acid, it s reasonable that they intersect each other. Another bonding rule concerning inter-acid bonding was defined that deals with the protein backbone. A plan was developed that would create useful acid-based visualizations and adhere to the Spiegel pipeline architecture. Because the process of creating these visualizations would be very similar to visualizing atoms, similar program architecture was chosen (Figure 3). Figure 3 - Acid Pipeline Plan 3.2 Acid Extraction Before the acid intersections could be examined, a new way of extracting atoms from a PDB file needed to be created. This was not very difficult with the existing atom extractor. The major difference was that the atoms needed to be grouped according to each atom s residue name. The standardization of PDB files made it easy to systematically read the amino acid member and then wrap them into the AminoAcid class. Based on the PDB file format [pdb], each common amino acid could be statically defined to create a library to reference when reading a sequence of atoms. There were also atom entries in the file that were not members of a common amino acid like the DNA atoms of the protein. The extractor parses 5

7 these from the file and can pass them along in the same way the atom extractor does. This allows for visualizations of either set of atoms or of both sets. 3.3 Intersections Intra-acid intersections were considered valid because of the possible existence of different bonds between the amino acid members. There was also an additional inter-acid bond that was validated. Acids bond together via two particular particles that when traced, form the backbone of the protein. By examining the names of inter-acid intersections these intersections were ignored and the total number of intersections was reduced by ~15%. An interesting aspect of this reduction was the noticeably smaller amount of orange shaded spheres in the intersection visualization. This might suggest that the remaining intersections are, in general, less severe (Figure 4). Figure 4 - Intersection Visualization with Backbone Rules 3.4 Visualization To visualize the amino acids, each type of acid was statically assigned a particular color (i.e. all atoms of this acid would have this color). This makes it easier to differentiate between the amino acids in the visualization and also helps show that all of the same colored atoms share membership in the acid. In the future, it would be helpful to have some kind of onscreen color legend that will show what colors represent which amino acids. Not all atom entries in a PDB file necessarily belong to an amino acid. The next step was to extend the amino acid extractor so that it could create a series of amino acids from the PDB file as well as a map of the non-acid members. This was easily added by examining the atom entry and extracting it by itself like an 6

8 atom or as a member of an acid based on whether the residue name associated with the atom entry matched any of the known common amino acids. The ability to extract both acid and non-acid members made it much easier to visualize both sets of file entries (Figures 5 & 6). Figure 5 - Amino Acid Visualization Figure 6 - Non-Acid Member Visualization For the particular protein being shown, most of the non-acid members were also atoms in the DNA. This could clearly be seen in the visualization s double helix structure. Now the task of examining inter-acid intersections could be addressed and it turned out to be relatively simple to modify the AminoAcid wrapper class so that it could fit into the previously designed intersection visualization function (Section 2.1). By looking at the atoms and comparing their properties with the known bonding rules supplied by Paul Craig, each intersection could be validated or invalidated. The visualization itself had changed little, as the same component was used for both atom and amino acid intersections. Having these intersections on the screen was helpful but to make the information a little more accessible a look-at feature was added to the Acid3D visual function. Acid3D now takes a double input parameter as an atom identification number. When cycling through the incoming atoms, each atom ID is examined and if it matches the atom ID parameter, a new look-at point is set to that atoms location in space and can be passed out to a camera. The camera will then take that point and set its center point to match it. In the future, combining this look-at ability with graspable and zoomable visualization will provide much better tools to examine each intersection. Bond Visualization 4.1 Objective 7

9 It was decided that it would be nice to be able to model an atom structure with the traditional ball-and-stick technique that shows atoms as spheres and bonds as sticks connected at either end to the bonded atoms. In Spiegel, the atoms were already being shown as spheres but this model has some limitations in its ability to show what s really going on in the protein structure. 4.2 Results This was accomplished by creating a new class, AtomBondDescriptor that accepts two three dimensional points. These points are considered to be the centers of the atoms that are bonded. The descriptor class then creates a transformation based on the two supplied points that can be applied to a Cylinder shape so that the cylinder will start at one point and end at the second. When these cylinders are superimposed with the atoms visualized as spheres, a familiar ball-and-stick model is created (Figure 7). Figure 7 - A Ball & Stick Model in Spiegel In this model a new AtomBondDescriptor object is created for each invalid intersection. This explains the high number of cylinders in the model. When comparing this model with the previous where intersections were visualized as spheres, this method seems preferable. The major reasons for this are the familiarity of the ball-and-stick method and the fact that showing the bonds as spheres sometimes results in strangely placed spheres that are more confusing than explanatory (Figure 8). In cases where the two atoms don t actually intersect in the visualization (due to scaling) the intersection spheres seem to hang in limbo. The cylinders are clearer in their definition because they are guaranteed to connect the two intersecting atoms and in the future can be extended to vary in color and shape according to the magnitude of the intersection. They also have the added 8

10 benefit of being cylinders as opposed to spheres which reduces confusion between intersections and atoms. Figure 8 - Ambiguous Intersection Spheres Picking 5.1 Objective With a more realistic structure visualization in place, new ways to improve it were discussed. Being able to click on various components in the visualization sounded like a nice feature to add. Having a ball and stick model was nice but due to the number of atoms that can exist in a PDB file there s no real way to know what spheres correspond to which atom definition in the file. If this kind of tool could be added, it would make the process of investigating intersections exponentially easier by eliminating the need to consult the original PDB file after the visualization has been created. 5.2 Results Strategies to implement a click-and-show interface, where information about visual objects can be displayed, were investigated and Java3D has a series of classes designed for this task. PickCanvas is a utility class that provides the ability to pick an object from a canvas based on a supplied shape. Any objects that intersect this shape can be determined and selected based on their properties. For the purposes of an atom click-and-show interface, a PickRay is the best choice. When a click is registered, the PickRay translates the two dimensional coordinates into a three dimensional ray that is then projected through the atom structure on the canvas. The closest object from the eye position that intersects the ray is chosen. Once the object is chosen, the camera function must be abandoned since it has no knowledge of what it s visualizing; only the object types in the BranchGroup that are part of the scene and their positions. The bounds of the selected object are then passed back to the Atoms3D function. By comparing the 9

11 bounds of the selected object with the PdbAtom objects that it s building spheres out of, the atom information can be extracted and shown. In practice however, this method of object picking has shown only moderate success. The first issue is the circular nature of the pipeline since the Atom3D function must send a BranchGroup of atom Spheres to the camera and then the camera must send a set of Bounds back to the Atom3D function (Figure 9). This process needs to be refined and implemented similar to the way a GripArm and GripImage operate on a camera. Figure 9 - Circular Atom Pick Pipeline Conclusions The second issue is the reliability of the object picking. Clicking a sphere onscreen does not always lead to a picked object. Additionally, sometimes the intended object is not selected, such as the case when clicking an atom sphere and actually picking a bond cylinder instead, and vice versa. For this click-and-show interface to offer any value, the causes for these discrepancies must be determined and corrected. 6.1 Spiegel For the purposes of this project, Spiegel has shown that it is easily extensible and supports a wide variety of capabilities. The previous work done by Ed Dale provided an excellent starting point for examining the atom intersections and the pipeline structure was responsible for the amount of work accomplished in a relatively small amount of time. The one flaw in Spiegel that was uncovered during this project was its Graphical Programming Environment limitation. In order to really examine the atom intersections, there were quite a few visualizations that needed to be constructed in the same program so that all of the data could be seen simultaneously. This led to more complex programs that required many different functions to be pieced together. The resulting script was large and complex and the GPE doesn t draw the program architecture very well (Figure 10). 10

12 Figure 10 - Complex & Confusing Pipeline With this pipeline illustration, the value of the GPE is lost since it become virtually impossible to see the flow of data from one segment to another and extremely tedious to add more components in the right places for an additional function. A more intelligent GPE should be investigated to avoid these kinds of situations and create clearer pipeline visualizations. 6.2 Unresolved Intersections While some new information has been yielded from this project there are still problems to address in terms of atom intersections. More tools have been created to resolve these unexplained overlaps but the true nature of the majority of the intersections has not been solved. Future Work 7.1 Bonding Rules The first area to pursue should be developing a more refined set of bonding rules that can discriminate valid intersections from invalid intersections. During this project one import rule was incorporated into the intersection visualization framework but until all rules are defined and implemented, the atom intersections are of very limited value. Domain expert consultation should be sought and turned into a more detailed algorithm that will produce accurate atomic structures. 7.2 Click-and-Show At this point, the intersection visualizations developed only show that intersections exist in the structures defined in the PDB files. Implementing a click-and-show interface will provide a substantial improvement to these models. Coupled with a larger set of bonding rules, this tool will allow for an easy way to examine unexplained intersections. 11

13 References [gra] The grape cluster project. [pdb] Protein Data Bank Atomic Coordinate and Bibliographic Entry Format Description. February [sco] The website of Edward Dale. study. 12