[docs] fix benders_decomposition.jl

[odow]

Closes #3531

Thanks for catching this @WalterMadelim. I'm surprised that it didn't error!

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (df022a5) 98.25% compared to head (64017e5) 98.18%.
Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3532      +/-   ##
==========================================
- Coverage   98.25%   98.18%   -0.08%     
==========================================
  Files          37       37              
  Lines        5563     5561       -2     
==========================================
- Hits         5466     5460       -6     
- Misses         97      101       +4     

see 4 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[odow]

I should look at why this didn't error. It should have...

[WalterMadelim]

It has indeed, after changing GLPK to Gurobi. (I have not installed GLPK)

[odow]

Ah, so this might be an issue with GLPK, not with JuMP. Thanks for looking.

[odow]

Now I don't understand what's going on here:

[odow]

GLPK callbacks are weird

[WalterMadelim]

I think the output in your figure is normal. There are multiple "Terminating with the optimal solution", because this is a callback function, which will be called frequently during solving, and the solver's terminating criterion doesn't depend on user's callback function. As for the Jumping up - Jumping down lower bound, this is also reasonable because the problem is changing during solving. The puzzling point is why GLPK can return the right answer, even if you submit to model not lazy_model.

But it should be fine after revising. I agree with the new callback function.

[WalterMadelim]

GLPK callbacks are weird

Actually I would prefer to use a solver-dependent callback. (For example, I would refer to Gurobi.jl directly when I have a need)

[odow]

I don't understand why GLPK calls so many times:
https://jump.dev/JuMP.jl/previews/PR3532/tutorials/algorithms/benders_decomposition/#Callback-method

[WalterMadelim]

I thought there might be no one who is more familiar with this than you, because it seems that you are the main contributer of GLPK.jl.🥲

From my point of view, the function my_callback(cb_data) is special, because it is controlled by the solver rather than Julia. I tried to put break points @bp's inside it, but they were never hitted. Therefore this function is more likely to be a component of the branch and cut module: when the main algorithm need a user's callback, then a lazy cut is retrieved and stored.

Therefore, I think the name number_of_subproblem_solves is not proper. It's the number of times that callback module in GLPK is executed when status == MOI.CALLBACK_NODE_STATUS_INTEGER. Subproblems modeling and branching should reside in a deeper module than callback module in GLPK (my comprehension).

This adapted version of TSP callback code (using MOI without JuMP) might be a comparison. Solver is Gurobi, the problem is larger and the counter reaches 20, compared with your result 341. (you can try it)

https://github.com/WalterMadelim/p8f.jl/blob/main/src/TSP_GRB_callback.jl

[odow]

I thought there might be no one who is more familiar with this than you, because it seems that you are the main contributer of GLPK.jl

Yes 😄 I meant this as "given I understand exactly how it works, it is confusing that it is called so many times."