You are here

Score Functions for Ligand-protein Docking

5 posts / 0 new
Last post
Score Functions for Ligand-protein Docking

Hi Rosetta Users,

I have a couple of questions on score functions that appeared in the protein-ligand tutorial. In the docking protocol XML file ( ), the score functions used are ‘ligand_soft_rep’ and ‘hard_rep’ with their corresponding weights for ‘HighResDocker’ and ‘FinalMinimizer’ movers. In the options list ( ), there is a flag state ‘-restore_pre_talaris_2013_behavior true’ which restores some parameters to earlier values. 

So, my questions/confusions are:

  1. Is my understanding correct that weights are given in the XML file, and a specific score function is given in the options list? 
  2. What score function actually used in this tutorial? How did the flag ‘restore_pre_talaris_2013_behavior’ change the behavior on score functions: ‘ligand_soft_rep’ and ‘hard_rep’ in this case? 
  3. How can I appropriately implement other score functions? For example, if I want to use ref2015 or betanov16, do I need to change the weight in the XML? And what do I need to do for the options list?
  4. Does the mover sequence in <movers>…</movers> and <protocols>…</protocols> matter? If it does, for example, when I add a new mover that adds water molecules to the interface, is it right to place it after ‘transform’ and before ‘high_res_docker’ mover?


I also tried to use GALigandDock mover, but it failed. What I know about GALigandDock is that it takes a ligand-protein complex as input and optimizes ligand conformation to predict docked structure. I attached the files I used for GALigandDock, and I appreciate any feedback. Since GALigandDock analyzes ligand structure, is it possible to add it after 'final_minimizer' and before 'InterfaceScoreCalculator' to better predict the docked structure? Or maybe just after 'High_res_dock'?

I appreciate any help! And shout out to this forum, I've learned so much from you all!





This is the XML for GALigandDock I used: 


            <ScoreFunction name="dockscore" weights="beta_genpot">
                <Reweight scoretype="fa_rep" weight="0.2"/>
                <Reweight scoretype="coordinate_constraint" weight="0.1"/>
            <ScoreFunction name="relaxscore" weights="beta_genpot_cart"/>

            <GALigandDock name="dock" runmode="dockrigid" scorefxn="dockscore" scorefxn_relax="relaxscore" nativepdb="6WNP_crystal.pdb"/>

            <Add mover="dock"/>

        <OUTPUT scorefxn="relaxscore"/>


Input PDB420.94 KB
options flags667 bytes
Post Situation: 
Sun, 2021-04-25 13:41

So there's multiple things which affect the scorefunction. The primary thing which controls the scorefunctions is the weights file, which specifies which terms to use, and at which level. But each of the terms also have a number of internal parameters which determine how they function. Changing those internal parameters will change how the scorefunction works, even with the same weight set. Those internal parameters are what the `-restore_pre_talaris_2013_behavior true` option is doing. It's not affecting the weights, but rather the internal parameters of the various terms being enabled.

The ligand soft-rep and hard rep weights were optimized for the pre-talaris behavior of the various score terms, so to get the best results with those weights, you want to enable the internal settings of the terms which those weights were optimized with. (And it looks like those old ligand weights do a better job with the RosettaLigand protocol than the current optimized-for-protein scorefunctions:

To use a different scorefunction, you would need to both ensure that the appropriate flags (or absence thereof) are set in the options for whichever scorefunction/Rosetta version you want to use. Then you would specify the weights to use in the SCOREFXNS section of the XML. (See again the Smith & Meiler paper, which did test alternate scorefunction settings.)

The order of the movers in the movers section really don't matter, so long as any nested movers (movers which take other movers as parameters) come after the definition of the mover it's using as a parameter. (The XML is interpreted in order, from top to bottom.)  The order of the movers in the PROTOCOLS section *does* matter, though, as the Protocol implemented is defined as going through each of those movers in the order they're specified. (That is, the first mover is applied, and then the output of the first mover is fed as input to the second mover, which is then applied and the output is fed into the input of the third mover, etc.)

The GALigandDock protocol is a separate docking protocol from the RosettaLigand Transform/HighResDock/FinalMinimizer protocol. I don't think anyone has investigated combining the two of them. I'm not sure if it would be worth it, as both of them are attempting to do the same thing, namely do a seach of the position/orientation of the ligand. -- I don't think there's necessarily anything theoretically wrong with putting the FinalMinimizer and/or the InterfaceScoreCalculator after the GALigandDock mover, though as you indicate, the GALigandDock mover was written to be independent of the standard RosettaLigand protocol, so I'm not sure if it would be useful.

A potential issue with combining them is the scorefunction issue. Wherease the RosettaLigand protocol is optimized to work with the pre-talaris ligand scorefunctions, the GALigandDock protocol is intended to work in the context of the genpot potential. As such, you would likely want to turn on the flags (and weights file) for the genpot potential while using it.

Wed, 2021-04-28 09:41

Thank you so much! This is really helpful!  Just one more thing I want to ask, can Rosetta run a protocol with movers that require different environments(e.g., score12, ref2015)? For example, using pre_talaris2013 for movers such as HighResDocker, and using betanov16 for movers like ddG, in a single docking protocol. I recently read a paper that introduced a mover to calculate energy including water molecules. ( Here is the paper: ) I wonder if i can combine them and get a more accurate binding energy estimate. 

Wed, 2021-04-28 16:39

Unfortunately, there's no way to combine the different scoring environments (pre-talaris; talaris; ref2015; genpot) in the same run. The settings which change between them are global settings, and can't be switched mid-run.

What you could do, if you really wanted to, though, is do a partial run with one environment, save the structures to disk as PDBs, then load them up and complete the run with a different environment.

Thu, 2021-04-29 15:57

Thanks! I might try this way. 

Fri, 2021-04-30 12:01