I’ve got some code that solves several optimization problems using Optimization.jl. When checking for type stability with JET’s report_opt function, it outputs all sorts of errors around the call to OptimizationFunction. This can be duplicated with the rosenbrock problem from the tutorial; report_opt finds 10 errors with this simple test:
Instantiating the OptimizationFunction is a setup step before launching the optimization. Some type instability during setup is usually not a concern as long as the optimization loop itself runs without type instabilities, so the developers of Optimization.jl apparently haven’t prioritized the effort to make this call type stable (assuming it’s even possible).
Keep in mind that what JET calls “errors” here are really just cases where the types of some variables and the corresponding methods had to be looked up at runtime instead of compile time. There’s nothing wrong/incorrect with the code.
I think it’s a better workflow to run the optimization with e.g. @btime from BenchmarkTools to see if there is a problem with excessive allocations (which is what type instability produces). If such problems appear, it’s time to investigate with @code_warntype or JET or similar things.