# Gradient rise was obtained by optim.jl package optimization

**URL:** <https://discourse.julialang.org/t/gradient-rise-was-obtained-by-optim-jl-package-optimization/69548>\
**Category:** General Usage\
**Tags:** package, optimization\
**Created:** [October 11, 2021, 9:07am UTC](https://discourse.julialang.org/t/gradient-rise-was-obtained-by-optim-jl-package-optimization/69548 "2021-10-11T09:07:21Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![F-YF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/f-yf/32/17363_2.png) [@F-YF](https://discourse.julialang.org/u/F-YF)\
**Post date:** [October 21, 2021, 2:53am UTC](https://discourse.julialang.org/t/gradient-rise-was-obtained-by-optim-jl-package-optimization/69548/9 "2021-10-21T02:53:49Z")

</div>

> [@cmarcotte](#):
>
> In my experience, the `allow_f_increases = true` option just allows the method to escape some number of local minima before finding a steady optimum.

You’re right, sometimes optimizations fall into local optimality, but I don’t think it’s a problem as long as it descends like a staircase. The Optim.jl optimization process has two different iterations, one is the iterative step controlled by parameter ` iterations`, and the other is the search process of LBFGS , `store_trace = true` only store the value of the last LBFGS step.

What really confused me was the intermediate search step of LBFGS, you can see what I described in [this problem](https://discourse.julialang.org/t/how-to-use-lbfgs-to-get-the-minimum-value-in-the-optimization-process-but-not-the-last-one/70080). It clearly appears a value smaller than the last process in a certain LBFGS search process, but it still returns the larger value of the last step.

---

_[View the full topic](https://discourse.julialang.org/t/gradient-rise-was-obtained-by-optim-jl-package-optimization/69548)._