add multi-objective support for highs solver release 1.9.0
Summary
The highs solver release 1.9.0 started to support multiple objectives. Please add this functionality and details are in https://ergo-code.github.io/HiGHS/stable/guide/further/#guide-multi-objective-optimization
Hi @shuaiwang88, I just had a look at the HiGHs repo and the HighsLinearObjective data structure as well as the AddLinearObjective method are not available in highspy, it seems it's only available in C/C++. see : https://github.com/search?q=repo%3AERGO-Code%2FHiGHS%20addLinearObjective&type=code I have opened an issue in the HiGHs repo to get clarity on the above: https://github.com/ERGO-Code/HiGHS/issues/2263
On the pyomo side, it's worth discussing if there's an interest to support this more broadly with new priority and tolerance fields for the objective ? schematically
class ObjectiveData(NamedExpressionData, ActiveComponentData):
"""This class defines the data for a single objective."""
__slots__ = ("_args_", "_sense", "_priority", "_tolerance")
def __init__(self, expr=None, sense=minimize, priority=0, tolerance=0.0, component=None):
# Inlining NamedExpressionData.__init__
self._args_ = (expr,)
# Inlining ActiveComponentData.__init__
self._component = weakref_ref(component) if (component is not None) else None
self._index = NOTSET
self._active = True
self._sense = ObjectiveSense(sense)
self._priority = priority
self._tolerance = tolerance
gurobi_direct (and probably other solvers I don't know of) could also make uses of these https://docs.gurobi.com/projects/optimizer/en/current/features/multiobjective.html
Thoughts @mrmundt @michaelbynum ?
@quantresearch1, I am a little hesitant to add those as fields for the objective, as that is a pretty solver-specific thing. What would you think about using Suffixes to provide that information? Note that some solver interfaces already support a priority Suffix for specifying branching priorities, so this would seem to fit into the same idea.
Thanks @jsiirola for your input. Good to know that's already done through suffixes, I was not aware of that. It makes sense to continue with suffixes. Eventually, I had in mind to not make lexicographic optimization solver specific by:
- If a solver supports lexicographic optimization, pass on priority and rel/abs_tolerance as required
- If a solver does not support it, we could do the following in pyomo as long as the user has set the required fields/suffixes: Solve for each objective in priority order, each time adding a constraint to ensure the degradation of the higher priority objective