low resolution blind protein-protein docking with a ligand

[Anonymous]

We’re trying to repeat published docking results with Cytochrome C & Human neuroglobin, because we want to compare that to docking a different globin to Cyt C. Low resolution blind docking of the protein only [no heme groups] produces 1000 structures 2-3 days on the linux station we’re using. However, the interface region in the published structure includes the space in which the hemes sit, so we think including the hemes will be more accurate. With the help of kind people on this forum, we were able to get to the requisite params files & docking partner syntax. The blind docking procress, however, has slowed down dramatically! In a week, it only produced 7 structures & was working on the 8th. Is this normal? Is there anything we can do about it? The all-atom refinement w/out the heme was very much slower than the low-resolution process, so I hate to think what might happen if we just stick it out. Thanks for any help!

[Anonymous]

A) The first thing to check if your code is slow is if it’s a release-mode compile. It should say release and NOT say debug in the executeable file name. (I don’t recall us suggesting you tweak compiling, so I doubt this is the problem).

I believe we got to a point where you have a centroid version of your heme, and are doing standard docking with the centroid heme in place (followed by fullatom docking with the fullatom heme in place; all as part of one trajectory). Is this correct? Is your slowdown in the fullatom or centroid phase? I think you can tease out where the code is by what it is outputting. Briefly, DockingLowRes is the centroid phase, and DockingHighRes is the fullatom phase. If you see core.pack.task, that’s high-res. We can try injecting some timing statements into the code to see where the slowdown is.

You may want to go ahead and post your exact command line for later reference.

[Anonymous]

We did inadvertently compile in debug mode [this is was the first time we’d ever built Rosetta] & were so anxious to use it, that we left it at that rather than do it again. It may be time to redo & update while we’re at it.

Yes, you did help us get to a centroid heme. Here are the flags we’re using:
@localhost lores-hem]$ cat flags
-in
-file
-s cytHNbHEx.pdb
# the input file should have two single, complete chains A and B
# for Ab molecules (with L+H chains) use -docking::partners flag below
-path
-database /opt/rosetta/rosetta_database/
# customize this to point to your installation directory
-extra_res_fa /home/newhojs/Desktop/RosettaParams/HEC.params /home/newhojs/Desktop/RosettaParams/HEM.params
-extra_res_cen /home/newhojs/Desktop/RosettaParams/loresHEx/HEC.cen.params /home/newhojs/Desktop/RosettaParams/loresHEx/HEM.cen.params
-docking
-randomize1
# rotates partner1 (chain A) before docking proteins together
#-randomize2
# rotates partner2 (chain before docking proteins together
-partners AD_BE
# defines docking partners by ChainID; see manual
-out
-nstruct 1000
# this should be set to a large number for effective sampling
-mute core.util.prof
# reduces copious output, without overdoing as with -mute all
-file
-o dock_output
# scorefile will be named dock_output.sc (or .fasc for fullatom)
#-fullatom
# fullatom is commented out for fast low-res "centroid mode" run
I don’t think we’re using full-atom mode. I can’t really attach the log file because it’s over 1MB & I’d prefer to compress it, but compressed file extensions aren’t supported by the forum software. So I grepped: $ grep -n pack *.log
7:core.io.database: Database file opened: /opt/rosetta/rosetta_database/cenpack_log.txt
279:core.pack.task: Packer task: initialize from command line()
535:core.pack.task: Packer task: initialize from command line()
552:core.io.database: Database file opened: /opt/rosetta/rosetta_database/cenpack_log.txt
When I tail the log file: tail *.log
protocols.moves.RigidBodyMover: Translate: Jump (before): RT 0.636906 -0.754867 -0.156607 0.765473 0.595051 0.24488 -0.0916633 -0.275844 0.956822 72.6401 -22.8441 -11.3836
protocols.moves.RigidBodyMover: Translate: Jump (after): RT 0.636906 -0.754867 -0.156607 0.765473 0.595051 0.24488 -0.0916633 -0.275844 0.956822 71.6688 -22.6469 -11.2505
protocols.moves.RigidBodyMover: Translate: Jump (before): RT 0.636906 -0.754867 -0.156607 0.765473 0.595051 0.24488 -0.0916633 -0.275844 0.956822 71.6688 -22.6469 -11.2505
protocols.moves.RigidBodyMover: Translate: Jump (after): RT 0.636906 -0.754867 -0.156607 0.765473 0.595051 0.24488 -0.0916633 -0.275844 0.956822 70.6975 -22.4497 -11.1174
protocols.moves.RigidBodyMover: Translate: Jump (before): RT 0.636906 -0.754867 -0.156607 0.765473 0.595051 0.24488 -0.0916633 -0.275844 0.956822 70.6975 -22.4497 -11.1174
protocols.moves.RigidBodyMover: Translate: Jump (after): RT 0.636906 -0.754867 -0.156607 0.765473 0.595051 0.24488 -0.0916633 -0.275844 0.956822 69.7263 -22.2526 -10.9843
protocols.moves.RigidBodyMover: Translate: Jump (before): RT 0.636906 -0.754867 -0.156607 0.765473 0.595051 0.24488 -0.0916633 -0.275844 0.956822 69.7263 -22.2526 -10.9843
protocols.moves.RigidBodyMover: Translate: Jump (after): RT 0.636906 -0.754867 -0.156607 0.765473 0.595051 0.24488 -0.0916633 -0.275844 0.956822 68.755 -22.0554 -10.8511
protocols.moves.RigidBodyMover: Translate: Jump (before): RT 0.636906 -0.754867 -0.156607 0.765473 0.595051 0.24488 -0.0916633 -0.275844 0.956822 68.755 -22.0554 -10.8511
protocols.moves.RigidBodyMover: Translate: Jump (after): RT 0.636906 -0.754867 -0.156607 0.765473 0.595051 0.24488 -0.0916633 -0.275844 0.956822

It trails off because we killed the job. There are a LOT of lines that resemble this one in the log file…

Thanks for your help!

[Anonymous]

“We did inadvertently compile in debug mode [this is was the first time we’d ever built Rosetta] & were so anxious to use it, that we left it at that rather than do it again. It may be time to redo & update while we’re at it.”

You should get a 10x or better performance increase off-the-bat from release mode. I won’t say who, but there are big names in the field who’ve been bitten by this issue. I guess we need to publicize it better…

You can lie about the extension: if your file is “log.gz”, rename it “log.gz.txt” and the attacher will allow it.

You don’t need to post the log for now; this is enough information to demonstrate that you are clearly reaching the fullatom part of the protocol. I was concerned that you had a weird bug where the centroid ligand was causing a problem.

It is challenging to diagnose WHERE it is spending the extra time; let’s see if release mode fixes the problem before we try harder.

[Anonymous]

Sorry I don’t have much time to look into this, but here’s a couple thoughts:

– my guess, without looking at the logfiles or scorefiles, is that a docking filter is being tripped up and it is having to re-do the decoys at some stage in the docking algorithm. When I used interfacial ligands, the differences in computational time was negligible because the system size was largely unchanged.

– did you look any of the outputted decoys? Another related explanation could be the fold tree or dock jump is incorrectly specified and the heme is being treated as the second partner, but since its very restricted from translation/rotation movements dock-perturbations are tripping the docking filters and restarting low-res mode.

hope this helps.

[Anonymous]

We downloaded the update & compiled it release. The full atom speeds are now just fine. Thanks for the suggestion!

[Author]

Posts