Codecov Report

Base: 98.06% // Head: 98.07% // Increases project coverage by +0.00% 🎉

Coverage data is based on head (c664da7) compared to base (451740a).
Patch coverage: 100.00% of modified lines in pull request are covered.

@@           Coverage Diff           @@
##           master    #3176   +/-   ##
=======================================
  Coverage   98.06%   98.07%           
=======================================
  Files          34       34           
  Lines        4597     4612   +15     
=======================================
+ Hits         4508     4523   +15     
  Misses         89       89           

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

Picking on the main sticking points from #2099

we have chosen to handle the objectives separately. Adding an index which denote a specific objective as suggested by @odow is our preferred option because we would like in a near future to remove one objective without redefining all the model.

You can re-define the objective without rebuilding the model. This is working with MOO.jl

model = Model()
@variable(model, x >= 0.0)
@variable(model, y >= 0.25)
@constraint(model, x + y >= 1.0)
@constraint(model, 0.5 * x + y >= 0.75)
@expression(model, obj1, 2 * x + y)
@expression(model, obj2, -x - 3 * y)
# Optimize two objectives
@objective(model, Min, [obj1, -obj2])
optimize!(model)
# ... do something with solution
# Drop objective 2
@objective(model, Min, [obj1])
optimize!(model)
# ... do something with solution

a discussion about how to pass the resolution method to invoke (and possibly the required parameters) is needed.

These are just normal solver parameters

using JuMP
import HiGHS, MOO
model = JuMP.Model(() -> MOO.Optimizer(HiGHS.Optimizer))
set_optimizer_attribute(model, "algorithm", MOO.NISE())

a discussion about how to retrieve Y_N and X_E is needed as soon as the problem is not discrete. Indeed, for the MO-MILP case, Y_N may be composed of points, segments (open or closed), facets (full or not; open or closed). We have not yet stated about a protocol in the vOpt team. One option may be to return each object separately, with its proprieties, and a description of their adjacency relations.

This is tricky. For now, value(x; result = i) and objective_value(model, ; result = i) return points. Presumably, we'd need some solver-specific attributes here for the facets. For example:

Y_N = MOI.get(model, vOpt.EfficientFacets())

In writing @objective(model, Max, [dot(x, p1), dot(x, p2)]), the user cannot
(1) blend functions to minimize and to maximize in the model, and

This is still a problem.

(2) point out a function to delete without rebuilding all the model.

You can set a new objective, but we can't say "delete the 2nd objective from this vector." Would solvers benefit from the ability to do this?

Before merging, I'd like to tag https://github.com/jump-dev/MultiObjectiveAlgorithms.jl as a public package and add a tutorial to the documentation. This would let us document both vector-valued objectives, and solvers which support multiple solutions.

I've added a tutorial using MultiObjectiveAlgorithms. I think it's pretty cool. The ease to which we can solve multi-objective problems is going to be a nice boost to the popularity of JuMP.

I'll post a link here once CI finishes.

Here's the tutorial: https://jump.dev/JuMP.jl/previews/PR3176/tutorials/linear/multi_objective_knapsack

@xgandibleux: I've updated the tutorial to use vectors instead of the Item struct I had before:
https://jump.dev/JuMP.jl/previews/PR3176/tutorials/linear/multi_objective_knapsack/#Data

Great!

After 3+ years (#2099), this is finally ready to merge!

Ideed, Ideal point is a common reference point in MOO, and I agree with Oscar, extra explanations are not required here.