too many constraints result in no output pose

[Anonymous]

Hi,everyone.
When I applied 11 distance constraints, get from chemical cross-linking assay, into Protein-Protein docking, there is no output pose and also no error reported.
Here is the output log:
“””
protocols.jd2.JobDistributor: poseinp_0001 reported failure and will retry
… …
protocols.jd2.JobDistributor: poseinp_0012 reported failure and will retry
“””
The maximum sum of all 11 constraints should be 9.5 REU. I don`t know whether it is too large. But when no constraint or only 1 constraint added, there are plenty of output poses. And among these output 100 poses, the “total_score” ranges from -62.304 to -90.282. It makes me to assume the energy barrier MC sampling can overcome in my case should be around 30REU. If so, why a max of 9.5 REU constraint can not be accepted ? (I chose ‘-low_res_protocol_only’ mode)
There is another line in log :
“””
protocols.docking.DockingProtocol: Scoretype: atom_pair_constraint score: 9.5, cutoff: 1
“””
I don`t know what ‘cutoff: 1’ means and whether it results in the no output poses problem. How to change it ?
Thanks very much !

[Anonymous]

You’ve absolutely found the root of the problem from the log file – thanks!

You may be able to fix this by deactivating ALL docking filters from command line with -docking:no_filters.

Unfortunately I can’t see a way to fix the constraint score cutoff specifically from command line. If you’re willing to edit code, you can edit line 50 in src/protocols/docking/DockFilters.hh. It should read:

void set_use_constraints( bool flag, core::Real cutoff=1.0 ); /// @brief add docking constraints

As best I can tell, that 1.0 is the cutoff that’s causing you problems. The simplest way to remove the cutoff is change that 1.0 to 10.0 or 100.0, recompile the code (scons bin mode=release), and re-run your docking.

If you’re comfortable with C++ we can discuss hacking in a command-line option control for you instead.

Also: if your unconstrained total scores are in the 60-90 range, a max constraint score of 9.5 seems very reasonable to me.

[Anonymous]

Flexpepdock cst similar problem :i was trying to use the cst file in rosetta flexpepdock.When i try 20 structures score file includes the atom pair distances. But for larger number of decoys(200) it termiates with error “”core.optimization.LineMinimizer: (0) BRENT exceed maximum iterations. 100”
My flags were -constraints:cst_file c.cst -constraints:cst_fa_file c.cst -constraints:cst_weight 10.0 -constraints:cst_fa_weight 10.0

AtomPair H 16 H 129 GAUSSIANFUNC 12.01 3.0
AtomPair H 16 H 130 GAUSSIANFUNC 12.62 3.0
AtomPair H 16 H 131 GAUSSIANFUNC 12.48 3.0
AtomPair H 16 H 132 GAUSSIANFUNC 12.92 3.0
AtomPair H 16 H 133 GAUSSIANFUNC 14.36 3.0
AtomPair H 16 H 134 GAUSSIANFUNC 16.11 3.0

[Anonymous]

Thanks very much smlewis !
I have tried to add ‘-docking:no_filters’ or ‘-no_filters’ in flag file. But the constraint score cutoff problem still exist. So I edit DockFilters.hh code (cutoff = 100) and recompile. Then I tested with ‘-out:nstruct 1000’ to write out exactly 1000 pose files. Though there are 71 line in log saying ‘… reported failure and will retry’, finally every pose was ‘reported success’ within the default value 10 cycle. Actually no pose was retry for more than 2 cycle.

When I check the output score file(.fasc), here comes another puzzle. The constraint score is 9.5 (the max constraint score) for 716 out of 1000 poses, which means all the distance requirements were not satisfied at all. And for the rest 284 poses the constraint score range from 7.81 to 9.49.
I doubt whether my biased sampling is efficient or not.
PS: ‘Acceptance rate’ in logfile ranged from 0.08 to 0.86. ‘total score’ ranged from -55 to -90.
Should I set the cutoff in DockFilter.hh to 9.5 ? Or should I make some changes to my current constraints?

[Anonymous]

If Rosetta is finding few models that satisfy your constraints well, it means that Rosetta thinks the system is frustrated: either the constraints cannot all be satisfied at once, or there is a very small cluster of conformations that will do it that Rosetta didn’t find, or the conformations that will do it are just beyond a relatively large energy barrier that minimization can’t get through.

The first thing I would try here is increasing your constraint weight by a factor of 10 or 100 just to see if it starts satisfying them better. This will do bad things to the rest of the scorefunction (for example, it may allow more clashes to satisfy the constraints) but it will address whether it’s _impossible_ to satisfy them simultaneously, or just really hard.

The next thing to try is to set the CONSTANTFUNC capping values much higher (like 100 or 1000). If you plot out the combined BOUNDED+CONSTANT func, you’ll see that there’s a flat zero basin of satisfied constraint, a region of increasing score where the constraint is just out of range, and another flat region where CONSTANT takes over. For model discrimination, this constraint works at any distance. But, for minimization, the constraint only really functions in the increasing region: the other regions are flat, have zero derivatives, and do not inform minimization. This means the minimizer can’t help optimize poses that aren’t already close to a satisfied constraint; how close “close” is will depend on what values you use for the functions. It may be that this increasing region is so small the minimizer never helps with the constraints, which will hugely increase the sampling you have to do to luck into a conformation that happens to satisfy the constraint.

Changing the cutoff in DockFilter to 9.5 will have little effect given your current constraints (they top out at 9.5 anyway). I would leave it high while you explore constraint space.

[Anonymous]

How many structures does it generate before failure? It sounds like some conformations are frustrated and it occasionally fails in minimization…if it fails on 1 in 100 on average then it will usually crash for nstruct 200 and usually not for nstruct 20.

I’m surprised it’s using the LineMinimizer at all; you can try -run:min_type dfpmin_armijo, but I don’t know if it will take effect for flexpepdock. If it does, it will run a different minimizer that reports bad minimizations without crashing.

You can always try softer or capped constraints (and should almost certainly try the latter).

[Author]

Posts