Member Site › Forums › Rosetta 3 › Rosetta 3 – General › -dock_pert problem
- This topic has 11 replies, 4 voices, and was last updated 13 years, 1 month ago by Anonymous.
-
AuthorPosts
-
-
July 19, 2010 at 10:45 pm #630Anonymous
Not to overwhelm the forum but I was wondering if anyone else has run into the following problem when using -dock_pert:
I am successfully able to use the “local refinement” procedure to generate decoys with small perturbations compared to my input structures and everything works great. I can do this by running docking_protocol.linuxgccrelease @flags where flags contains:
-database /usr/global/rosetta/rosetta3.1/rosetta_database
-l names.txt
-nstruct 1000
-no_optH false
-docking:docking_local_refine
-docking:partners ABCD_EF
-fake_native
-ex1
-ex2aro
-packing:use_input_sc
-mute core.util.prof
-out:output
-out:pdb
-out:file:fullatom
-out:path:pdb ./RESULTS
-out:show_accessed_optionsWanting to increase the search space, I thought to use -dock_pert to add a larger perturbation. I used the same input structures and identical flags as above but substituted “-docking:dock_pert 3 8” instead of “-docking:docking_local_refine”.
The decoys produced by doing this appear to have translated the ligand about 500 angstroms away from the receptor. The center of mass distance between the original placement of the ligand in my input structure versus the resulting decoys ranges from about 491 to 505 angstroms. I would also like to add that the problem seems to be in translation perpendicular or normal to the ligand/receptor interface (ie the decoy ligand protein structures form a nice cluster with structures having nice small perturbations relative to each other…only that the cluster is ~500 angstroms away from my original receptor/ligand interface).
Perhaps I’m missing some other necessary flags which support -dock_pert 3 8?
I tried specifying -dock_pert 3 8 8 but it does not accept the third argument. I also tried adding -dock_mcm but it does not recognize that flag. Any thoughts? -
July 20, 2010 at 2:31 pm #4495Anonymous
To clarify: you have 6 chains in the complex, and you’re docking EF to ABCD?
Which chains are moving 500 angstroms? EF, ABCD, or some combination?
I can think of two possible culprits. (There’s more than I can think of for sure).
One possibility is that the centroid perturbation phase is producing a bad clash, which the minimizer “fixes” by moving the chains apart. The huge step size (500 angstroms) may be due to it being a huge clash or overly granular minimizer settings.
Another is that the code responsible for interpreting which chains are in which rigid body has gone haywire, and is trying to move your whole complex (say, to the origin) but instead accidentally only moves part of it. It could also be separating them deliberately for dG_bind calculations but they somehow aren’t put back together?
-
July 22, 2010 at 10:37 pm #4497Anonymous
Thanks for the suggestions. You are correct, I am docking the protein containing chains EF to protein with chains ABCD. The chain that moves 500angstroms compared to the input structure is chain EF.
To try to avoid clashes I have tried moving the two proteins apart by several increments, from a few angstroms to ~20 angstroms (at closest contact) away from each other and tried decreasing the -dock_pert perturbation sizes and tried doing prepacking. I have also varied the number of inner and outer cycles in the adaptive moves using the -docking:docking_centroid_inner/outer_cycles flags.
Occaisionally, if I start the proteins ~7 angstroms from each other and increase the number of outer and inner cycles by 5x the default values to 50 outer and 250 inner cycles respectively, I get 1 or 2 structures out of every 15-20 that will be closer than the typical 500 angstroms. These structures actually form an interface with the protein but still have a centroid RMS of ~100-150angsroms which is significantly greater than the 0-8 angstrom perturbations I’m shooting for.
Looking at the output the problem does seem to be in the Low-resolution rigid body moves. I’m not sure why it thinks it is failing in moving away… Below is partial output from a run w/ -dock_pert 3 4, outercycles = 100, innercycles = 50:
…
protocols.docking.DockingProtocol: Setting docking foldtree
protocols.docking.DockingProtocol: old fold tree: FOLD_TREE EDGE 1 229 -1 EDGE 1 230 1 EDGE 230 458 -1 EDGE 1 459 2 EDGE 459 687 -1 EDGE 1 688 3 EDGE 688 916 -1 EDGE 1 917 4 EDGE 917 1255 -1 EDGE 1 1256 5 EDGE 1256 1319 -1
protocols.docking.DockingProtocol:
protocols.docking.DockingProtocol: new fold tree: FOLD_TREE EDGE 1 229 -1 EDGE 229 230 1 EDGE 230 458 -1 EDGE 458 459 2 EDGE 459 548 -1 EDGE 548 687 -1 EDGE 548 1148 4 EDGE 687 688 3 EDGE 688 916 -1 EDGE 1148 917 -1 EDGE 1148 1255 -1 EDGE 1255 1256 5 EDGE 1256 1319 -1
protocols.docking.DockingProtocol:
protocols.docking.DockingInitialPerturbation: Reading options…
protocols.docking.DockingInitialPerturbation: dock_pert: true
protocols.docking.DockingInitialPerturbation: option[ docking::dock_pert ]()4 3
core.io.database: Database file opened: /usr/global/rosetta/rosetta3.1/rosetta_database/env_log.txt
core.io.database: Database file opened: /usr/global/rosetta/rosetta3.1/rosetta_database/cbeta_den.txt
core.io.database: Database file opened: /usr/global/rosetta/rosetta3.1/rosetta_database/pair_log.txt
core.io.database: Database file opened: /usr/global/rosetta/rosetta3.1/rosetta_database/cenpack_log.txt
protocols.docking.DockingInitialPerturbation: sliding into contact
protocols.docking.DockingInitialPerturbation: Moving away
protocols.moves.RigidBodyMover: Translate: Jump (before): RT -0.689405 0.597832 -0.409046 0.661045 0.750135 -0.0177809 0.296209 -0.282656 -0.912341 -23.3265 -22.274 48.2585
protocols.moves.RigidBodyMover: Translate: Jump (after): RT -0.689405 0.597832 -0.409046 0.661045 0.750135 -0.0177809 0.296209 -0.282656 -0.912341 -23.8252 -22.5823 49.0686
protocols.moves.RigidBodyMover: Translate: Jump (before): RT -0.689405 0.597832 -0.409046 0.661045 0.750135 -0.0177809 0.296209 -0.282656 -0.912341 -23.8252 -22.5823 49.0686
protocols.moves.RigidBodyMover: Translate: Jump (after): RT -0.689405 0.597832 -0.409046 0.661045 0.750135 -0.0177809 0.296209 -0.282656 -0.912341 -24.3239 -22.8905 49.8787
…
continues for a total 1000 lines of RigidBodyMover
…
protocols.docking.DockingInitialPerturbation: failed moving away with original vector. (:exclaim:)
Aborting DockingSlideIntoContact. (:exclaim:)(:eek:)(:exclaim:)
protocols.docking.DockingProtocol: finished initial perturbation
protocols.TrialMover: Acceptance rate: 1
protocols.TrialMover: Acceptance rate: 1
protocols.TrialMover: Acceptance rate: 1
protocols.TrialMover: Acceptance rate: 1
…
continues for a total 100 lines of TrialMover. (acceptance rate always = 1)
…
protocols.docking.DockingLowRes: in DockingLowRes.apply
Centroid Rigid Body Adaptiveprotocols.docking.DockingHighRes: in DockingHighRes.apply
protocols.docking.DockingHighRes: DOCK_MCMcore.pack.task: Packer task: initialize from command line()
core.pack.interaction_graph.interaction_graph_factory: Instantiating DensePDInteractionGraph
core.pack.pack_rotamers: built 0 rotamers at 0 positions.
core.pack.pack_rotamers: IG: 480 bytes
protocols.geometry.RB_geometry: centroids_by_jump_int called but no interface detected!!
protocols.geometry.RB_geometry: calling centroids_by_jump…
core.pack.task: Packer task: initialize from command line()
protocols.geometry.RB_geometry: centroids_by_jump_int called but no interface detected!!
…
…Repeats…
…
protocols.geometry.RB_geometry: centroids_by_jump_int called but no interface detected!!
protocols.geometry.RB_geometry: calling centroids_by_jump…
core.pack.task: Packer task: initialize from command line()
protocols.moves.RigidBodyMover: Translate: Jump (before): RT -0.826737 0.503775 0.250432 0.527971 0.848495 0.0361073 -0.194301 0.162072 -0.967461 -272.794 -177.095 452.414
protocols.moves.RigidBodyMover: Translate: Jump (after): RT -0.826737 0.503775 0.250432 0.527971 0.848495 0.0361073 -0.194301 0.162072 -0.967461 -770.71 -485.262 1263.04
protocols.moves.RigidBodyMover: Translate: Jump (before): RT -0.826737 0.503775 0.250432 0.527971 0.848495 0.0361073 -0.194301 0.162072 -0.967461 -272.794 -177.095 452.414
protocols.moves.RigidBodyMover: Translate: Jump (after): RT -0.826737 0.503775 0.250432 0.527971 0.848495 0.0361073 -0.194301 0.162072 -0.967461 -770.71 -485.262 1263.04
protocols.jobdist.main: Finished NC0_0001 in 505 seconds.It looks like it doesn’t think it is succeeding in moving away and thus it aborts sliding the ligand protein (chains EF) back towards the Receptor. Any thoughts as to what is causing this and/or how to prevent it?
-
July 26, 2010 at 9:08 pm #4506Anonymous
Hi I think I am having a similar problem with -dock_pert. Did anyone have an answer to this????
-
July 27, 2010 at 3:26 pm #4510Anonymous
Looking into the code in that region, i suspect that the code separating ABCD / EF is the culprit. I’ve asked some of the more docking-experienced people for help…
-
July 27, 2010 at 7:44 pm #4516Anonymous
Re: the use of “TER” card: in one of my latest runs I used the ppked file directly which didn’t have the TER line between the docking partners (FAC and BD). I used the flag -partners FAC_BD. this run was ok as far as I can tell, that is, it was able to find the docking partners properly without the correct TER line formatting. The question is is it necessary to use the TER line between the docking partners or is it enough just to use the flag. I used to add the TER line between the docking partners and also use the flag but it seems now the TER line may not be neessary??
(part of the pdb file I use for the run is below:
ATOM 2047 3HD1 LEU F 183 -4.727 51.468 50.201 1.00 0.00
ATOM 2048 1HD2 LEU F 183 -3.723 51.486 53.114 1.00 0.00
ATOM 2049 2HD2 LEU F 183 -5.368 51.013 52.623 1.00 0.00
ATOM 2050 3HD2 LEU F 183 -4.369 49.896 53.583 1.00 0.00
ATOM 2051 N ARG A 58 8.567 60.239 53.307 1.00 0.00
ATOM 2052 CA ARG A 58 8.457 61.689 52.936 1.00 0.00
ATOM 2053 C ARG A 58 8.204 62.580 54.153 1.00 0.00…….
ATOM 4098 1HD2 LEU A 183 13.225 67.944 53.114 1.00 0.00
ATOM 4099 2HD2 LEU A 183 14.457 66.756 52.623 1.00 0.00
ATOM 4100 3HD2 LEU A 183 14.925 68.179 53.583 1.00 0.00
ATOM 4101 N ARG C 58 -0.501 74.210 53.307 1.00 0.00
ATOM 4102 CA ARG C 58 -1.701 73.391 52.936 1.00 0.00
ATOM 4103 C ARG C 58 -2.346 72.726 54.153 1.00 0.00
………
ATOM 6148 1HD2 LEU C 183 -9.502 74.392 53.114 1.00 0.00
ATOM 6149 2HD2 LEU C 183 -9.089 76.053 52.623 1.00 0.00
ATOM 6150 3HD2 LEU C 183 -10.556 75.747 53.583 1.00 0.00
ATOM 6151 N GLU B 1 -28.704 17.452 68.716 1.00 0.00
ATOM 6152 CA GLU B 1 -27.344 17.691 69.205 1.00 0.00
ATOM 6153 C GLU B 1 -26.698 18.717 68.302 1.00 0.00……….
ATOM 7766 1HB SER B 121 3.824 9.133 56.018 1.00 0.00
ATOM 7767 2HB SER B 121 3.120 8.501 54.512 1.00 0.00
ATOM 7768 HG SER B 121 4.680 7.093 55.423 1.00 0.00
ATOM 7769 N ASP D 1 3.590 34.214 71.207 1.00 0.00
ATOM 7770 CA ASP D 1 2.674 33.242 71.806 1.00 0.00
ATOM 7771 C ASP D 1 2.893 33.246 73.296 1.00 0.00………
ATOM 9407 2HH1 ARG D 108 -8.681 -2.507 83.250 1.00 0.00
ATOM 9408 1HH2 ARG D 108 -5.513 -1.411 84.297 1.00 0.00
ATOM 9409 2HH2 ARG D 108 -6.397 -2.307 83.077 1.00 0.00
TER
# All scores below are weighted scores, not raw scores.
#BEGIN_POSE_ENERGIES_TABLE ox40-edited_0001……….
Cheers.
Thank you for looking into this smlewis. As an added note, which may or may not be relevant: I was able to run -docking_local_refine successfully before trying -dock_pert. However, when I first attempted -docking_local_refine, I did get some errors about “foldtree” which seemed to indicate it was having issues figuring out which protein was receptor/ligand. As far as I could gather, my input structures were formatted correctly with a “TER” line separating chains ABCD from EF. This error was resolved when I added the -docking_partners flag.
Thanks again. Please do let me know if you hear back anything…
-
October 18, 2011 at 8:21 pm #6144Anonymous
The TER record is not needed any longer. The partners flag is parsed and compared to the PDB ChainIDs in the input file. It’s important to note that the order of the chains in the partners flag must match the order of the chains in the PDB file.
-
-
August 9, 2010 at 4:14 pm #4560Anonymous
My usual contact for these questions graduated. I’m looking for a new person in that lab…
-
October 13, 2011 at 10:54 am #6126Anonymous
I would still be interested in resolving this issue. Any new ideas on what could be causing the problem?
-
October 13, 2011 at 1:50 pm #6127Anonymous
This thread is pretty old – have you tried it again in 3.3? Docking got updated between 3.2 and 3.3, I think. I sent it along to one of the docking people.
-
October 14, 2011 at 4:33 am #6131Anonymous
Thanks smlewis for your prompt attention. I am actually using 3.1 but since it is installed on a cluster, updating will require administrative difficulties. In any case, if anyone else is having similar difficulty: after exhaustive trials of different combinations I think I can get dock_pert to work if 1)all the chains in the receptor molecule are named “A” 2) “TER” is placed in between the receptor and ligand proteins in the input pdb file 3) the -partners flag is removed.
-
October 18, 2011 at 8:24 pm #6145Anonymous
If you could try running a few trajectories on a local machine to confirm if the issue still exists in v3.3, we can figure out what’s going on here.
-
-
AuthorPosts
- You must be logged in to reply to this topic.