You are here

Using ref2015 and talaris2014 in the same script

3 posts / 0 new
Last post
Using ref2015 and talaris2014 in the same script


I'm using pyrosetta compiled from rosetta_src_2017.39.  I was wondering whether it's possible to use both talaris2014 and ref2015 in the same script.  When I try to set up a scoring function using talaris2014 weights, I get this error:


ERROR: talaris2014(.wts) requested, but -corrections::restore_talaris_behavior not set to true. This leads to a garbage scorefunction.  Exiting.


If I put in the appropriate flag when starting rosetta (-corrections::restore_talaris_behavior), I can set up a scoring function using both talaris2014 and ref2015.  I was wondering, is the ref2015 scoring function is impacted negatively by this flag I've added?  If I put in this flag, can I use both talaris2014 and ref2015 score functions in the same script?

One related question about ref2015 - I did a quick benchmark repacking an antibody.  With talaris2014 repacking took 10.8s (measured using the timeit function in pyrosetta).  Using ref2015, repacking took 24.0s.  Is this difference expected (i.e. taking more than twice as long)?  Is there some other flag that I have to set to get ref2015 to run in a time that's comparable to talaris2014?




Post Situation: 
Wed, 2017-11-01 10:24

No, it's not possible.

The change from talaris to REF involved more than just changing the weights file. There's associated changes in a whole bunch of low-level information which is not captured by the weights file, and even not entirely captured by the score function object. As such, the change between the two regimes is something of an all-or nothing. Either you're working with talaris or you're working with REF.  (You might be able to use the talaris/REF *weights* file with REF/talaris, but that's definitely not the same thing as using the talaris/REF *energy function* ... hence the error message.)


Regarding the slowdown, it's a known issue that REF is slower than talaris.  It's not really a function of the code being slower (though it is, slightly), at this point we think it's more of a result of the energy landscape being different, and thus taking more time to optimize over. We're looking into it, seeing if there's ways around it, but at this point there isn't a single flag you could point to which would change the performance behavior of REF.

Wed, 2017-11-01 10:35

Thanks Rocco for the quick reply.  Much appreciated.

Wed, 2017-11-01 10:39