Behaviour of fits that reach max_max_nfev

[dangarciahe]

Hello. I've been playing around with global optimization algorithms, and I'm unsure about the intended behavior of some. When a lmfit.minimize() problem finishes due to reaching max_nfev, is the intended behavior to return the latest values of the parameters, or the values of the parameters for the best recorded fit?

I saw #679 and #665, but I still get behaviors of return of latest values, so I'm a bit confused.

Thanks in advance.

[newville]

@dangarciahe If a fit aborts because it reached max_nfev function calls, the fitting algorithm thinks that it has not reached the best solution. If max_nfev is reached, how far the "last evaluation" is from "best so far" will depend on the algorithm used. We don't keep that status information separately from the fitting algorithm.

For many methods, "latest" and "best so far" should not be too far off. But, this might not be the case for some global solvers. Of course, global solvers may require many function calls and fail frequently — and some more often than others. For most iterative solvers where a solution is possible, the "latest" is likely to be an improvement over the starting values. Increasing max_nfev or starting over with the returned values would be perfectly reasonable things to do. Otherwise, it could just be a bad fit, which is not necessarily a problem that we can fix. That is especially true if we do not know what you are doing.

You did not provide any code or any indication of what you are trying to do or what result you actually got. If you want further help, you will have to show us what you are doing and what results you get. See https://en.wikipedia.org/wiki/Minimal_reproducible_example.

[dangarciahe]

Hi @newville, thanks for the clarification.

I'm trying to do a multivariable fitting to a rather complex function under some private data. Since I'm just playing around, I tried max_nfev = 100 with ampgo. I'm storing the evaluations, and I found that the latest value (returned by fit_report(result)) is actually the worst value in the 100 evaluations. I fiddled around a bit, thinking maybe I somehow called a maximizing function method, but it was not the case. Below is an example of simple function that has a similar behavior.

A Minimal, Complete, and Verifiable example

import lmfit

def parabolic(p):
  x = float(p["x"])
  y = (x)**2
  print (f"x: {x:.1f}, y:{y:.1f}")
  return y

fit_params = lmfit.Parameters()
fit_params.add('x', value=-2, min=-10, max=10, vary=True)

result = lmfit.minimize(parabolic, fit_params, method="ampgo", max_nfev=400)
print(lmfit.fit_report(result))

Fit report:

[[Fit Statistics]]
    # fitting method   = ampgo, with L-BFGS-B as local solver
    # function evals   = 400
    # data points      = 1
    # variables        = 1
    chi-square         = 1548.89793
    reduced chi-square = 1548.89793
    Akaike info crit   = 9.34529895
    Bayesian info crit = 7.34529895
##  Warning: uncertainties could not be estimated:
[[Variables]]
    x: -6.27343930 (init = -2)

Version information:

Python: 3.13.3 (main, Apr  9 2025, 07:44:25) [GCC 14.2.1 20250207]

lmfit: 1.3.4, scipy: 1.16.1, numpy: 2.2.5,asteval: 1.0.6, uncertainties: 3.2.3

Running in Linux 6.6.90-1-MANJARO

With the prints, one can see that there's a lot of near-0 evaluations, and even that the returned evaluation is worse than the last one, so returning -6.27 doesn't make much sense. Trying max_nfev=4000 instead of max_nfev=400 fixes this and gives a good enough answer. Still, I think that not returning the overall best is an undesired behavior, specially since I found this in AMPGO's article:

"[...] where as customary the best feasible candidate is retained as the overall “winner”"

Therefore, I think an improvement would be to return the overall best set of parameters, not just for ampgo but in general. If you agree on this, I would be happy to help with a PR under some guidance.

[newville]

@dangarciahe well, (and: a concrete example with real code is always helpful), I do see that the ampgo method does, in fact, always return a "best parameters so far" result, and we are not actually using that, but instead using "last tried". So, this should be easily fixable (in the "ampgo" wrapper in minimizer).

If you'd like to play around with that a submit a PR, that would be great. Otherwise, I can put it on my ToDo list.

[dangarciahe]

@newville Thanks for the info. I'll play around and submit the PR.