You are here

pose.replace_residue() & incorrect scoring

4 posts / 0 new
Last post
pose.replace_residue() & incorrect scoring

Hi developers,

I wasn't sure where to submit bug reports so I'm posting here instead.

I've noticed a scoring error after repeated pose.replace_residue() function calls. The final pose after repeated calls to replace_residue() ends up having a score substantially lower (often < -50 Rosetta energy units) than when scored using the scoring application or if the pose is loaded upon application initialization.

To replicate this behaviour run the Pose classes replace_residue() function multiple times and rescore with the scoring application, I've been doing this via a custom c++ application I'm currently toying with. Below I'll use the backrub c++ design application to demonstrate

  1. ~/path/bin/backrub.static.linuxgccrelease -database ~/path/database -s some_model.pdb -resfile nataa.resfile -backrub:sc_prob 1.0 -backrub:sc_prob_uniform 0.0 -resfile nataa.resfile -ex1 -ex2 -backrub:mm_bend_weight 0.0
  2. ~/path/bin/score.static.linuxgccrelease -database ~/path/database -s some_model_0001.pdb

What you'll notice is that the score assigned in step 1 to the lowest energy model will be X. Rescoring the model will often result in a score greater than X+50 after 1000 resplace_residue calls.

I've tried this on Rosetta 3.3 and Rosetta 2015wk12 builds and get the same scoring anomaly. In all instances the talaris2013 scoring function was used.

Let me know if more information is required or if I'm doing something fundamentally incorrect.






Post Situation: 
Tue, 2015-10-06 10:51

I'm not quite following  the protocol you're using. Are you saying the backrub protocol is doing the replace_residue() calls, or are you performing the replace_residue() calls on a backrubbed structure? In your custom application, what are you replacing the residues with? Are you interspersing other operations with your replace_residue() calls, or are you doing anything between the replace_residue() call and the call to scoring?

One minor point is that he PDB file format has less precision in atom coordinates than the interal representation that Rosetta uses. So if you score a structure, save it to PDB, and read it back in, the score from the read-in structure will be (slightly) different than before you saved it, because the coordinates will have been rounded off. Normally this is a small (less than 1 REU) difference, but depending on your exact structure it might be in a particularly sensitive region and thus rounding off the coordinates could be giving you an error. One thing you might want to try is outputting the coordinates in (binary) silent file format for storage and subsequent read-in. Binary silent files should store the full internal precision of the Rosetta representation, so they shouldn't suffer rounding issues.



Tue, 2015-10-06 12:36


Thanks for the fast response!

To clarify, I'm using the replace_residue() call in a custom application, but for the purpose of demonstrating the scoring issue I provided a backrub protocol to only sample side chains. So I'm effectively just using the backrub protocol to make multiple replace_residue() calls for demonstration purposes. When scoring the generated pose (low or last from backrub) using the scoring application (no other operation is performed between the last backrub replace_residue() call and scoring), a large REU difference is observed (> 50 REU for a 400 amino acid system).

The resfile in the above rosetta protocol should be ALLAA, but now that I've tried it with NATAA, the scoring issue persists.

What seems to be happening for the backrub protocol case is that using the sidechainmover [protocols::simple_moves::sidechain_moves::SidechainMover()] multipe times results in a large REU difference between in application scoring (so what backrub thinks the pose score is) and the actual score provided by score.linuxgccrelease.




Tue, 2015-10-06 13:58

The (admittedly brief) tests I've done haven't indicated anything untoward - as far as I noticed. I'm wondering if it might be an input issue.

Could you post the particular example input files (PDBs, resfiles, etc.) you're using here, as well as the precise details of the series of commandlines you use, highlighting where the numbers you're comparing are coming from? Working from the same example would help facilitate replicating this issue, rather than having to ad hoc input on my end and hoping it's triggering exactly the condition you're seeing.

Wed, 2015-10-07 16:35