# Optim.jl returns \`Stopped by an increasing objective: true\`

**URL:** <https://discourse.julialang.org/t/optim-jl-returns-stopped-by-an-increasing-objective-true/15428>\
**Category:** Optimization (Mathematical)\
**Tags:** optim\
**Created:** [September 24, 2018, 3:51pm UTC](https://discourse.julialang.org/t/optim-jl-returns-stopped-by-an-increasing-objective-true/15428 "2018-09-24T15:51:34Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![gasagna](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gasagna/32/1275_2.png) [@gasagna](https://discourse.julialang.org/u/gasagna)\
**Post date:** [September 24, 2018, 3:51pm UTC](https://discourse.julialang.org/t/optim-jl-returns-stopped-by-an-increasing-objective-true/15428/1 "2018-09-24T15:51:34Z")

</div>

Hi,

Under exactly what conditions does `optimize` in Optim.jl return `Stopped by an increasing objective: true`?

I have a fairly complicated optimisation problem using LBFGS which terminates at some point with this statement. The function provided to the solver computes the discrete gradient of the objective function and I have checked that the gradient is indeed a descent direction. Does the line search algorithm play any role here?

---

<div class="post-metadata">

**Author:** ![jcook](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jcook/32/18211_2.png) [@jcook](https://discourse.julialang.org/u/jcook)\
**Post date:** [September 24, 2018, 4:10pm UTC](https://discourse.julialang.org/t/optim-jl-returns-stopped-by-an-increasing-objective-true/15428/2 "2018-09-24T16:10:19Z")

</div>

Have you tried constructing an `Optim.Options` with `Optim.Options(allow_f_increases=true)`? Also maybe try `successive_f_tol=n` where `n>1`? I’m not sure what the latter does though. Worth an experiment maybe?

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [September 24, 2018, 4:16pm UTC](https://discourse.julialang.org/t/optim-jl-returns-stopped-by-an-increasing-objective-true/15428/3 "2018-09-24T16:16:51Z")

</div>

> Does the line search algorithm play any role here?

I’m no expect, but I imagine the line search algorithm plays a role. BackTracking, for example, takes aggressive steps, and then (if the objective increased), it automatically back tracks until it sees a decrease in the objective.

---

<div class="post-metadata">

**Author:** ![gasagna](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gasagna/32/1275_2.png) [@gasagna](https://discourse.julialang.org/u/gasagna)\
**Post date:** [September 24, 2018, 5:15pm UTC](https://discourse.julialang.org/t/optim-jl-returns-stopped-by-an-increasing-objective-true/15428/4 "2018-09-24T17:15:39Z")

</div>

Thanks. This works, although it does not make me feel comfortable. Why is the optimiser thinking my gradient is not a descent direction? Are there tolerances in the line search algorithm that can be tuned to achieve the same effect? At the moment I am using

```julia
res = Optim.optimize(f, g, x0, 
                     LBFGS(m=100, linesearch=LineSearches.BackTracking(), 
                           alphaguess=LineSearches.InitialStatic(scaled=true, alpha=0.1)), 
                     Optim.Options(show_trace=true, allow_f_increases=true, iterations=1000, f_tol=1e-10, x_tol=1e-10))

```

An off-topic question. I have noticed that when the optimisation results are printed, the norm of the gradient `|g(x)|` that gets displayed does not match with the norm of the gradient that can be computed afterwards from the optimizer. Any known reasons for this?

---

<div class="post-metadata">

**Author:** ![jcook](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jcook/32/18211_2.png) [@jcook](https://discourse.julialang.org/u/jcook)\
**Post date:** [September 24, 2018, 5:42pm UTC](https://discourse.julialang.org/t/optim-jl-returns-stopped-by-an-increasing-objective-true/15428/5 "2018-09-24T17:42:03Z")

</div>

No probs. I think the algorithm is getting stuck in a local minimum that does not satisfy your stopping criteria, and setting `allow_f_increases=true` lets the algorithm dig itself out of a hole.

> An off-topic question. I have noticed that when the optimisation results are printed, the norm of the gradient `|g(x)|` that gets displayed does not match with the norm of the gradient that can be computed afterwards from the optimizer. Any known reasons for this?

Perhaps it displays `|g(x)|` of the step before the final result? I suppose it wouldn’t bother calculating `g` if `f` satisfies a stopping criterion.

I can’t speak fo the `linesearch` part of all this. I’ve never looked into them.

---

<div class="post-metadata">

**Author:** ![pkofod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pkofod/32/2179_2.png) [@pkofod](https://discourse.julialang.org/u/pkofod)\
**Post date:** [September 26, 2018, 11:54am UTC](https://discourse.julialang.org/t/optim-jl-returns-stopped-by-an-increasing-objective-true/15428/6 "2018-09-26T11:54:56Z")

</div>

Can you post your actual output?