talaris2013 energy terms modifications

[Anonymous]

I’ve noticed that they are some modifications in talaris2013 in energy terms in comparison with score12.
There appear new hack_ele energy term. What is more now I can see rama and omega – in score12 as default they weren’t visible.
My question is : what’s stand for hack_ele? And why can I see now rama and omega energy terms? Is there any docuemnation for talaris2013?

[Anonymous]

No documentation yet for talaris2013 – at least no better documentation than there was for score12. What we have is piecemeal publications and drips and drabs of received wisdom. Part of the changes for talaris2013 are discussed in Leaver-Fay et al. Methods Enzymol. 2013 523:109 and some in Song et al. Proteins. 2011 79(6):1898, but neither of those are comprehensive.

Rama and omega were in score12, but they weren’t in standard.wts (which hasn’t been “standard” for ages now). Score12 was actually a patch to standard.wts, which turned on the rama and omega terms (among a few other things). They should have been visible if you were using score12, rather than “standard”. (BTW, as part of the move to talaris2013, we renamed standard.wts to avoid the confusion that having a “standard” weights file that isn’t in any way, shape or form “standard” anymore.)

fa_elec (which is now the new name for hack_elec) is an all-atom Coulombic electrostatic potential with a distance dependent dielectric. It replaces the fa_pair term that was in score12, which was also an (effective) electrostatic potential, but for a single “action atom” on polar sidechains, rather than all atoms for fa_elec.

[Anonymous]

Thanks. It was very helpful. But I dont understand the difference between rama and omega. They seem to be almost the same for me. The value omega reflects the rama, doesn’t it?

[Anonymous]

This default change should have been in the release notes under the NEWS tag, however, we were not quite there with parsing that information yet.

I include Andrew Leaver-Fay’s merge message to the switch as you can’t find it anywhere else on RosettaCommons unfortunately.

Modifying the default score function and idealized geometries to the “talaris2013” version.

NEWS: Updating Rosetta’s default scoring function to talaris2013.

This new functionality includes

– corrected atomic coordinates in our amino-acid parameter files, (aka 05.2009_icoor + NTermPatch geom fixes (fullatom) + CTermPatch fixes (centroid))
– analytic evaluation of the Lennard-Jones and solvation terms (derivatives match giving fewer inaccurate G! messages)
– Roland Dunbrack’s 2010 rotamer library
– bicubic interpolation of the knowledge-based terms
– sp2 hydrogen bond functional form + associated geometric improvements
– expanded hydroxyl-chi sampling (SER/THR)
– explicit Coulombic electrostatic term with a distance-dependent dielectric (hack_elec)
– removal of the fa_pair term
– tweaks to the LK_DGFREE values for four atom types
– improved disulfide geometry protential
– a new set of reference energies fit with the above modifications (39.4% sequence recovery!)

The new functionality can be rolled back by using the flag
-mistakes::restore_pre_talaris_2013_behavior

The new weight set to go along with the new set of default parameters can be found in

main/database/scoring/weights/talaris2013.wts

In order to make this score function default, ~500 places in the code where score functions were created
had to be modified. Most of these places previously asked for score12 (created by the combination
of the “standard” weight set and the “score12” patch) and these were replaced with calls to the
“getScoreFunction()” function, which reads from the command line. The remaining places asked for
score functions besides score12, e.g. just the standard weights without the application of the score12
patch. In these places, a new function, getScoreFunctionLegacy( , ) has been
added that will return the previously requested score function if the restore_pre_talaris_2013_behavior
flag is on the command line, and will otherwise invoke getScoreFunction().

A few notes:

– RotamerConstraints do not yet work with the 2010 library, and so the -restore.. flag is recommended for
protocols that rely on these constraints (or, for non-design protocols, set the -dun10 flag to false).
A talaris2013_dun02 weight set is in preparation and will be added soon.

– If you are using score functions that down weight the short-range bb/bb hbond term (e.g. as is done with
the score12.wts_patch), note that the new hydrogen bond definitions do not require that downweighting.
Short ranged bb/bb hbonds should have the same weight as long range bb/bb hbonds.

