Molecular Data Master Ticket

[Tom Goddard]

The molecule data structures include the primary data read from a PDB or mmCIF file like atom names and coordinates, residue names and numbers, chain identifiers, biological unit information. I think we should also consider display state as part of this molecule data project. In Chimera 1 we do not separate the primary data from the display state in the C++ objects. Whether an atom is displayed, its color, is display style (sphere, ball, stick cap, dot), whether a ribbon is shown for each residue, ..., all these display attributes are mixed in the same data structures with the primary data such as atom coordinates and names. This contrasts with density map data where the primary data is in one object (Grid_Data) and the display state is a subclassed object (Volume). I think that we should continue to keep display state and primary data for molecules in the same C++ and Python objects. Unlike the case of density maps, molecule data forms a tree (molecule / chains / residue / atom+bond) and it is much more cumbersome to attach display state layered on top of the primary data as it requires subclasses for all levels of the tree. For this reason I think the molecule display state should be treated as part of this "molecule data" project rather than part of the molecular viewer project. The molecular viewer project will handle the actual rendering of the molecule using the primary and display state data.

[Eric Pettersen]

I made Atom and Bond inherit from base classes (BaseSphere and Connection) that I'm hoping such graphical data will go into, with the goal of not having to use fake atoms and bonds in Chimera 2 due to the limitations of the alternatives. Similarly, selection-related info would go there too.

[Eric Pettersen]

Conversely, I think the graphical data can directly mix into Residues, since I don't envision us offering ribbon depictions for non-atomic Spheres/Connections.

This conversation made me realize that I need to make AtomicStructure inherit from a base class that contains Spheres/Connections so that graphical data can go into that base class.

[Greg Couch]

Need an official API for C++ extensions that import and/or export other 
formats to use.  In particular, the connect_structure function hidden in 
PDBio.cpp and anything it requires should be split out. graphical data 
can go into that base class

[Eric Pettersen]

On May 7, 2014, at 2:11 PM, Chimera2 <chimera2-bugs-admin@cgl.ucsf.edu> wrote:


Hmm, I guess I can put the split-out on my increasing-by-the-day to-do list.  Does mmCIF have the equivalent of MODRES records?  For instance, in entry 4KDN, residue 169.A is a glycosylated asparagine that nonetheless has the standard asparagine code of ASN in the PDB entry.  Therefore there is a MODRES record for it in the PDB entry.  Is there any equivalent in mmCIF?  A list of MODRES residues is one of the inputs to connect_structure (so it know not to use a connectivity template despite the standard name).  It looks like ASN is also the name of the residue in the 4KDN mmCIF entry, but I don't see anything like a MODRES record, but maybe I'm not looking for the right thing…

--Eric

[Greg Couch]

There a pdbx_struct_mod_residue category that looks like it might work.

     -- Greg

[Eric Pettersen]

As mentioned in Sequence Data ticket (#26), am implementing pseudobond groups. Am also largely replacing std::map with std::unordered_map, except for Bonds in Atoms, where I'm using a custom VectorMap.

[Eric Pettersen]

Converted from std::map to std::unordered_map where appropriate for improved efficiency. Converted Atom::Bonds to custom VectorMap more space and time efficiency. The latter may need further work once we get far enough along to benchmark real world usage.

[Eric Pettersen]

Made MODRES records update the 3-to-1 letter map