in silico affinity maturation design

[Anonymous]

Two years ago, Fleishman & Whitehead and their colleagues published on Science a paper about their encouraging work of de novo design new proteins targeting HA. This work was intended to be a general computational method for designing proteins that bind a specific surface patch on a target, while the success ratio was rather low and it was likely there is a long way to go.

So I am curious if there is any progress in this area, is there already some stable/pilot protocols of in silico affinity maturation that can be followed to be applied in similar works?

I found some XML scripts in rosetta_demos/rosetta_scripts/experimental/computational_affinity_maturation_strategy*, but I don’t know if these are what we want.

[Anonymous]

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.

[Anonymous]

Good to know that! I am reading GreedyOptMutationMover.

I wrote one XML script that uses the GreedyOptMutationMover to design the interface residues to get affinity-improved mutants. I hope you can take a look to see if this is reasonable.

The start structure is a complex of a two-chain antigen (chain A and and a two-chain Fab (chain H and L), the structure was prepared by constrained minimization. What I want to do is to design some mutants on several positions on chain H and L which is defined in a resfile.
“FOLD_TREE EDGE 1 110 -1 EDGE 1 111 1 EDGE 111 216 -1 EDGE 1 217 2 EDGE 217 432 -1 EDGE 1 433 3 EDGE 433 650 -1 “
The jump=2 separates the two partners.

In this script:
one customized score function is defined, with h-patch weight.
three task operations are defined: InitializeFromCommandline, ReadResfile to define the mutation set, RestrictToInterfaceVector to define interface residues between A+B and H+L.
several movers are defined: a combined mover “roller” is defined for the relax step after mutation used in GreedyOptMutationMover.
GreedyOptMutationMover takes residues for mutation from ‘resfile’, and then does mutation scanning, and then for the mutant pose:
a) local docking A+B on H+L
b) repack sidechains of interface residues defined in RestrictToInterfaceVector
c) then minimize the backbone and sidechains of interface residues
d) then only minimize the sidechains of interface residues with h-patch weighted score function.

The filter is “ddG”.

[Anonymous]

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.

[Anonymous]

Thanks for your suggestions.
I modified the script according to your comments, see attached.
a task <RestrictToRepacking name=rtrp/> is added to PackRotamersMover and TaskAwareMinMover to make sure only side chain repacking.

Note that I modified DockingProtocol to enable both low-res and high-res docking with “docking_local_refine=0”.

[Anonymous]

after low-Res docking, the program dies with errors:
ERROR: ReturnSidechainMover used with poses of different sequence; aborting
ERROR:: Exit from: src/protocols/simple_moves/ReturnSidechainMover.cc line: 81

[Anonymous]

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.

[Anonymous]

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
}

[Anonymous]

yes, I mean “comma separated”.

[Anonymous]

a very interesting thing is:
if DockingProtocol enables local refinement only (docking_local_refine=1), the program goes well;
if the low-res docking is enabled (docking_local_refine=0), the program dies.

[Anonymous]

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.

[Anonymous]

Very helpful answer,
I am so lucky that I have found this issue by trying unusual option settings.

[Author]

Posts