- This topic has 2 replies, 2 voices, and was last updated 9 years, 5 months ago by Anonymous.
June 20, 2014 at 7:16 am #1925Anonymous
I am docking several different proteins and before docking I use fastrelax to relax the individual proteins.
Fir some of the proteins (they are all less than 200 aa) Fastrelax takes extreemly long to generate 25 poses.
For one in particular following error pops up:
core.pack.task: Packer task: initialize from command line()
core.pack.interaction_graph.interaction_graph_factory: Instantiating LinearMemoryInteractionGraph
core.pack.pack_rotamers: built 9099 rotamers at 245 positions.
core.pack.pack_rotamers: IG: 7504384 bytes
core.optimization.Minimizer: reset HESSIN from failed line search
HESSIN for (i,i): 1 1.21939
G for (i): 1 -1.63693e-06
HESSIN for (i,i): 2 1.0625
G for (i): 2 -0.000937159
$direxe/rosetta_scripts.default.linuxgccrelease @relax.flags -restore_pre_talaris_2013_behavior -s $dirunbound -parser:protocol relax_saxs.xml -nstruct 25 -database $dirdata >& relax.log
I was wondering if B-factors can influence the speed of Relax?
To note all proteins has been cleaned and only contain the structure itself.
Last for the particular protein giving extra problems I have attached the PDB and am particular interested in what this error mean. I have tried changing the B factor to 1 and removing the extra column with information but it does not help..
I would greatly appreciate any comments.
July 2, 2014 at 4:12 pm #10143Anonymous
B factors should be ignored for most Rosetta applications – it’s only if you’re using the density refinement applications that they come into play. (Aside from other applications which may store additional information in the B-factor column.)
The slow speed and errors you see are probably due to the quality of the starting structure. It’s likely in a bad position for Rosetta, so FastRelax has a hard time working with it.
What I’d recommend doing is changing the minimizer type being used during FastRelax add the option “mintype=lbfgs_armijo_nonmonotone”. The newer lbfgs version seems to do a better job than the (default) dfpmin version, both in terms of speed and the chance of errors. (In fact, there’s no real reason not to use the lbfgs version – defaults are for dfpmin purely for historical reasons.)
Also, depending on the downstream applications you may want to consider doing the relax with the talaris2013 scorefunction (as opposed to score12), and removing the -restore_pre_talaris_2013_behavior option. Talaris includes some changes which means that minimization proceeds smoother, and encounters certain types of issues less often.
July 3, 2014 at 2:21 pm #10150Anonymous
Thank you for your response!
ACtually comparing the run between score12 and Talaris2013, score12 is still the fastest by far (400 sec pr pose vs 1400 sec per pose). As I am proceeding with docking where I need the restore_pre_talaris flag, i guess I am good with Fastrelax using score12. I have added the flag -ignore_unrecognized_res plus the flag you recommended above and as of now things seem to be running smoother without the
“core.optimization.Minimizer: reset HESSIN from failed line search”
error message, which makes the entire fastrelax process faster as well:)
- You must be logged in to reply to this topic.