MantisBT - Rosetta
View Issue Details
0000341Rosetta[All Projects] Bad Codingpublic2014-06-24 16:292014-06-24 16:30
rmoretti 
 
normalminoralways
newopen 
 
 
na
na
0000341: Too many add_cutpoint/chainbreak_variants functions
As mentioned by Justin in bug 0000336, we have a number of different "add chainbreak variants to pose" functions:

core::pose::correctly_add_cutpoint_variants
protocols::forge::methods::add_cutpoint_variants
protocols::loops::loops_main::add_cutpoint_variants
protocols::abinitio::add_chainbreak_variants
protocols::environment::add_chainbreak_variants
protocols::topology_broker::add_chainbreak_variants

These functions (and any corresponding remove_* or has_* functions), should likely be consolidated.
For preference, I'd say that we should consolidate under the core::pose namespace, as adding the cutpoints is a general pose manipulation.

Once successfully accomplished, the function probably should be renamed to just "add_cutpoint_variants". (We can't do that just yet, due to Koenig lookup issues.)

Complications noticed so far is how to normalize differences in error handling - e.g. what if a location isn't a chainbreak in the fold tree? Do you raise an error or silently pass? How about if they're already an incompatible termini ending - again raise an error or pass silently.

Another issue is side manipulations: The protocols::loops version does constraint remapping. That should probably be added to the centralized version, but I'm thinking we might instead want to make that a more general property of adding/removing variant types. That is, have the pose introspect about residue type changes and update associated data appropriately.
No tags attached.
related to 0000336resolved rmoretti core::util::add_cutpoint_variants() and remove_cutpoint_variants() take raw pointers 
Issue History
2014-06-24 16:29rmorettiNew Issue
2014-06-24 16:30rmorettiRelationship addedrelated to 0000336

There are no notes attached to this issue.