About scorefunction.

Those different scorefunctions are simply for different stages of the abinitio protocol. As abinitio progresses, it goes through multiple different stages, each one getting progressively more complex and detailed (roughly speaking). The scorefunctions reflect this – notice that score0 has only the vdw term, whereas going to score1 and score2 you add in more terms and re-weight others. This progressive stage approach allows Rosetta to quickly throw away/fix structures that will never work, and saves the time consuming later stages for structures that have a greater likelihood of being good.

“Potential energy” is perhaps not the best way to think of it. In contrast to some other techniques, Rosetta doesn’t concern itself heavily with matching up energies with some theoretical kJ/mol value. Instead, it attempts to find metrics which captures the experimentally relevant features – for example, metrics where native-like structures have a lower score than non-native-like structures. This is especially true of multi-stage protocols like abinito, where the early stage scorefunctions might not necessarily have direct physical relevance, but instead do the best job of selecting those structures which will be experimentally relevant when the complete protocol is done.

All that said, in those situations where we do compare Rosetta produced scores/energies with experimental energies (e.g. binding energies, or delta-delta-G of folding), the values that Rosetta gives are typically linearly related to the experimental energies, although the slope and intercept may be arbitrary values.

For the most part, the code to calculate the various scorefunction terms is located under the rosetta_source/src/core/scoring/ directory, particularly in rosetta_source/src/core/scoring/methods/ Each scorefunction term typically has its own class or two. You’ll probably want to read Leaver-Fay et al. “ROSETTA3: an object-oriented software suite for the simulation and design of macromolecules.” Methods Enzymol. 2011;487:545-74 http://www.ncbi.nlm.nih.gov/pubmed/21187238 to get an overview of how the score function system is organized.

I’m not quite sure if I understand your question. Scons is a build system, whereas gcc is a compiler. They do different things. In typical usage, both are used to build Rosetta.

What you may be asking about is how to use GCC directly, without invoking scons. The reason for this is that the overhead of the scons system can sometimes take a lot of time, which adds up when you’re repeatedly compiling during development. The recommended way to do this is to make your changes, and the first time you compile, capture the scons output to a file. That should list all the commands scons invoked to make the build. You can then edit out all the non-command items, and use that file as a shell script to re-invoke the compile. As long as you keep changing the same files, the commands should be the same. (If you have to change additional files, you need to re-invoke scons to figure out all the commands that need to be built.)

That’s only worthwhile if you’re doing a large number of recompiles with changes to the same set of files. If you’re only recompiling a few times, or are going to be touching a different set of files with each recompile, it’s not really worth it.

By the way, if you just want to recompile a single application, you can specify just that application on the scons command line. So instead of compiling the whole bin directory with “scons mode=release bin”, you’d do “scons mode=release bin/AbinitioRelax.linuxgccrelease” to just compile the AbinitioRelax application.

In general, all of the Baker Lab CASP papers would be a good bet to understand how Rosetta abinitio code runs.

The Rosetta3.5 documentation (https://www.rosettacommons.org/manuals/archive/rosetta3.5_user_guide/db/d26/_abinitio_relax.html) specifically mentions the following papers:

Srivatsan Raman, Robert Vernon, James Thompson, Michael Tyka, Ruslan Sadreyev,Jimin Pei, David Kim, Elizabeth Kellogg, Frank DiMaio, Oliver Lange, Lisa Kinch, Will Sheffler, Bong-Hyun Kim, Rhiju Das, Nick V. Grishin, and David Baker. (2009) Structure prediction for CASP8 with all-atom refinement using Rosetta. Proteins 77 Suppl 9:89-99.

Bradley P, Misura KM, Baker D (2005). Toward high-resolution de novo structure prediction for small proteins. Science 309, 1868-71.

Bonneau R, Strauss CE, Rohl CA, Chivian D, Bradley P, Malmstrom L, Robertson T, Baker D. (2002) De novo prediction of three-dimensional structures for major protein families. J Mol Biol 322(1):65-78.

Bonneau R, Tsai J, Ruczinski I, Chivian D, Rohl C, Strauss CE, Baker D. (2001) Rosetta in CASP4: progress in ab initio protein structure prediction. Proteins Suppl 5:119-26.

Simons KT, Ruczinski I, Kooperberg C, Fox B, Bystroff C, Baker D. (1999) Improved recognition of native-like protein structures using a combination of sequence-dependent and sequence-independent features of proteins. Proteins 34(1) 82-95.

Simons KT, Kooperberg C, Huang E, Baker, D. (1997) Assembly of protein tertiary structures from fragments with similar local sequences using simulate anealing and Bayesian scoring functions. J Mol Biol 268:209-25.

The Rosetta 2.3 documentation (https://www.rosettacommons.org/guide/AbRelax) mentions the following additional papers:

Das, R., Qian, B. et al, Structure prediction for CASP7 targets using
extensive all-atom refinement with Rosetta@home. Proteins (2007), in
press.

Qian, B., Raman, S., Das, R., Bradley, P., McCoy, A.J., Read, R.J. and
Baker D. (2007). High resolution protein structure prediction and the
crystallographic phase problem. Nature. manuscript accepted.