You are here - protocols.docking.DockingInitialPerturbation: moving together failed. Aborting DockingSlideIntoContact.

8 posts / 0 new
Last post - protocols.docking.DockingInitialPerturbation: moving together failed. Aborting DockingSlideIntoContact.

When I run the docking script, it starts out ok, but, as the run progresses, the ligands are being placed further and further from the target substrate. Also, I get the message "protocols.docking.DockingInitialPerturbation: moving together failed. Aborting DockingSlideIntoContact."

Is there any way to constrain where the movers will place the ligands? I'm using the following command line options: --pdb_filename hard_to_dock.pdb --partners AB_C --jobs 1000 --job_output docked --translation 3 --rotation 8 --PyMOL_Mover_ip off

Any suggestions or ideas for debugging this much appreciated.

Post Situation: 
Fri, 2012-06-08 13:56

Here is the pdb file I was using to test docking. I got this off of the protein databank and then cleaned it up for docking.

Fri, 2012-06-08 14:24

P.S. I'm seeing similar behavior now when I run the script on the test_dock.pdb file that's given here: After about 20 attempts at docking that look pretty good, the docking script starts placing the 2nd protein farther and farther away from the protein it's trying to dock against. I thought it might be my pdb file, but, now I think it's something else. The docking attempts now look like a star field out of star trek... pretty cool looking but not what it should look like.

Also, for what it's worth, I'm running on Windows, Python 2.7, the latest version of PyRosetta.

Fri, 2012-06-08 14:35

I've forwarded this along to some of the docking folks but haven't gotten any reply back yet.

Mon, 2012-06-11 07:32

Thanks for looking at this and forwarding it to the docking folks!

Mon, 2012-06-11 08:18

Hmm, I'm unable to reproduce this behavior using either pdb file. There is a way of using constraints to force the two docking partners together but that should already be happening with the slide-into-contact mover. The best way to debug would be to comment out all but a small portion of the script at a time and try to narrow down exactly what moves are resulting in this behavior. Seems like it is probably the docking slide into contact mover, but it might be worth checking if just applying that mover results in the proteins spreading apart. If you are only interested in using the out of the box script (not making your own custom protocol) another option would be to just use the RosettaDock C++ application (instead of PyRosetta). It uses very similar command line arguments and has been tested/benchmarked to a much greater extent than the script has. Let me know how the debugging goes!

Wed, 2012-06-13 09:59

Thanks for the comments and suggestions. I've worked through the script, I find if I comment out all occurrences of the randomize_downstream RigidBodyRandomizeMover the problem does not occur. The software acts like the downstream mover is "composing translations" from one application to the next. Thus the object is placed farther and farther away on each successive call. I don't have any idea why this is happening since I don't currently have access to the PyRosetta source code. Slide into contact is not causing the problem, if I comment it out I still have the same result. It's a problem with translation and related to the downstream rigid body randomizer. I've got a 64-bit machine and I'm running the 32 bit software... not sure if that's part of the equation or not, at least I have a workaround.

Wed, 2012-06-13 14:27

Has this problem been addressed/solved? I have been struggling with it too. The above-mentioned composition of translations occurs in my simulations sooner or later, but usually within 10-100 trajectories. The molecules get so far apart that the slide mover doesn't even work anymore, the simulation slows down and the scores get to some minimal value (and rms to the astronomical).  This problem seems to occur for both the randomize_upstream and the randomize_downstream mover and even faster when both are combined. I found that defining the RigidBodyRandomizeMover movers within the simulation (job distributor) helps to solve the problem, but then all the other rigid body movers have to be moved and it is getting very unelegant...

I am working with OS X El Capitan, Python 2.7.10 and the current (January 2016) version of Pyrosetta for mac (everything in 64-bit).

Thank you in advance for any suggestions.

Mon, 2016-03-07 06:58