in silico affinity maturation design

Those would be good scripts to look into, but there’s been some recent effort in use the GreedyOptMutationMover (https://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/Movers_%28RosettaScripts%29#GreedyOptMutationMover) to do all-at-once optimization, rather than using FilterScan to output a resfile followed by packer-based or Monte-Carlo based optimization. (It produces good results for much less runtime.)

Basically, the concept is to set up a filter or filters which embody your optimization criteria, a mover which embodied what sort of post-mutation relaxation you want to do, and task operations to specify which residues you want to mutate and then run either FilterScan or GreedyOpt to do the comprehensive point mutation scan. GreedyOpt then automatically does a greedy (best mutation first) combination of the mutations, and FilterScan outputs a resfile which you can use in the same or other XML file as input to either the packer, or to a GenericMonteCarlo mover to make a RandomMutation from the resfile, followed by the relaxation, followed by the evaulation with your filters.

That’s the main technical aspect of things. There’s still a bit of work trying to figure out what the best combination of filters and relaxation are for maturation, but that may be a bit system dependent, and there isn’t a clear recommendation.

In your relax protocol you need to be careful with any packing operations, as the default packing behavior is to redesign. I’d recommend to add a RestrictToRepacking operation to all the relax mover task operations, otherwise the filter might not be operating over the sequence you thought it would be.

The other thing would be to be careful about which jumps control which chains – both in minimization and in the interface definition. Especially with the DockingProtocol mover liekly changing the foldtree. I’d recommend using the dump_pdb option with a reduced resfile to check that you’re moving just the things you think are moving.

Other than that, things look reasonable. Just check the output (including the tracer output) to make sure you’re getting things that make sense.

One thing to point out – the taskoperations options are conventionally comma seperated. e.g. task_operations=”rtrp,inter”

I’ve never tried space separated, but my guess is that it wouldn’t do what you expect it to do.

It looks like the DockingProtocol mover stores the first structure it encounters, and assumes the structure will be the same for all subsequent calls. So if you change the structure between calls, it’s going to error out. There’s no way around it with options, but if you’re willing to recompile, I believe (but have not tested) that a quick fix would be to go into rosetta_source/src/protocols/docking/DockingProtocol.cc, and in the apply function around line 888 or so change


if ( previous_sequence_.compare( pose.sequence() ) != 0 ){
first_apply_with_current_setup_ = true;
previous_sequence_ = pose.sequence();
}

To


if ( previous_sequence_.compare( pose.sequence() ) != 0 ){
first_apply_with_current_setup_ = true;
previous_sequence_ = pose.sequence();
set_input_pose( new core::pose::Pose( pose ) ); // Add this line
}

Right. If you’re only doing local refinement, you never go through the centroid stage, so you never have to recover the sidechain positions. (Because you never lose them in a fullatom-to-centroid transition.) As the input pose is really only used during the recover sidechains operation, if you’re only doing the fullatom-mode-only local refinement you never look at the stale input pose and thus never realize that it contains the incorrect sequence.