You are here

RosettaScripts LinkResidues

6 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

Hey,

Thanks a lot for the reply and explanation why LinkResidues is bad. 

I had a different project coming in between so I couldn't focus on it yet.

I now first derived a symmetry file which is based on my structure and verified the assembly and after some puzzling it's all good.

Now I'm trying with PackRotamersMover and a res file to mutate 19 residues (some have one option, some have 5 options), but the output (-nstruct) is basically all the same, the same mutation happened on the different structures. Because there are multiple options I don't think I can use MutateResidue, but is there a way to introduce more variety to obtain different constructs?

Best wishes,

Yero

Wed, 2019-07-03 06:37
Yero

My suggestion would be backbone variation. Fixed backbone design is sometimes very convergent. If you allow the backbone to move, though, you can get different sequence results, even if the input structure isn't all that different.

There's several options for introducing backbone movement. The first is to do not just one round of mutation, but instead to do repeated rounds of mutation with a (flexible-backbone) minimization in between. Slight differences in design (or even just sidechain placement for a single design) will result in differing minimization trajectories and different results.

The other is to pre-generate the backbone diversity by doing something like running the starting structure through relax. (You can apply symmetry during relax.) This should result in an ensemble of different-but-similar structures, which should result in different sequences when you design them.

Depending on what you're interested in, you can try other approaches to introduce backbone diversity. For example, active loop remodeling is a possibility, as is various fragment-based techniques. Typically, though, minimization or relax introduces enough backbone variation to result in the desired level of sequence diversity.

Tue, 2019-07-09 10:04
rmoretti

Thank you for your answer!

I tried once with backrub, it showed a bit more variation, but am trying now with fastrelax.

The output is really different from the expected output, so I'm trying with constraints, but currently still have an error with this.

Thu, 2019-07-18 01:39
Yero