「view this page in B3 βῆτα server」

Revisions №60945

branch: master 「№60945」
Commited by: Rocco Moretti
GitHub commit link: 「04d3e581085629b0」 「№3770」
Difference from previous tested commit:  code diff
Commit date: 2019-09-24 11:07:52

Merge pull request #3770 from RosettaCommons/roccomoretti/const_restype_split Split ResidueType into separate modifiable and "finalized" classes. Our current ResidueType layout leaves something to be desired. Right now we have an odd prefinalized/finalized state distinction in a single class, with a whole host of duplicated data which may-or-may not be valid based on the (semantic and non-queriable) state of ResidueType. To fix this, I'm splitting the ResidueType into two (three if you count the common base class). The vast majority of usage with be of the (always-finalized) plain ResidueType class, which has the conventional name-and-index implementation, with an internal struct-of-arrays layout. For most people, the interaction with ResidueTypes will be the same. What does change is the interface for people who are modifying ResidueTypes. These people don't work with the plain ResidueType class, but with a new ModResidueType class, which uses VD's (and names) as the primary accessor, with atomic information represented in a graph. (While there is an implicit atom order, accessing by index is highly discouraged in favor of the VD interface, as atoms could be added/deleted at any time, and there isn't necessarily the same bb/sc/hydro order that the plain ResidueType has.) The only way to make a (non-modifiable) ResidueType is through building and converting a ModResidueType. (You can also convert a plain ResidueType back to a ModResidueType for further alteration.) The ResidueType factory function/constructor takes over the function of the (now-removed) finalize() function. (A common base class which stores non-atom-dependent data simplifies things.) This should make working with (Mod)ResidueTypes in their modifiable form easier, as there's less redundant information, and all information there is should all be valid and up-to-date throughout the lifetime. (Versus some data/functions being contingent on being finalized.) A side effect should be that ResidueTypes become slightly smaller (as they no longer have redundant atom information), and that compilation times become shorter because ResidueType no longer has to include the highly-templated boost::graph headers. (These are limited to the ModResidueType class, which is included in many fewer compilation units.)

...