You are here

domain:domain fusion

6 posts / 0 new
Last post
domain:domain fusion

Dear all

I would like to insert a domain at the N-terminus of protein and at the same time build different linker sizes. Which application is the best suited? My impression is that domain insertion protocols, like remodel, broker or AnchoredPDBcreator, assumes that we are not at the end or a protein. Is there a way to do this?

thanks in advance



Post Situation: 
Thu, 2017-06-15 13:13

Do you have a particular orientation you want the inserted domain to be in with respect to the existing domain? My suggested approach would probably be to first treat the two domains as independent chains, combine them together in the correct orientation as independent chains (ignoring the linker region), and then use one of the loop remodeling protocols in Rosetta (or homology modeling using your mockup as a template) to complete the linker between them.

If there's some flexibility in the relative orientation of the domains, you can either sample that on the backend with relax and active loop sampling, or you can pre-generate a number of relative orientations and do separate loopmodeling on each.

Fri, 2017-06-16 07:39

Hi rocco!

thanks for your answer. My idea is to build a rigid linker between both domains. But I would like to sample different orientations and  distances in between, and this is something I can't clearly see how to do it. Docking probably will favor interactions between domains and this is something I want to avoid.

is there a way to pre-generate a number of relative orientations

thanks again


Fri, 2017-06-16 08:34

So you have two problems.  One is computationally hard, and one is mechanically hard due to flaws in Rosetta.

The computational problem of "given this linker, how will these two proteins dock" is challenging but addressible.  FloppyTail is non-awful (but not great) for sampling the DOFs between two rigid bodies with a linker peptide.  As Rocco suggested, loop modeling is great where the rigid body orientation is known but the linker conformation is not.  You can always try free docking followed by loop closure, as well.

The mechanical problem is "I want to add residues and glue poses together".  That's low-to-medium difficulty in code, but extremely hard from the command line interface.  Nobody knows how to write a generic command line interface to allow you to make that kind of modificiation.  Remodel is the closest I know of.  

This is a TERRIBLE solution, but it is probably what I would do:

1) pre-position the C- and N- termini very close together, for example by dragging in pymol

2) manually edit the PDB file to insert dummy residues for the linker.  Make sure that the two proteins are now of the same chain ID and that the dummy residues number contiguously on both sides, so that Rosetta knows they're supposed to be attached.  DO make sure the dummies have N, CA, C, O; the actual coordinates aren't important so long as they aren't co-linear (that will break torsion calculations) - usually I just copy the last residue of the first protein.  Do this M times for your M linker lengths.  

3) run this hot mess through loop modeling with the "delete the existing loop conformation" option activated.  This will debride the garbage coordinates for your new residue and put in something with reasonable geometries.

Now you have something that's at least CHEMICALLY your interesting species (w/r/t the backbone) - so you have the starting structure for addressing the actual computational problem through FloppyTail.  I assume you can see how to modify this for docking+loop modeling instead - don't use pymol drag in the first step, use rosettaDock instead.




Separate solution: the "assembling the starting structure" part is pretty straightforward in the code, in C++ or Python - so if you're comfortable with PyRosetta, this is a great place for it.

Fri, 2017-06-16 08:50

Here's some more thoughts on how to use FloppyTail in the general case (which may apply to your problem).  I'm also adding this to the documentation, but that update will take a day or two, so here it is for you immediately.




The Philosophy of FloppyTail – how to use it on hard problems


(Note that this section may duplicate some of the above, or the demo – it was written to stand alone and included here for posterity)


FloppyTail is aimed at “constrained docking”.  It can be used when you have one or more relatively rigid domains, with flexible linkers connecting them / at their ends.  For some cases, like the original flexible tail, the question is “where might this tail be able to dock onto the rigid protein?”  For some cases, like two domains with a linker between them, it might be “how should these two proteins dock, given that some conformations are impossible because the linker can’t stretch that far?”


Broadly speaking, FloppyTail comes into play for FLEXIBLE linkers.  There are two problems with this.  First, the Rosetta energy function is parameterized on and for well folded crystalline protein.  It will only do so well with flexible linkers, because its view of physics doesn’t allow for unstructured soluble protein.  Second, flexible linkers are flexible in time, but a static structure has no time domain, so looking at the top model by score is not very informative about the state of the linker region.  So, using FloppyTail and interpreting its results requires some careful consideration of the value of the results. 


If your goal is “I have two proteins that are connected and I want to know what it’s going to look like” – that’s an expensive problem and the success rate is marginal.  (It’s equally expensive, with an equally marginal success rate, to just do global docking and then try to solve the loop, which is a valid alternative).


If you have NO experimental data about your problem, you can use FloppyTail to generate hypotheses.  Look at your result ensemble and see what interactions recur frequently in the better models, then think about ways to test experimentally if those interactions are real (via crosslinking or mutagenesis, perhaps). 


Perhaps you have an idea of a conformation that might exist and you want to check computationally before trying the experiment.  In this case, try using constraints to force the conformation you’re interested in to see if the system can accommodate it.  If you get out models that still don’t have the interaction you wanted, or can only achieve it with tortured geometries, that constitutes a negative result from FloppyTail.


If you have experimental data – great!  Constraints are the way to go.  Run the code with constraints, and you’ll get much higher model quality to feed into further hypotheses.  Alternatively, use the constraints to filter unconstrained results, or just use them to judge if the model population is realistic.  This lets you generate an “envelope” of the things the system might be doing consistent with your constraints, which can be used for further cycles of experiment as necessary. 

Fri, 2017-06-16 10:43

Hi Steven

great! thanks for the advice and I will try to implement it


Fri, 2017-06-16 11:42