You are here

RosettaScripts LinkResidues

3 posts / 0 new
Last post
RosettaScripts LinkResidues
#1

Hey,

I want to redesign the interface of two three-fold symmetrical proteins and I thought of using RosettaScripts.
I first wanted to make it work on one three-fold symmetrical protein and then continue with the interaction, but I am stumbling on some errors.

I'm using LinkResidues, because the protein is three-fold symmetrical, so a mutation on residue a should also occur on residue b and c, thus without breaking the symmetry of those residues.

I'm using:

<TASKOPERATIONS>
  <ReadResfile name="int_one" filename="int_one.txt" />
    <LinkResidues name="IntDesign">
      <LinkGroup group="a,b,c" />
      <LinkGroup group="d,e,f" />
      <LinkGroup group="g,h,i" />
      <LinkGroup group="j,k" />
    </LinkResidues>
  <ExtraRotamersGeneric name="extrachi" ex1="1" ex2="1" ex1_sample_level="4" ex2_sample_level="4" />
</TASKOPERATIONS>

There is no residue l, due to the N-, C-terminal stuff, so j and k are just linked together.

Via Movers I do the "PackRotamersMover" and select all three (int_one, IntDesign, extrachi) and via protocol I do "Add mover".
The ResFile 'int_one.txt' contains residues a-k, all on separate lines with the correct chain and 'PIKAA' followed by the amino acids I prefer (a few just have one option, but I thought that's okay normally).

When I excecute this I get a 'segmentation fault'-error, but if I remove one '<' of the LinkGroups or keep the script intact but just remove one residue (i.e. "d,f" instead of "d,e,f" it will work.

I also tried to have one residue outside the linked residues that is also allowed to be mutated via an extra PackRotamersMover function, but that didn't change the 'segmentation fault'-error.

Can anybody help/explain this problem please?

Thanks in advance!

 

Category: 
Post Situation: 
Fri, 2019-05-17 05:26
Yero

Don't use LinkResidues.  LinkResidues is a horrible hack for almost-symmetric systems that aren't truly symmetric, to let Rosetta know that certain residues should mutate together.  If you've got a truly symmetric system, use the Rosetta symmetry machinery.  You set up your pose as a symmetric system, and after that point, everything that happens to it is guaranteed to preserve the symmetry automatically.  See the Rosetta symmetry tutorial to get started: https://www.rosettacommons.org/demos/latest/tutorials/Symmetry/Symmetry.

If you've got a PDB file with a threefold-symmetric starting scaffold, I'd recommend the following:

- Edit your PDB file in PyMOL or another editor so that your trimer is centered on the origin, with the symmetry axis aligned with the Z-axis.  Then delete two of the subunits, leaving only one.

- Use the make_symmdef_file_denovo.py script (located in Rosetta/main/source/src/apps/public/symmetry) to generate a symmetry definition file for C3 symmetry.  Edit the file, and comment out the "recenter" line (or delete the line).

- Write a little RosettaScripts script that does the following:

     - Use the SetupForSymmetry mover (https://www.rosettacommons.org/docs/latest/scripting_documentation/RosettaScripts/Movers/movers_pages/SetupForSymmetryMover) to read in the symmetry definition and convert the asymmetric unit that you read from the PDB  file into a C3-symmetric system.

     - Use the MutateResidue mover to introduce a desired mutation on one subunit (which will automatically propagate to all others), or use design movers (e.g. PackRotamersMover, FastDesign) to design one subunit (with the effects propagating automatically to all others).

One final note: the Advanced RosettaScripts Tutorial (https://www.rosettacommons.org/demos/latest/tutorials/advanced_scripting_with_rosettascripts/advanced_scripting_with_rosettascripts#symmetry-within-rosettascripts) mentions how to use symmetry within RosettaScripts.  I just noticed that it's a bit out of date, though: if you're using the latest weekly releases of master, it is no longer necessary to specify that a ScoreFunction is symmetric, or to use the SymmetricPackRotamersMover instead of the ordinary PackRotamersMover.  Instead, ScoreFunctions are automatically symmetry-aware, as is the ordinary PackRotamersMover.  I'll try and update that when I have time.

Fri, 2019-05-17 16:13
vmulligan

(One final note: LinkResidues is incredibly inefficient: it treats a symmetric system as an asymmetric system, and does extra work to keep everything symmetric.  The symmetry machinery, on the other hand, is elegant, in that it converts a system with 3N degrees of freedom into one with N degrees of freedom.  It actually _saves_ quite a bit of comuptational expense.  Frankly, I'd love to pull LinkResidues out and toss it, but that it's necessary for certain quasi-symmetric special-case modelling tasks.)

Fri, 2019-05-17 16:15
vmulligan