MantisBT - Rosetta | ||||||||||
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 | |||||
Reporter | rmoretti | |||||||||
Assigned To | ||||||||||
Priority | normal | Severity | minor | Reproducibility | always | |||||
Status | new | Resolution | open | |||||||
Platform | OS | OS Version | ||||||||
Product Version | ||||||||||
Fixed in Version | ||||||||||
Application(s) Affected | na | |||||||||
Command Line Used | na | |||||||||
Developer Options | ||||||||||
Fixed in SVN 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: 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. | |||||||||
Steps To Reproduce | ||||||||||
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. | |||||||||
Relationships |
| |||||||||
Attached Files | ||||||||||
Issue History | ||||||||||
Date Modified | Username | Field | Change | |||||||
2014-06-24 16:29 | rmoretti | New Issue | ||||||||
2014-06-24 16:30 | rmoretti | Relationship added | related to 0000336 |
There are no notes attached to this issue. |