Developer-focused chat about JuMP, MathOptInterface, solver interfaces, and JuMP extensions. Yay JuMP 1.0! Basic usage questions will be answered more quickly at https://discourse.julialang.org/c/domain/opt.
Some people here might be interested, the MIP workshop is organizing a reoptimization competition (solving instances with limited changes in constraints or objectives across them)
https://github.com/ambros-gleixner/MIPcc23
^ rules and MOI starter in the repo
https://github.com/ambros-gleixner/MIPcc23
^ rules and MOI starter in the repo
in other news, SCIP is finally open-source: https://github.com/scipopt/scip/blob/master/LICENSE
1 reply
Should we make a new scip_jll build so we can (officially) officially distribute?
1 reply
That will package with the new license. And yes I am planning on adding a SCIP_HiGHS build in Yggdrasil
never merge at a release party
HiGHS seems to do pretty well on this benchmark vs SCIP: http://plato.asu.edu/ftp/milp.html
Just wondering, ignoring SCIP's flexibility and generality and callbacks etc, do people think that for solving your average MILP instance, SCIP and HiGHS are about as good as each other? or could that simple benchmark be a bit misleading?
Just wondering, ignoring SCIP's flexibility and generality and callbacks etc, do people think that for solving your average MILP instance, SCIP and HiGHS are about as good as each other? or could that simple benchmark be a bit misleading?
I don't have much practical experience with HiGHS, but I think the reason to enjoy SCIP is not just the MIP performance, but the fact that it's a proper MINLP solver, with extensive callback support etc.
There are also some recent gimmicks, such as the "progress bar" indicator during tree search.
There are also some recent gimmicks, such as the "progress bar" indicator during tree search.
Overall, HiGHS is doing better on MIPs because it's a single MIP solver with everything baked in, the goal is not to have something super extensible for MIPs / other problems. So with the design decisions HiGHS has and with continuous development, I do expect it to stay faster than SCIP, but integrating new development can only be done from within HiGHS
SCIP's barrier to entry is high, but once one understands the whole plugin interface structure, it can be very fast to develop a realistically good branch and bound solver for larger or more specialized classes of problems
in a talk at the SCIP workshop, there was an observation that OR practitioners were massively using commercial solvers in the last years, and more than before in proportion. The performance gap might explain a bit, but people also seem to value a lot being able to adapt the process with their own cutting planes and heuristics, even though they cannot analyze how they are processed by the solver
one of the things I want a good implementation of is this relaxation handler: scipopt/SCIP.jl#251
basically lets you do arbitrary branch and bound with different relaxations at the nodes (other than the LP one)
basically lets you do arbitrary branch and bound with different relaxations at the nodes (other than the LP one)
@/all a reminder that we have a nonlinear call, tomorrow Wednesday 9th at 2pm Eastern. Please ping me for an invite if you don't already have one. I've gotten side-tracked from our nonlinear expression work to re-factor how MutableArithmetics rewrites expressions: jump-dev/MutableArithmetics.jl#170
Hello, I intend to call the multi-objective optimization function of Gurobi, and I used convex.jl for modeling, but I don't know how to operate it.The documentation provides python modeling methods, such as MODEL.setObjectiveN(expression, index, priority=0, weight=1.0, abstol=0, reltol=0, name="). But I could not find any method to use convex.jl for modeling, so I don't know where to find the data, what should I do?thank you very much.
JuMP has limited support for the multi-objective interface to Gurobi: https://discourse.julialang.org/t/gurobi-not-using-barrier-method/68078/7?u=odow. Improving that is on our roadmap: jump-dev/JuMP.jl#2099
@/all JuliaCon opened submissions early this year to give people more time to apply for visas. That means we need to sort out what we want to do for JuMP-dev ASAP. If you want to help out on the organizing committee, please fill out https://doodle.com/meeting/participate/id/dBN2BKQd so we can have a call to discuss some options. Here's some of the backstory: jump-dev/jump-dev.github.io#90.
2 replies
It seems like the latest version of HiGHS returns
result_count > 0 when the primal_status is NO_SOLUTION. possibly because the dual_status is INFEASIBILITY_CERTIFICATE
I am wondering if this is a bug in the semantics of HiGHS or how I have implemented this function, https://github.com/lanl-ansi/InfrastructureModels.jl/blob/master/src/core/solution.jl#L2-L31
The problem is your function. A result count > 0 does not mean that there is a feasible primal solution available. See https://jump.dev/MathOptInterface.jl/stable/reference/models/#MathOptInterface.ResultCount. You should probably check
primal_status(aim.model) == MOI.FEASIBLE_POINT instead.
@odow, I was looking into the fix for this and came around to thinking the the current semantics of InfrastructureModels is correct. The core idea is, if any kind of solution exists, we want to pass that info on to the user. It is the user's job in PowerModels (and similar) to interpret what that solution means based on the MOI status codes.
So I am going to update the PowerModels tests to better reflect the user's responsibility to check the status codes.
Is this by chance in the road map to be supported? :)
2 replies
@/all two reminders: We will be holding JuMP-dev 2023 in conjunction with JuliaCon. See https://jump.dev/meetings/jumpdev2023/ for details and talk submissions.
Second, we have a monthly developer call this Thursday, 8 December at 2pm Eastern. This is a re-scheduled time to avoid Thanksgiving and Christmas. Your calendar invites should have been updated.