Docking a protein into a symmetrical complex

[Anonymous]

Hi everyone,
I’m brand new to the forums and a beginner at using Rosetta. I’ve got what may be a very simple or a very complicated question. I would like to dock a relatively small protein into a symmetrical complex with known symmetry and structure. At first, I saw the Symmetrical Docking protocol and thought that might be what I should use, but that seems to be for docking the members of the complex together, not for docking a different protein into the complex, and I’d imagine the scoring would be more complicated in this case. Has anyone done this before, can Rosetta do this, and if so, could someone steer me in the right direction? Thanks so much!
Seth

[Anonymous]

I’m not quite clear on your problem.

If you have: dock C to AB, where AB is a highly symmetric homodimer: just use regular docking, the symmetry is irrelevant.

If you have: dock C and D separately to AB, where C and D are the same and must dock symmetrically: this would be hard, but you could probably just dock only C and place D later, assuming C and D do not interact.

If you have: re-model the docking between A and B symmetrically when C is added to the system, that is probably hard.

Does that help any?

[Anonymous]

Hi smlewis,
Thanks so much for your quick response. I’m running a blind docking of a protein (let’s call it A) to a layer of proteins (let’s call the monomer that tile as hexamers. As a result, in order to consider all possible binding sites, it would be necessary to run the docking of the A against a complex of 10 of B (one hexamer, the edges of two adjacent hexamers, and the interface where the three hexamers meet). This in and of itself is not extremely computationally intensive. However, when I was relaxing a large complex of B to prepare for the docking, it took several hours to generate one structure, while when I incorporated symmetry, a relaxed structure was generated within minutes.
Because running relax with symmetry used resources so much better, I was curious if there was a way to dock A into a layer of B by inputting just A, the monomer of B and B’s symmetry information. Would this allow Rosetta to be similarly much more efficient with its computations? I’m planning to repeat this experiment with a variety of different layers and possible binding proteins in the future, and any increase in efficiency would be extremely helpful.
I can think of one possible problem. It seems that if A binds asymmetrically to the layer of B, then requiring all moves of B in minimizing the energy to be identical will likely not represent reality. Perhaps I could do a low resolution dock with symmetry and then refine it in high resolution without symmetry? Again, I’m a complete beginner here and don’t know if this is possible or wise. Thanks for your time!
Seth

[Anonymous]

My understanding of symmetric docking is that it is to be used in situations where the docking “axis” is also the axis of symmetry. When you have a a homodimer (AB) docking to a monomer (C), you should use the -docking:partners option. For this situation, it would be:

-docking:partners AB_C

To make life simpler, I would list the chains in the same order as they appear in the input pdb file. Unfortunately, I don’t know too much about using the symmetry mode, so I can’t be much help for symmetric docking.

[Anonymous]

Thanks everyone! This has been very helpful. I’ll go ahead and run the docking without symmetry. In order to avoid redundancy in the locations available for the docking, I’ve limited the layer of A to one hexamer and two monomers each from adjacent hexamers to include two-fold and three-fold interfaces between hexamers. However, this still contains a number of repetitive units. Here’s an example of why this is a problem for me: Suppose I have two docking runs. In Run1, A (the protein being docked) docks to M1, a subunit of the hexamer in the layer of B. In Run2, A docks to M2, a non-adjacent subunit in the same hexamer in a layer of B. In both runs, let’s suppose A is not in contact with any adjacent subunits, though in other runs, the docking interface could extend across anywhere from 1 to 6 subunits of B. These will have very different RMSD values, while if we superpositioned the two solutions by M1 and M2, we might find that A is in an almost identical position in each. Due to the fact that there are 10 identical subunits of B in this run (and all are necessary), this indicates that a large percentage of the results will be highly repetitive but not obviously so. I think an easy way to fix this would be to use constrains. I’ve read about site constraints in Rosetta++ and would like to penalize any docking solutions that do not place A in any contact with one specific subunit in the hexamer of B while allowing contact with all other subunits, but I don’t know of a way to do this in Rosetta 3.2.1. I’ve already read the constraint documentation, but I don’t see any mention of penalty site constraints, and it is not clear if I can penalize a solution that does not place any atom of A in contact with any atom of one specific chain of B. Any help would be appreciated.
Seth

[Anonymous]

Hi Steven,
Thanks for the suggestions! I’m now running into a different problem. When I run the docking with constraints, I see two error messages that say “protocols.docking.DockingProtocol: Danger Will Robinson! Constraints not supported in docking. Do not use. You will be sad.”
If I’m running both low- and high-resolution docking, the docking run continues on, but constraints are clearly not affecting the results or the scoring. If I’m running with the -low_res_protocol_only flag on, then the docking run quits immediately after these errors with a Segmentation Fault. Any ideas as to what might be causing this?
Seth

[Anonymous]

I’ve forwarded it to weitzner. I didn’t know docking in 3.2 didn’t support constraints; it can probably be hacked in with middling effort.

No idea on the segfault – running in debug mode (mode=debug when compiled) may offer a more useful error message than just a seg fault.

[Anonymous]

Sadly, adding constraint support to docking is not a small task, however, it has been done. I am going to try to track down that seg fault and after that is fixed, maybe I can provide a statically-linked executable of docking with constraint support – Steven: Does the license permit me to do this?

[Anonymous]

saxen – I have fixed the segfault issue and would like to send you a statically linked docking executable with working constraints. What platform/architecture do you use (e.g. linux 64-bit)?

[Anonymous]

Weitzner, yes, I use a 64-bit linux. Thanks so much!

[Anonymous]

Hi weitzner,
Thanks for the information. The only info I could find on site constraints was old. From what you’re describing, it definitely sounds like distant constraints are more what I’m looking for. My e-mail address is saxen@lbl.gov, by the way.
Seth

[Anonymous]

I flagged this for further attention from the docking and symmetry gurus, but on the outside, I think you don’t need to worry about symmetry for docking. The symmetric docking stuff is written for homocomplexes so far as I know; I don’t think the faster relax result will translate to docking.

I think your best bet is docking A and whatever groups of B you want; there should be a tool in docking to say “treat this group of Bs as one big monomer”.

[Anonymous]

There is unfortunately no way to mix symmetry with non-symmetry in rosetta. The binding of a protein to the hexamer makes is non-symmetric – unless a protein is bound to every subunit in the hexamer. So you are stuck with non-symmetric docking and all atom refinement. If you want to maintain the symmetry of the hexamer during the refinement you would have to add some sort of contstraint. But it would probably not help much with speed.

[Anonymous]

“and it is not clear if I can penalize a solution that does not place any atom of A in contact with any atom of one specific chain of B”

The constraints need to specify which atoms they concern, but you can build constraints via AmbiguousConstraints that only affect the score in a generic fashion. See this post for an example: http://www.rosettacommons.org/node/2358#comment-2441

Basically, you might run 100 docking runs to get an idea of where a B-A interface might be, with 100 potential contacts. Then, you use AmbiguousConstraint and MultiConstraint (with judicious grouping) to say, “one of these 10 groups of constraints must be satisfied”, but you don’t enforce which one. This lets you force B to stick to a particular A, but doesn’t define the orientation.

You may also be able to get away with a wide-well CoordinateConstraint on the center of mass atoms of B, which restrict it to being above a particular A.

[Anonymous]

“Does the license permit me to do this?”

::shrug:: I’m no lawyer. Jeff will probably not disapprove?

[Anonymous]

Btw, there are some caveats to using constraints with docking. First off, there are two types of constraints: site and distance. Right now, distance constraints are proper constraints objects, for which there is documentation here: http://www.rosettacommons.org/manuals/archive/rosetta3.2.1_user_guide/constraint_file.html. The only additional thing you should know for distance constraints is that for the “residue number” field, you can specify the pdb residue number and chain (e.g. 34A). We think this makes it more clear in the case of docking.

Site constraints are used to reward or penalize residues for being in the interface. Since this requires some additional information, these types of constraints are not proper constraints, that is, their parent is not a constraint. Because of this, site constraints currently have quite limited functionality, and I would recommend against using them until they have more functionality. If you want to try site constraints anyway, here are the details on the file format:
In a file with the extension .site:

ResNo Chain Penalty
ResNo Chain Penalty

ResNo is the pdb residue number, chain is the one letter pdb chain identifier and penalty is floating point number. A positive penalty is for residues that should not be in the interface, and a negative penalty is a reward for that residue being in the interface. Right now, this is applied as a step function (like I said, limited functionality), so please use with caution.

[Author]

Posts