protein interface design for multi-chain complex

A lot of the protein-protein interface design code is written on the assumption of two chains separated by a single rigid body jump.

Here “chain1” and “chain2” simply mean “those residues before the jump” and “those residues after the jump”. For a 4-chain protein, you have three jumps, one between (at least in the before/after sequence sense) A & B, the second between B & C, and the third between C & D. If you want to do designs between the AB complex and the CD complex, you need to specify the “jump=2” parameter for ProteinInterfaceDesign to tell it to work off of jump 2 instead of the default jump 1.

Then you would do “repack_chain1=1 repack_chain2=1 design_chain1=0 design_chain2=1” to design the last two chains and not the first two chains. Keep in mind that TaskOperations are strictly restrictive. If you have one thing saying to design the residue and one that’s telling it to not pack, the not packing behavior will dominate over the design. (Because the “don’t repack” is more restrictive behavior than “design it” behavior.)

Depends on what you want to accomplish. On one hand, the fixed-sequence side of the interface certainly moves in the test tube, so allowing movement will more closely represent reality, and allow for induced-fit-type binding. On the other hand, Rosetta’s energy function doesn’t match reality precisely, so the more flexibility you allow, the more chance you have to find one of the false minima. Also, if you think thermodynamically, an induced-fit mode would result in lower binding energy, as you “lose” the energy you need to move the structure from its apo state to the bound conformation – though if you play it right, the rearrangement could more than make up for it. A final consideration is that packing is the method by which we change the position of hydrogens on things like serine and histidine, so if you don’t repack those residues, you may not get good hydrogen bonding patterns unless you’re lucky to begin with.

Generally, people will allow repacking in the interface of the fixed-sequence partner (but not secondary or distal shells), but keep the backbone conformation fixed. They then they look at the resulting designs and make sure the structural changes are reasonable and aren’t too severe.

Interpreting the fold tree:

The first two numbers for each edge are the two residues (pose numbered) that are connected by the edge. The third number tells you which type of edge you have. -1 means a polymeric edge – that is, the residues between the two endpoints are connected in a polymer. Positive numbers indicate jumps, being the jump number of the edge.

So in your fold tree you have four segments (likely chains but if your foldtree has been manipulated, it could be a one or more chains being handled as if they were four chains).

A 110 residue segment from residue 1 to 110 (likely chain A)
a 106 residue segment from residue 111 to 216 (chain , attached to residue 1 by jump #1
a 216 residue segment from residue 217 to 432 (chain C), attached to residue 1 by jump #2
a 218 residue segment from residue 433 to 650 (chain D), attached to residue 1 by jump #3

If you just moved jump 2, it looks like you’d move chain C but not chain D. What you’d want to do is use either “jumps=2,3” or “partners=AB_CD” – I don’t have enough experience with the various docking movers to know if there might be a difference between the two designations/movers would be.

Sometimes with docking the default foldtree isn’t ideal – connecting the N-terminus to the C-terminus can result in lever arm effects if you allow backbone movement. Depending on how things are set up, a small backbone change can cause a big swing in the docked partner. Instead, people change the foldtree such that the two docked partners are connected by their closest approach, minimizing lever arm effects.

That’s what’s happening here. The setup_foldtree() function notices that residue 75 (on chain A) is very close to residue 476 (on chain L) so it connects the HL complex with the AB complex through a jump (jump #1) through those residues. It then builds the rest of the protein off of those, with jump 2 connecting chains A and B, and jump 3 connecting L and H. If you were to dock with this foldtree, movement of jump 1 would be sufficient to move the rigid body orientation of the HL complex, where H and L are kept as a rigid block (assuming no backbone movements and no change in jump 3).

The reason that what you pass to the third argument doesn’t matter is because it is an *output* argument. (This is a C++ convention to get around the fact that it doesn’t have multiple return values like Python does with tuple packing/unpacking.) One of the very first things the function does (when used with the string-based partner specification – other calling conventions are different) is to clear the contents of the vector. After the function returns, the passed vector should contain the values of the movable jumps determined from the string specification.

I’ve been coding Rosetta either in PyRosetta or C++ for a few years and I’m STILL digesting it.

P.S. There’s several functions in the core::kinematics namespace (core.kinematics module for PyRosetta) to help with FoldTree visualization. core.kinematics.visualize_fold_tree(FoldTree) probably is the easiest to use.

I’m not quite sure which constraints you’re talking about regarding “minimized with constraints”. If you’re talking about using the relax application and its autogenerated constraints, they aren’t yet available through RosettaScripts. If you’re not doing backbone minimization, though, I’m not sure they would help you much, as they would either do nothing or else over-constrain the system. Other constraint system may vary. If you have generated a separate constraint file, there is a way to load that into the pose. Take a look at the ConstraintSetMover mover – but be aware that upon application it will knock out any pre-existing constraints on the pose.

When you say “very very small deviation”, what sort of changes do you actually see? The XML file you’re using is only doing a local refinement and design. I wouldn’t expect big changes from the HL rigid body position, although I would expect some small movements. I’d also expect to see mutations and rotamer rearrangments on the HL complex side – though that would depend highly on the resfile you’re using. I’d also expect to see all the sidechains slightly displaced from their starting locations (though not necessarily a great amount, especially if the input strucuture was minimized with constraints.)

You can control which residues to minimize and which ones not to with a movemap specification. The details on how to do it are with the FastRelax mover documentation (https://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/Movers_%28RosettaScripts%29#FastRelax), but the MoveMap subtag will work with the MinMover as well.

The jumps setting only controls the minimization of the jumps proper – that is, the rigid body orientation represented by the jump. For the MinMover, if jump isn’t set, the rigid body jumps aren’t allowed to minimize (but any backbone and sidechain torsions you allow to move will be minimized, including those that are after the jump in the foldtree).

If you want finer, property-based control of which residues get minimized and which ones don’t, the TaskAwareMinMover may be what you want. This allows you to use taskoperations to define minimized residues, rather than a movemap.

The MinPackMover is something different from the MinMover. Instead, it’s like the PackRotamersMover, but instead of just evaluating just the on-rotamer (or e1/ex2/etc exploded rotamer) positions, it does sidechain minimization prior to evaluation. You don’t need to specify jumps or backbone, as the MinPackMover will never change those.

Once you change a FoldTree, it stays the FoldTree of the pose until you change it again. So assuming the FoldTree isn’t reset by DockingProtocol before it exist, the new foldtree should be the one the MinMover sees. If you want, you can use the simple_ft option of the AtomTree mover (https://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/Movers_%28RosettaScripts%29#AtomTree) to reset the foldtree to a simpler default.

It’s historical accident, mainly. The various components of RosettaScripts have been put together by a number of different people over a period of time. Naming conventions weren’t ever explicitly designed, they just sort of emerged organically, and we still don’t have any official naming convention list, so people are free to use different names if they think they should. It’s best to refer to the documentation for each component to see what each option does. (As even identically named options might not do exactly the same thing in two different components.)