Docking with constraints

Member Site › Forums › Rosetta 3 › Rosetta 3 – Applications › Docking with constraints

Viewing 4 reply threads
  • Author
    Posts
    • April 2, 2013 at 4:45 pm #1548
      Anonymous

        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

      • April 2, 2013 at 5:26 pm #8586
        Anonymous

          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.

        • April 2, 2013 at 7:22 pm #8591
          Anonymous

            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

          • April 2, 2013 at 7:27 pm #8592
            Anonymous

              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.

            • April 2, 2013 at 9:29 pm #8595
              Anonymous

                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

              • April 2, 2013 at 6:20 pm #8590
                Anonymous

                  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

                • April 2, 2013 at 8:14 pm #8593
                  Anonymous

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

                • Author
                  Posts
                Viewing 4 reply threads
                • You must be logged in to reply to this topic.