MantisBT - Rosetta
View Issue Details
0000160Rosetta[All Projects] Bad Codingpublic2012-12-10 09:542012-12-10 13:18
All platformsAnyAny
fixbb in particular, but packing in general; enzdes and RosettaScripts are exempt
fixbb -favor_native_res is legal but useless
Feature Request
0000160: Generalize "favor native residue" support

It would be nice if we had a generalized favor_native_residue support, or at least a version that works for fixbb. The existing Mover for the purpose, FavorNativeResiduePreCycle, works _only_ with RosettaScripts and not in isolation. There is a FavorNativeResidue class, and the ResidueTypeConstraint is easy to use in isolation, but it is moderately nontrivial to synchronize these with the fixbb/JD2 paradigm of "no pose until apply" and the necessary scorefunction sharing.

What would be really nice would be if this worked from resfile. That would require the packer to add/remove constraints (PackerTask can't because it doesn't see the pose at its application time), which might be breaking encapsulation.
No tags attached.
child of 0000161new  Fixbb really should have a protocol-level mover 
Issue History
2012-12-10 09:54smlewisNew Issue
2012-12-10 13:18smlewisNote Added: 0000132
2012-12-10 13:18smlewisRelationship addedrelated to 0000161
2012-12-10 13:18smlewisRelationship replacedchild of 0000161

2012-12-10 13:18   
Here is a code snippet that would work if we fixed 0000161 first:

#include <core/scoring/constraints/ResidueTypeConstraint.hh>
basic::options::RealOptionKey const fav_nat_bonus("fav_nat_bonus");

for ( Size i=1; i<= pose.total_residue(); ++i ) {
        pose.add_constraint( new ResidueTypeConstraint( pose, i,
basic::options::option[fav_nat_bonus].value()) );
//might want to check is_protein
scorefxn->set_weight( res_type_constraint, 1.0 );

option.add( fav_nat_bonus, "favor native residue" ).def(1.5);