ddG filter gives deltaG calculation number?

[Anonymous]

Hi,

I used attached “design2.xml” to design interface of Ag-Fab complex (see my previous thread). A “ddG” filter was used in the design script to calculate ddG of mutant.
After the required mutants were dumped out into PDBs, I used another very simple script (attached “ddg.xml”) with just only one “ddG” filter to calculate ddG for each output PDB. When I was checking the log file, I found the ddG values calculated by two scripts are different.

For example, for the structure decoy des5xxxx_0005,

its ddG reported in log file of “design2.xml” is about -27:

protocols.simple_filters.DdgFilter:

---

Scores Wghtd.Score

---

fa_atr -31.914
fa_rep 2.873
fa_sol 10.251
fa_intra_rep -0.002
fa_pair -1.793
hbond_sr_bb 0.000
hbond_lr_bb -0.021
hbond_bb_sc -5.270
hbond_sc -1.988
dslf_ss_dst 0.000
dslf_cs_ang 0.000
dslf_ss_dih 0.000
dslf_ca_dih 0.000
rama 0.000
omega 0.000
fa_dun 0.555
p_aa_pp 0.000
ref 0.000

---

Sum ddg: -27.3098
protocols.rosetta_scripts.ParsedProtocol.REPORT: ddg -27.3098
============End report for ddG_binding==================
protocols.rosetta_scripts.ParsedProtocol.REPORT: ============Begin report for sasa==================
protocols.moves.RigidBodyMover: Translate: Jump (before): RT 0.444934 -0.854746 0.267286 0.0281422 -0.284964 -0.958125 0.895121 0.433825 -0.102736 47.3926 6.81371 0.854232
protocols.moves.RigidBodyMover: Translate: Jump (after): RT 0.444934 -0.854746 0.267286 0.0281422 -0.284964 -0.958125 0.895121 0.433825 -0.102736 904.898 477.211 -207.497
protocols.rosetta_scripts.ParsedProtocol.REPORT: Sasa= 1514.21
============End report for sasa==================
core.scoring.ScoreFunctionFactory: SCOREFUNCTION: standard
core.scoring.ScoreFunctionFactory: SCOREFUNCTION PATCH: score12
protocols.jd2.JobDistributor: des5xxxx_0005 reported success in 23756 seconds

But it is reported as about -70 in log file of “ddg.xml”:

protocols.simple_filters.DdgFilter:

---

Scores Wghtd.Score

---

fa_atr -104.726
fa_rep 13.659
fa_sol 45.538
fa_intra_rep 0.015
fa_pair -5.928
hbond_sr_bb 0.000
hbond_lr_bb -0.021
hbond_bb_sc -12.158
hbond_sc -11.771
dslf_ss_dst 0.000
dslf_cs_ang 0.000
dslf_ss_dih 0.000
dslf_ca_dih 0.000
rama 0.000
omega 0.000
fa_dun 6.792
p_aa_pp 0.000
ref 0.000

---

Sum ddg: -68.6011
protocols.rosetta_scripts.ParsedProtocol.REPORT: ddg -70.0259
============End report for ddG==================
core.scoring.ScoreFunctionFactory: SCOREFUNCTION: standard
core.scoring.ScoreFunctionFactory: SCOREFUNCTION PATCH: score12
protocols.jd2.JobDistributor: des5xxxx_0005_0001 reported success in 30 seconds

I don’t know why there is such difference. I used application InterfaceAnalyzer to get the binding properties of this structure, “dG_separated” of this structure is about -27, similar to that reported in design log.

[Anonymous]

I believe the issue is the foldtree. The current default foldtree is a star-like one where each chain moves independently. The simple_ft option of AtomTree, on the other hand, gives you a pseudo-linear foldtree, where each chain is dependent on the rigid body orientation of the preceding chain (but not the backbone degrees of freedom.) For your AB_HL complex, the GreedyOpt script and the InterfaceAnalyzer are computing the energy of the AB – HL interaction, whereas the separate ddG XML is probably calculating the ABL – H interaction (as jump 2 is only controlling H and not L), giving you a higher interaction energy.

Add the AtomTree mover to the ddG rescoring script, and you’ll probably get equivalent results.

[Anonymous]

Thank you!
I added “<AtomTree name=simple_FT docking_ft=0 simple_ft=1/>” before ddG filter, it works.

[Author]

Posts