Reply To: Modeling phosphate ion binding site in protein.

[Anonymous]

Specifying the native is optional. The docking should still work without it, you’ll just not get some of the diagnostic information about how close the predicted conformation is to the native conformation. Supplying a native should have absolutely no effect on which structures (or their energies) you get out from the prediction.

For the jump issue, each (covalently connected) molecule should be it’s own chain. My guess is that your phosphate is listed as being part of the same chain as the protein in the input PDB. Usually we set the protein to be chain A, and the ligand (phosphate in your case) to be chain X – although any combination where the ligand is the last chain (alphabetically) in the file should work.

Regarding flags, the ones listed in the documentation (http://www.rosettacommons.org/manuals/archive/rosetta3.2.1_user_guide/app_ligand_dock.html) are the recommended ones to start with. I’m not quite sure what you’re asking about with regard to cycles. If you’re talking about the total number of decoys to produce, 5000 trajectories (e.g. ten runs each with -nstruct 500, although you can mix and match based on how many processors you have available) is somewhat of a standard, for tricky cases (possibly your phosphate) you may want to increase that. What I’d recommend is to do the 5000 trajectories for the controls, then plot the predicted binding energy against the rmsd of the output ligand to native. Ideally you should get a clear “funnel” like plot, where the spout of the funnel points to the low energy, low rmsd corner. If not, you’ll have to change your docking proceedure, say by increasing the sampling (the number of trajectories you run).

P.S. I have access to a CONDOR cluster, so when I do docking I tend to use the arls.py setup script. Even if you don’t use condor, you can still use arls.py to set things up, and then massage the condor script to work with your cluster or even just the command line.