Cleanup BBO and MOI

[SebastianM-C]

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

The callback implementation for BBO was not reporting the objective correctly during callbacks. I think that's related to the improper use of global variables to communicate between the objective and the callback.

I've also adapted the BBO wrapper to use the BBO API for elapsed time and I fixed the stats for MOI (the stats didn't report anything).

[ChrisRackauckas]

The MOI failure looks legit.

[SebastianM-C]

yep, let me see what I can do about that...

[SebastianM-C]

Looking at https://github.com/jump-dev/NLopt.jl/blob/master/ext/NLoptMathOptInterfaceExt.jl it seems that we don't have BarrierIterations (nor other things like SimplexIterations). The MOI docs for implementing the solver interface, https://jump.dev/MathOptInterface.jl/stable/tutorials/implementing/#Solutions mention

If applicable, implement:
SimplexIterations
BarrierIterations
NodeCount

But I can't find a way to programmatically check if this is applicable for a given solver outside of something like

ms = methods(MOI.get, [typeof(opt_setup), MOI.BarrierIterations])
only(ms).module === MOI

Would this be too horrible to consider?

[SebastianM-C]

It's even worse than I thought, we have solvers like Juniper.jl which don't implement something for the number of iterations (https://github.com/lanl-ansi/Juniper.jl/blob/master/src/MOI_wrapper/results.jl), but they do intercept all the MOI.get calls,

https://github.com/lanl-ansi/Juniper.jl/blob/c63231b64578dfc574d687e4bd2e7c17292b2379/src/MOI_wrapper/MOI_wrapper.jl#L389-L396

So we can't really know just from the module of the method :(

[SebastianM-C]

Something weird is happening in the BBO test. I can see the hang locally too, but only if I run with the testset 🤔

[SebastianM-C]

Hmm
Looking at Tracy output I see quite a large increase in the heap size & the runtime of the callback. I think that the deepcopy is responsible, but I'm not sure yet why it only happens if this is run inside the testset...
If I run inside the testset, the time for the callback explodes, but if it's not, then it's constant.

Edit: I separated the deepcopy to a dedicated region and that confirms the above.

[SebastianM-C]

I also found a fix for OptimizationNOMAD, it seems that it was using a very old version (2.0) due to the latest one (2.4) not being yet compatible with the latest LinearSolve due to Krylov.jl compat (see ds4dm/Tulip.jl#156, on which NOMAD depends on).

[SebastianM-C]

@ChrisRackauckas is this good to go?

[Vaibhavdixit02]

bump versions so a release can be triggered after merging