Regarding the efficiency of the new low resolution ligand-docking movement “Transform”.

The first thing to know is that the red line in Figure 3 (the one that peaks around 10s) is actually the Transform/MIN protocol, rather than the Transform/MCM protocol. Adding the Monte Carlo steps to the full atom portion of the protocol changes the average runtime to more along the lines of 18-20s. That accounts for ~2 fold speed difference, but doesn’t explain most of what you’re seeing. 

What computer are you running it on? If it’s a laptop or a relatively older desktop model, then you’ll expect that there will be some slowdown versus the reported timings. (Which are probably done on a higher-end desktop machine.)  Do you have a slow hard drive, or are trying to access something like a remote disk? File IO might slow things down. You might want to try omitting  the -qsar:grid_dir option, and see if disk access there is hurting you.

Also, what type of compliation are you running? If you’re using something like rosetta_scripts.linuxgccdebug versus rosetta_scripts.linuxgccrelease, that could account for a large amount of the slowdown, as the debug mode compilation adds a bunch of extra checks that can slow down runs.

You might also want to try is to add the option -analytic_etable_evaluation and see if that helps. With current versions of Rosetta and -restore_pre_talaris_2013_behavior true, Rosetta uses a lot of memory. If your computer doesn’t have enough memory, then it will swap to disk, which will *greatly* slow things down. The -analytic_etable_evaluation should greatly reduce the amount of memory used.

If none of that works, check is the tracer output. Are there any warnings or errors that might be giving you issues? Are there certain points where things slows down or “hangs”?  Using Rosetta 3.8, I’m able to run the protocol capture docks in under 20s per output structure.

The first thing to know is that the red line in Figure 3 (the one that peaks around 10s) is actually the Transform/MIN protocol, rather than the Transform/MCM protocol. Adding the Monte Carlo steps to the full atom portion of the protocol changes the average runtime to more along the lines of 18-20s. That accounts for ~2 fold speed difference, but doesn’t explain most of what you’re seeing. 

What computer are you running it on? If it’s a laptop or a relatively older desktop model, then you’ll expect that there will be some slowdown versus the reported timings. (Which are probably done on a higher-end desktop machine.)  Do you have a slow hard drive, or are trying to access something like a remote disk? File IO might slow things down. You might want to try omitting  the -qsar:grid_dir option, and see if disk access there is hurting you.

Also, what type of compliation are you running? If you’re using something like rosetta_scripts.linuxgccdebug versus rosetta_scripts.linuxgccrelease, that could account for a large amount of the slowdown, as the debug mode compilation adds a bunch of extra checks that can slow down runs.

You might also want to try is to add the option -analytic_etable_evaluation and see if that helps. With current versions of Rosetta and -restore_pre_talaris_2013_behavior true, Rosetta uses a lot of memory. If your computer doesn’t have enough memory, then it will swap to disk, which will *greatly* slow things down. The -analytic_etable_evaluation should greatly reduce the amount of memory used.

If none of that works, check is the tracer output. Are there any warnings or errors that might be giving you issues? Are there certain points where things slows down or “hangs”?  Using Rosetta 3.8, I’m able to run the protocol capture docks in under 20s per output structure.

The first thing to know is that the red line in Figure 3 (the one that peaks around 10s) is actually the Transform/MIN protocol, rather than the Transform/MCM protocol. Adding the Monte Carlo steps to the full atom portion of the protocol changes the average runtime to more along the lines of 18-20s. That accounts for ~2 fold speed difference, but doesn’t explain most of what you’re seeing. 

What computer are you running it on? If it’s a laptop or a relatively older desktop model, then you’ll expect that there will be some slowdown versus the reported timings. (Which are probably done on a higher-end desktop machine.)  Do you have a slow hard drive, or are trying to access something like a remote disk? File IO might slow things down. You might want to try omitting  the -qsar:grid_dir option, and see if disk access there is hurting you.

Also, what type of compliation are you running? If you’re using something like rosetta_scripts.linuxgccdebug versus rosetta_scripts.linuxgccrelease, that could account for a large amount of the slowdown, as the debug mode compilation adds a bunch of extra checks that can slow down runs.

You might also want to try is to add the option -analytic_etable_evaluation and see if that helps. With current versions of Rosetta and -restore_pre_talaris_2013_behavior true, Rosetta uses a lot of memory. If your computer doesn’t have enough memory, then it will swap to disk, which will *greatly* slow things down. The -analytic_etable_evaluation should greatly reduce the amount of memory used.

If none of that works, check is the tracer output. Are there any warnings or errors that might be giving you issues? Are there certain points where things slows down or “hangs”?  Using Rosetta 3.8, I’m able to run the protocol capture docks in under 20s per output structure.