– The “standard.wts” weight set has been renamed “pre_talaris_2013_standard.wts” to avoid confusion
over which is the default score function.

– The “standard_params” hydrogen bond definition directory has been renamed “score12_params”.

– If you are using a RosettaScript that relies on score12, you will either need to add the -restore..
flag to your command line, or update your script to use the talaris2013 weight set. We will add
a default score function to RosettaScripts for the talaris2013 weight set, soon (unless someone
beats us to it).

– The LKCosTheta term relies on the table-based LJ/LK evaluation, and so any protocol (e.g. rna_denovo)
that relies on this term needs to have -analytic_etable_evaluation false on the command line.
This can be fixed in the future by separating out the “use analytic etable evaluation” flag from
the “avoid constructing the etables” flag. Alternatively, it can be fixed by making the LKCosTheta
term rely on the analytic evaluation instead of the table-based evaluation.

Unit tests have all been updated so that they will pass. They were all run with the -restore.. flag
before being updated so that the new expected behaviors reflect only the change to the score function
and are not the result of bugs that we have introduced.

Almost all integration tests will fail. To make sure that no unexpected behaviors have slipped in,
the integration tests were run with the -restore.. flag and were examined to make sure that the
changes were all cosmetic. In the absence of the -restore.. flag, integration tests were examined
to make sure they all ran to completion. Some integration tests had to be edited so that they
could run with the talaris2013 set of parameters. The antibody_legacy integration test takes
dramatically longer with the talaris2013 parameters, and so the -restore.. flag was added for this
test.

Score function fingerprint tests all pass, except for cosmetic changes to their flags files; each
of the existing fingerprint tests had the -restore.. flag added to them. A new fingerprint test
has been added for the talaris2013 score function.

[Anonymous]

and what is the difference between rama and p_aa_p?

[Anonymous]

Omega is the energy term associated with the omega backbone angle. From what I can see, there’s no dependance on the phi and psi angle in the default implementation, although there is a commandline parameter (-corrections:score:bbdep_omega) which will turn the omega term into one that uses a phi/psi/residue type dependent form, though if this is not on by default in talaris2013, it’s likely for a reason.

Rama, on the other hand, is an energy term associated with the phi and psi backbone angles (reflecting the allowed and disallowed regions of the Ramachandran plot), and depends only on the phi and psi angles, without any omega dependance.

[Anonymous]

Which direction the information is calculated in.

They’re both a statistical potential based off of the amino acid identity and the backbone conformation. Rama is calculated based off of statistics gathered under the assumption “Given a particular amino acid, what’s the probability/distribution of the phi and psi angles for that given amino acid?” (e.g. it’s based off of P(pp|AA) — p_aa_pp flips that conception, instead calculating the statistics off of “given a residue that has this particular phi/psi bin, what’s the probability that I see this amino acid type? (e.g. P(AA|pp)

The full underlying distribution — P(pp,AA) — is the same, but how the data is sliced up differs, resulting in distinct energy terms. One could argue the p_aa_pp term is set up for design contexts, but that’s not entirely true – it’s still active in non-design situations and it still influences the results, in a non-identical but still non-orthogonal way to rama.

[Anonymous]

Thanks.
And the last question: According to C. Rohl, C. Strauss, K. Misura i D. Baker, „Protein structure prediction using Rosetta,” Methods Enzymol., pp. 66-93, 2004. “Rosetta scoring function or potential energy surface is based on a Bayesian” So the energy scoring function are knowledge-based. However 6-12 Lennard-Jones potential is also knowledge-based or this scoring function is empirical? All of scoring functions are knowledge-based?

[Anonymous]

Some scoreterms are knowledge-based statistical potentials. Other scoreterms (like the LJ 6-12 fa_atr/fa_rep) are physics based. (The fa_atr/fa_rep scoreterms are more-or-less a crib from the CHARMM LJ potential.) The Rosetta scorefunction taken in total is a mix of both.

That particular sentence, by the way, is referring to the centroid energy function, which is much more of a statistical potential based scorefunction than the fullatom scorefunction is.

[Author]

Posts