Differential-evolution: Is there a 'vectorized'-option like in scipy?

[MagneticX]

Dear community,

I'm currently working with lmfit's differential_evolution algorithm.
My understanding is that lmfit leverages scipy.optimize.differential_evolution under the hood, but I prefer lmfit due to its more convenient handling of parameter definition, constraints and bounds.

My goal is to accelerate the optimization process through parallel evaluation of parameter sets.
Typically, this is achieved by providing a map-like callable to the workers parameter, which requires the objective function to be pickleable for multiprocessing.
Here lies my challenge: My objective function is designed to evaluate multiple sets of parameters concurrently.
It achieves this by using asyncio to orchestrate and await results from multiple external simulations. Consequently, this objective function is not pickleable.

With scipy.optimize.differential_evolution, I could leverage the vectorized=True option.
This allowed me to pass an array of parameter sets to my objective function, which then returned a corresponding array of result-values, by using its own internal parallelism.

My question is: Does lmfit's differential_evolution (or any other lmfit optimizer) offer a similar vectorized evaluation mode, where the objective function receives multiple parameter sets at once?

Thank you!

[newville]

Two comments:

a) I think our support for differential_evolution may be "not great". The original author of this wrapper stopped contributing to the project a while ago, and I'm afraid that I simply never use it. In my experience, it is just not a very good algorithm. I know people who use it, but I do not know of anyone who has compared differential_evolution with other algorithms, including ampgo, and concluded that differential_evolution is better. People seem to be drawn to differential_evolution based on some theory or description of how it is intended to work. Expecting evolution to get to an optimal solution is optimistic, and insisting that derivatives can never be used is sort of "willfully ignorant". I can believe it has its uses... but the results at
https://infinity77.net/global_optimization/multidimensional.html#test-functions-multi-dimensional-n-d-test-functions
suggests that the overall success rate is very low, and the computation time is very high. That's in comparison to other Global Solvers.
AMPGO succeeds 3x as often and with fewer than half as many function calls.

b) As you note multi-processing for optimization problems is not easy. It would be wonderful to be able to support this. We're not opposed to doing so, we just do not know how to do it. Suggestions and pull requests welcome.

[reneeotten]

@MagneticX this should be addressed with PR #1022