You are here

revert_design_to_native app comparison to FavorNativeResidue mover

4 posts / 0 new
Last post
revert_design_to_native app comparison to FavorNativeResidue mover
#1

Hello,

I am currently designing ligand-binding protiens, but designs are returned with more mutations than I would like. In order to reduce this number, I currently use the revert_design_to_native app, but I recently read about about the FavorNativeResidue mover. However, I am unsure of the differences in function between the two. I made two small sets of designs with the FavorNativeResidue bonus set to 0.5 and 1.5, and I ran revert_design_to_native on those designs with the same thresholds, respectivley. 

i.e. input structure --> design with FavorNativeResdue bonus=n --> revert design with revert_design_to_native threshold=n

I expected that the sequences of each design and its paired revert design would be the exact same since the cutoffs were set to the same value, but they often are not. Is this because the revert_design_to_native app does a ddg calculation and the FavorNativeResidue mover calculates a different metric? The documentation for FavorNativeResidue is not clear on this as it only refers to the cutoff as a "bonus energy."

What is the difference in calculation between the two tools? If there is not one, what could account for the differences I am seeing? Lastly, are there general pros and cons associated with these tools or are there other apps/movers that would be recommended to reduce mutations based on energy?

I have attached my xml protocol below as well as a fasta with a few sequences.

Best,

Nick

AttachmentSize
enzdes_w_favor_native.txt2.03 KB
favor_native_trial.txt3.14 KB
Category: 
Post Situation: 
Wed, 2016-06-29 14:35
nwhoppe

An important thing to note is that the FavorNativeResidue mover doesn't actually do any modification to the sequence. Instead, what it does is add energetic bonuses/penalties ("constraints" in Rosetta parlance) to certain positions. In this case, it adds a bonus to certain positions if they match the identities of the native. It's only on subsequent steps (the EnzRepackMinimize and RotamerTrialsMinMover design movers) where those bonuses are actually applied. So the bonuses are being applied across an entire design run. It's also important to realize that those bonuses are being applied to the total score of the pose - the same score which the design movers are operating over. The binding energy is in there, but the value you're optimizing over isn't just the binding energy.

In contrast, the revert_design_to_native application isn't really doing a design calculation. Instead, it's doing a more iterative trial of each substitution, and then looking at the change of ddg (rather than the total energy) at each position. So it's isolating the effect of ddG, possibly at the detriment of total score & structural stability.  The optimization proceedure is also different, with revert_design_to_native looking at a very limited change, whereas the  protocol you're using with FavorNativeResidue involves much more extensive sampling, including backbone minimization.

So the FavorNativeResidue protocol you have is more for biasing the design to the native while you're coming up with new designs, whereas the revert_design_to_native is intended more as a post-processing step, to take an already produced design and walk it back toward the native.

By the way, instead of using revert_design_to_native, I might suggest the GreedyOptMutationMover (http://dx.doi.org/10.1002/prot.24463) instead. This is set up to do much the same thing as revert_design_to_native (scan and combine point mutations, using an arbitrary metric), but it's RosettaScriptable so you can more finely control how you want various optimization and other considerations set up.

Wed, 2016-06-29 14:57
rmoretti

Hi Rocco,

Thanks for the quick response and for the suggestion! After reading the article you linked and the GreedyOptMutationMover documentation, I have a few follow up questions. For any of my questions, please feel free to point me to a source with the answer. 

  1. I am unsure about implementing the GreedyOptMutationMover since the link to the xml file (EnzScan_w_cst10_greedy_wt25_filt.xml)  from the supporting material is broken.  Would I be correct to put GreedyOptMutationMover after RTdesign in my current xml as this will have it sequentially evaluate the created mutations after design is complete?  Additionally, should I keep FavorNativeResidue in the protocol or is there a way to do the same thing with GreedyOptMutationMover?
  2. The article mentions that GreedyOptMutationMover added mutations in some cases. Is there a way to only let it operate on mutated residues such that no more mutations can be introduced and only existing ones could change? 
  3. I like the ability to descrimiate mutations based on a per-residue ddg with revert_design_to_native. Is there a way I could incoroporate this with GreedyOptMutationMover? So far I have only seen a ddg filter for the binding energy of the protein-ligand complex. If not, how else could I encorporate a structural stability descriminant into the protocol?

 

Lastly, on a slightly different note, I would like to design for specificity towards target ligands in the near future. I was currently thinking of using ligand_dock or a rescore to find a subset of designs which score poorly for the native ligand (or other ligands) but well for one specific target ligand. Could I use GreedyOptMutationMover to screen for mutations that are both favorable for the target ligand and unfavorable for the native ligand or do you know of a different method that could accomplish specificy?

Nick

Wed, 2016-06-29 18:35
nwhoppe

1. The download from http://robetta.bakerlab.org/downloads/ligand_design_benchmarks/MDOBENCH/ works for me. You might have to right-click and "save as" rather than direct clicking. Since it's an XML file, your browser might be trying to display it instead of downloading if you just regular click it.

I'd make sense to put the mover at the very end of the protocol. I probably wouldn't put it in the same file as the design. This is because the GreedyOptMutationMover process takes a fair amount of time, and it doesn't make sense to run it on everything. I'd only run it on the best structures, after you apply your post-design filtering criteria. 

I'd certainly keep the FavorNativeResidue in the design protocol. This would keep the design from going too far off the native path, and thus reduce the number of reversions you'd need to do after the fact.

2. It depends on how you have your TaskOperations set up. The default setup is for refinement, and uses a TaskOperation which considers all mutations. If you want to limit which mutations you consider, you can use a more restrictive set of TaskOperations. At the extreme, you can limit it just to those mutations/positions which differ from the native. This is what the JointSequence TaskOperation was written to do. Use it instead of the DetectProteinLigandInterface operation in the example.

3. GreedyOptMutationMover will do the rescoring over whatever filter metric you provide to it. The example XML is set up for a combination of total score and shape complementarity, but you can certainly switch out the total_SC filter for something else. Like the example total_ligint filter for a combination of total score and interface energy (I might recommend this) or you could go with just the interface energy. (But I wouldn't use the LigIntE directly, as that wouldn't incorporate any of the residue_type_cst scores from the FavorSequenceProfile/FavorNativeResidue added constraint. I'd do a sum of LigIntE and resid instead.) If you wanted to use the ddG filter instead of the LigInterfaceEnergy filter (e.g. if you wanted apo repacking), you could do that as well. 

The key to GreedyOptMutationMover is that you need to be able to make a filter which calculates a metric which you're interested in optimizing over. The trick in your specificity scenario is to get a filter which can calculate the energy on the alternate target. You might be able to put something together with the RelativePose filter, but this isn't really something that's been extensively tested. You might be better off with post-processing scripts, or one of the other multistate design protocols.

Tue, 2016-07-12 09:30
rmoretti