Architecture and Implementation Issues

1. Use numpy for vector, point, transform, bounding box, coordinate set data types. Our current home-brewed Vector, Point, and Xform classes are a significant obstacle to implementing geometric calculations. The Chimera volume data code is littered with conversions back and forth between these undernourished data types and the much more usable numpy arrays. TG
2. Use SWIG to make Python wrappers for C++ code. Our current home-brewed WrapPy seems to require maintenance for every new Python version. WrapPy does not support numpy array arguments which are used throughout the volume data C++ code. SWIG is well-maintained and the industry standard and it does not make sense for us to duplicate that work. TG
3. Don't auto-generate molecular data classes with OTF. Our current auto-generated molecule classes introduce unnecessary difficulty in maintaining and enhancing those data structures. Those classes should be directly hand-written. The OTF appears to be historical baggage. TG
4. Many GUI features have no command equivalent. This impairs movie making and scripting to process large numbers of models. May want to establish a protocol that no new feature goes into a production release without a command interface? TG
5. Separate _chimera C++ library into a molecule library and a 3d viewer library (Camera, viewer, side view, lights, opengl management, colors). More modularity will help code quality and faster code modification/testing cycle. TG
6. Code in Python unless C++ is needed for speed. I think much Chimera C++ code (almost all) would be easier to enhance, maintain, and debug if it were instead written in Python. The only code that belongs in C++ is code that requires high speed (and can't be done adequately in numpy) or that is called by other C++ code. The (trivial) examples that brought this to mind are eigenMatrix(), RMSD_fillMatrix(), RMSD_matrix() in _chimera. The entire opengl viewer/camera framework currently in _chimera could probably be in Python. TG
7. Molecular surface use is limited. Each atom can only have one molecular surface associated with it. For instance, making a surface for chain A, one for chain B and one for the atoms of chain A and B to examine buried surface area is not possible. Each atom can belong to just one "surface category" and each molecular surface is created from a category. It is also cumbersome to redefine the surface categories from the default ones (main, ligand, solvent). The constrained possibilities for molecular surfaces complicate simple problems like looking at electrostatic potential on the interface between two chains. Allowing multiple molecular surfaces would seem to be conceptually simple and more useful. Current implementation with surface color, opacity, and display attributes attached to atoms instead of the surface would need to be changed. Also current practice of using the same model id number for molecules and their surfaces would make referring to different surfaces in commands problematic. TG
8. Many operations impose arbitrary requirements on how atoms are grouped. For example a sequence based structure alignment can be done on two separate "molecules", but not on two separate "chains" without first partitioning the chains into separate molecules objects. Fitting two molecules into a density map with distinct rigid motions can be done but two chains of a single molecule cannot be moved independently by the fit-in-map tool. In other cases two chains would be needed instead of two molecules. For instance, a single molecular surface can be computed bounding two chains, but not two molecules. These use restrictions are caused by implementation details such as molecules being positioned by transformation matrices while chains are positioned by individual atom coordinates, and also by graphical user interface design such as a menu that only allows choosing chains. TG