You are here

unwanted Glycines after PackRotamersMover

3 posts / 0 new
Last post
unwanted Glycines after PackRotamersMover
#1

Hello everybody.

I am trying to design the sequence of small peptides (4-8 aa long) using PackRotamersMove but I tend to get way too many glycines (50% of residues become Glycines as avarage).
here my protocol:

"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
scorefxn_12 = create_score_function_ws_patch('score12','score12')
task_design = TaskFactory.create_packer_task(pose)
parse_resfile(pose, task_design,"resfile")
pack_design = PackRotamersMover( scorefxn_12, task_design )
pack_design.apply(pose)
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

here an example of ResFile (chain A is the binding site and chain B the peptide):
1 A NATAA

2 A NATAA

3 A NATAA

4 A NATAA

5 A NATAA

6 A NATAA

7 A NATAA

8 A NATAA

9 A NATAA

10 A NATAA

11 A NATAA

12 A NATAA

13 A NATAA

1 B ALLAA

2 B ALLAA

3 B ALLAA

4 B ALLAA

5 B ALLAA

Does anybody have any ideas about the reason why I get so many glycines?
Can it depend on the energy function? if yes which energy function wud you suggest to use?

Thanks in advance

Post Situation: 
Tue, 2014-03-04 10:08
oppopomoz

Two likely possibilities for too many Gly:

A) The Ramachandran angles for those residues are on the right side of the Ramachandran plot (positive phi). Those torsions are heavily favored for glycine, which Rosetta knows, so it puts in gly. Solution: use peptides with less tortured conformations. Easy diagnosis: force all-alanine design (PIKAA A as resfile) and see if the Ramachandran score term is huge.

B) The peptide has lots of sidechain clashes, and Rosetta is trimming back to glycine to resolve them. Solution: find a peptide conformation that, well, doesn't. Diagnosis: Look at the structure, you could fit larger sidechains, or would there be clashes? You can try the same all-alanine test and watch the fa_rep term (on a per-residue basis) - expect a clash or two, but if you have a lot of large fa_rep terms, it's sidechain clashes.

I had a loop modeling protocol with the A) problem once, which I fixed by forbidding designing to glycine for a lot of the protocol (to prevent loops from getting trapped with positive phi), only allowing them in later polishing steps.

Broad solution: NOTAA G in resfile to forbid glycine, perhaps only at some stages in your protocol. Changing the energy function is a bad idea: Rosetta is legitimately telling you something is wrong with your peptide backbones, you don't want to mute that.

Tue, 2014-03-04 10:17
smlewis

About your scorefunction (Note is independent of your Gly problem that Steven has addressed), it depends on which version of PyRosetta you are using. Newest binaries (Mac/Linux) builds or builds from Rosetta source should use talaris2013 scorefunction, as this pairs with changes to the defaults in a number of things recently (This can be found elsewhere on the forums - https://www.rosettacommons.org/node/3508). Older versions (Windows, MacOS 10.6) should use score12 as you are using.

You can use score12 with the newer versions, but you must pass the restore_pre_talaris_2013_behavior option.

Mon, 2014-03-10 11:16
jadolfbr