You are here

Fastrelax problem

3 posts / 0 new
Last post
Fastrelax problem

Hi all
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

<InitializeFromCommandline name=ifcl />
<RestrictToRepacking name=rtr />
<FastRelax name=relax repeats=8 scorefxn=score12 task_operations=ifcl,rtr />
<Add mover=relax />

-ignore_zero_occupancy false
-linmem_ig 10
-corrections:score:use_bicubic_interpolation true

$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.



1ACB_r_u.pdb138.79 KB
Post Situation: 
Fri, 2014-06-20 00:16

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.

Wed, 2014-07-02 09:12

Hi Moretti
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:)

Thu, 2014-07-03 07:21