|Anonymous | Login||2023-09-24 21:23 CDT|
|My View | View Issues|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000341||Rosetta||[All Projects] Bad Coding||public||2014-06-24 16:29||2014-06-24 16:30|
|Fixed in Version|
|Summary||0000341: Too many add_cutpoint/chainbreak_variants functions|
|Description||As mentioned by Justin in bug 0000336, we have a number of different "add chainbreak variants to pose" functions:|
These functions (and any corresponding remove_* or has_* functions), should likely be consolidated.
|Additional Information||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.
|Tags||No tags attached.|
|Command Line Used||na|
|Fixed in SVN Version|
|2014-06-24 16:29||rmoretti||New Issue|
|2014-06-24 16:30||rmoretti||Relationship added||related to 0000336|
|Copyright © 2000 - 2012 MantisBT Group|