Anonymous | Login | 2023-02-02 11:46 CST | ![]() |
My View | View Issues |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
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 | |||||||||||||
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. | ||||||||||||
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. | ||||||||||||
Application(s) Affected | na | ||||||||||||
Command Line Used | na | ||||||||||||
Developer Options | |||||||||||||
Fixed in SVN Version | |||||||||||||
Attached Files | |||||||||||||
![]() |
||||||
|
![]() |
|||
Date Modified | Username | Field | Change |
2014-06-24 16:29 | rmoretti | New Issue | |
2014-06-24 16:30 | rmoretti | Relationship added | related to 0000336 |
Copyright © 2000 - 2012 MantisBT Group |