You are here

the ddg of mutant is same as the wt

7 posts / 0 new
Last post
the ddg of mutant is same as the wt

I am trying to find the ddg for my mutant protein-protein complex using the resetta script in calculate_protein_protein_ddg application. I have done it with -ntruct 5 and all of them gave the same values. But I am getting the same value for both the mutant and the WT.I am not sure what's wrong.Can anyone suggest something if they have an idea?


I am uploading my PDB and the score file. Chain A and B represent the 2 protein in the heterodimer respectively.It also has heteroatoms at the end.

score.txt3.42 KB
4apx.pdb339.98 KB
Post Situation: 
Wed, 2015-03-04 11:56


Which residue looks to be iso-energetic? I've never used the calculate_protein_protein_ddg app, but perhaps there is something missing in your RosettaScript? Can you post that?

Thu, 2015-03-12 09:15

I am attaching my rosetta script.Actually, I mutated the residues which significantly increase the Kd of the complex(experimentally shown) .But rosetta predicts ddG values to be the same for those mutants as the WT.

File attachments: 
Sun, 2015-03-15 08:45

The score in the scorefile output is not quite what you're thinking it is. The values for the filters in the scorefile are re-evaluated for the *output* pose. So the fact that you get the same score for dg_wt and dg_mut is not surprising, as the values are both being evaluated on the post-mutation structure, rather than on different structures. You'll need to look at the tracer output to see what the value is at the time it is applied.

Another thing you may want to look into is using the ddG mover instead of the ddG filter - this has the ability to attach the when-run values to the output pose.

Wed, 2015-03-25 12:41

Thanks for your reply rmoretti! I changed my script as per your suggestion.Now, I'm using the ddG mover instead of the ddG filter. But still I'm not satisfied with the results. I looked at the predicted "Sum ddg" values in the log file for the WT and mutant and they don't seem to agree with my experimental data. Actually, I had expected a significant difference in those values(magnitude of mutant's ddg value to be lower) which wasn't there. I am attaching my new script and log file.
I don't know if there is something wrong in my pdb file as I have some Ca2+ ions and don't know if they are causing any issues.
I look forward to your new thought about this.


File attachments: 
Sun, 2015-03-29 13:48

I am still waiting for a reply.

Mon, 2015-04-06 18:05


So there are a few things I would suggest. First, you are relaxing WT, then packing, then designing in your mutant, and then using ddg.
When you relax the structure first, you are essentially trapping it in the WT conformation. Most forced mutants after a relax will probably be not good unless you use Rocco's pareto optimal relax ( ), which will only slightly perturb the structure and get it into the Rosetta energy function. Is your resfile forcing the mutant?

I would try two things first and remove the pack step after the relax. It is unnecessary and actually probably Increases the energy. Your structure is packed rigorously during the relax. Also, why are you using score12?


1) Repeat your script with the pareto optimal flags on. They are explicit and easy to find in the paper. That way your WT and Mut will be actually comparable.

2) This is more complicated. Instead of the pareto optimal flags, you run a full relax on the WT. Use ddg_calc. Then you use the LoadPDB mover ( or the SavePoseMover ( to reload your native pose/replace the current pose with your WT. Then run your mutation, then run the full relax, and then your calc_dg.

So, to summarize 2:
-relax wt
-set wt info using calc_dg
-load unrelaxed wt with SPM or LoadPDB
-relax mutant

I'm not sure which would work better, but its worth a shot. The second protocol won't work if ddG mover does not save a copy of the data. I tried to find the actual C++ code that is being called to double check this would work, but I couldn't find it. If protocol 2 shows no difference, than this is probably the case.

Good luck!


Tue, 2015-04-07 10:50