I am doing SymDock using Rosetta 3.5. I wonder what the option really does:
-symmetry:initialize_rigid_body_dofs - Initialize the rigid body configuration according to the symmetry definition file.
I actually ran SymDock using diff. option combinations. When initialize_rigid_body_dofs is set, the assemblies look very different, otherwise more homogeneous. So I concluded that the option does initialization.
But, when I also set some distance constraints that the original orientation of the input rigid body wouldn't satisfy, SymDock could also generate assemblies satisfying the distance constraints, although initialize_rigid_body_dofs was NOT set. In all experiments, perturb_rigid_body_dofs was not set.
So my question is, why is the input rigid body initialized/randomized no matter the option is set or not?
The -initialize_rigid_body_dofs option is read during the initial perturbation stage of symmetric docking. It's actually the very first step. It's then followed by the rigid body dof perturbation, if the -symmetry:perturb_rigid_body_dofs flag is specified on the command line, followed by the slide into contact step, if applicable.
That said, I think the sense of the -initialize_rigid_body_dofs is actually reversed from what might be implied by the discription. In my reading of things, if -initialize_rigid_body_dofs is set, the initial degrees of freedom are randomized. That is, the degrees of freedom from the symmetry definition file are initialized by randomizing them, rather than (re)setting them to the particular values listed in the symdef file.
So there is a difference between setting/not setting the option, but it might not be one that has a substantial effect on results, depending on the system. With/without the initial randomization, the docking protocol will be altering the rigid body degrees of freedom as part of the docking process. Since it's stochastic, a different starting position may result in a different output distribution. Randomizing the starting position make make it more likely you'll escape a local minimum - but it will also make it more likely that you'll find false minima, if your starting structure is already close to optimal. The trade off depends on your starting structure. In some cases it might not matter all that much because the structural minima are well defined enough that there's a clear funnel to them, meaning your exact starting position is not too important.
Why is perturbation still necessary if the inital perturbation is randomized? Does one need to set both -initialize_rigid_body_dofs and -perturb_rigid_body_dofs ?
So is this understanding correct: there are at least three DOFs randomization processes in Rosetta docking:
1. the initial randomization of DOFs ( -initialize_rigid_body_dofs );
2. the perturbation of rigid body DOFs ( -perturb_rigid_body_dofs );
3. the internal docking protocol ( option?).
The difference between the two has to do with what happens to the input position. As I understand it, with the -initialize_rigid_body_dofs the input rigid body position is ignored, and reset to be with whatever particular "box" is set for sampling. With -perturb_rigid_body_dofs, the initial position is kept, and a random adjustment is added to the location. Both of these are energy un-directed: that is, the movements don't consider the final energy of the complex when the determine where to put the binding partners. This is in contrast to the docking protocol proler, which does move the rigid body orientation, but does so in an energy directed fashion - the complex energy is considered when looking at accepting/rejecting the changed complex.
You're right that having both -initialize_rigid_body_dofs and -perturb_rigid_body_dofs on at the same time is likely superflous to having just -initialize_rigid_body_dofs on - once you've randomized the positioning of the complex, adding additional purturbation on top of it doesn't increase/decrease the randomization of position. (That said, details matter, as the precise settings of the purturbation step may cause the partners to move out of the region which is accessible to -initialize_rigid_body_dofs alone.) It probably won't hurt, either, so that's why you may see them both on in protocols.