You are here

Docking with constraints

7 posts / 0 new
Last post
Docking with constraints
#1

Hi,

I've tried to run rosetta docking with constraints. But in the output files it seems that only the first decoy fits the constraints while all the other decoys don't. Could someone help me figure this out?

My flags:
-s input/2ERK_06092.pdb
-ex1
-ex2aro
-docking_local_refine
-dock_pert 3 8
-spin
-nstruct 10
-no_filters
-constraints:cst_file input/distance_constraint
-out:overwrite
-out:file:fullatom
-out:file:scorefile score_dock.fsc
-out:file:silent decoys_dock.out
-mute core.io.database
-mute core.util.prof

My constraint file:
AtomPair CA 185A CA 358B HARMONIC 10 1
AtomPair CA 261A CA 440B HARMONIC 10 1

In the log file, I can see that rosetta did read in the constraint file, but only once before the docking protocols:

protocols.docking.DockingProtocol: (1) old fold tree: FOLD_TREE EDGE 1 353 -1 EDGE 1 354 1 EDGE 354 454 -1
protocols.docking.DockingProtocol: (1)
protocols.docking.DockingProtocol: (1) new fold tree: FOLD_TREE EDGE 1 143 -1 EDGE 143 353 -1 EDGE 143 445 1 EDGE 445 454 -1 EDGE 445 354 -1
protocols.docking.DockingProtocol: (1)
protocols.docking.DockingProtocol: (1) setting up the constraint set mover
core.io.constraints: (1) read constraints from input/distance_constraint
core.io.constraints: (1) read constraints section --NO_SECTION---
core.io.constraints: (1) no section header [ xxx ] found, try reading line-based format... DON'T MIX
core.io.constraints: (1) read constraints from input/distance_constraint

In the output score file, the "atom_pair_constraint" column:
atom_pair_constraint
4.210
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
0.000
Only the first decoy fits close to the constraints, decoys 2 to 10 don't fit the constraints at all even though the "atom_pair_constraint" score is 0.

Many thanks,

Yisong

Post Situation: 
Tue, 2013-04-02 09:45
ytao

What is the reported weight for your constraints column? I don't see a weight flag in your inputs. Try -cst_weight 10 or -cst_fa_weight 10. I don't understand why it would behave this way, but if those flags don't fix it I can poke around.

I see that you are using docking_local_refine (only fullatom docking) - you may also wish to try -cst_fa_file instead of / in addition to cst_file. Many protocols distinguish centroid mode and fullatom mode constraints in that fashion; I'm not sure off the top of my head if docking does or not.

Tue, 2013-04-02 10:26
smlewis

Hi Steve,
The reported weight for atom_pair_constraint is 1. Using -cst_weight 10 did change the weight to 10, but did not change the weird behavior that the constraints were only used in first decoy.
Using -cst_fa_file and -cst_fa_weight did not help either, rosetta did not report any error but completely ignored the constraint file during the run (the log file did not show any info about reading in the constraint file).

Yisong

Tue, 2013-04-02 11:20
ytao

Update:

This issue seems to be system-related. I tested the same inputs and flags on two other linux computers and they both ran properly (all decoys have used the constraints).

I recompiled rosetta 3.4 on the computer(mac) that had the issue but the problem still remains. I guess I'll just stick to the linux systems for now.

Thanks,

Yisong

Tue, 2013-04-02 12:22
ytao

I looked at your flags again and spotted two problems. First, -no_filters is generally meant for debugging, I am not sure you want it here. Second, you are using:

-docking_local_refine
-dock_pert 3 8
-spin

You can't use all three of those. If you want only fullatom refinement (small changes), use -docking_local_refine (it skips the centroid step). If you want the full docking protocol, leave -docking_local_refine out and leave pert/spin in (that still does refinement! It just doesn't do ONLY refinement.).

I was able to reproduce your bug using -local_refine_only, but NOT using the full protocol. I am testing if it is still present in trunk; if so I will file a bug report.

Tue, 2013-04-02 12:27
smlewis

You're right!
The bug happens (here on my mac) only when -docking_local_refine is turned on.

Tue, 2013-04-02 13:14
ytao

As a workaround, try -reinitialize_mover_for_each_job - this works in trunk and probably for 3.4. I have filed a bug report. https://carbon.structbio.vanderbilt.edu/mantisbt/view.php?id=241

Tue, 2013-04-02 14:29
smlewis