Changes between Version 2 and Version 3 of Architecture

Timestamp:

Jun 22, 2009, 4:54:04 PM (17 years ago)

Author:

goddard

Comment:

--

Architecture

@@ -7 +7 @@
  1. 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
  1. 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
+ 1. 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
+ 1. 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