You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR adds flow cover cuts to HiGHS. All logic related to the cut can be followed from the HighsCutGeneration::tryGenerateFLowCoverCut function. Currently the cuts are only generated based on rows in the LP, i.e., "aggregations" of size 1.
The performance results are extremely finicky, but seem to be promising, and are especially so for some network based energy problems I've been testing on. This shouldn't be merged before any additional computational experiments are done. @galabovaa I changed the two tests because (1) the instance now solved at the root node and therefore has the optimal solution but has status interrupted (2) the primal heuristics now jumped quicker to the optimal solution, so I had to up the objective limit to still catch the event.
@jajhall It's still active, but I've been failing to make them anything but performance neutral on-and-off for months now. @fwesselm has been benchmarking them whenever I try something new and I think the change is significant enough.
I'm happy to close the PR if you don't want clutter. I'm hesitant to merge them with the parameter off by default because I don't want to introduce dead code. I also firmly believe this PR is a couple of lines away from improving general MILP performance by a couple of percent and being properly helpful for certain problem classes. I just can't seem to tune them correctly...... (or there's some logic error and I'm weakening them by accident)
@jajhall It's still active, but I've been failing to make them anything but performance neutral on-and-off for months now. @fwesselm has been benchmarking them whenever I try something new and I think the change is significant enough. I'm happy to close the PR if you don't want clutter. I'm hesitant to merge them with the parameter off by default because I don't want to introduce dead code. I also firmly believe this PR is a couple of lines away from improving general MILP performance by a couple of percent and being properly helpful for certain problem classes. I just can't seem to tune them correctly...... (or there's some logic error and I'm weakening them by accident)
I'm happy to keep it open, but it would be good to merge latest into it so that conflicts don't build up and have CI tests pass
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds flow cover cuts to HiGHS. All logic related to the cut can be followed from the
HighsCutGeneration::tryGenerateFLowCoverCutfunction. Currently the cuts are only generated based on rows in the LP, i.e., "aggregations" of size 1.The performance results are extremely finicky, but seem to be promising, and are especially so for some network based energy problems I've been testing on. This shouldn't be merged before any additional computational experiments are done.
@galabovaa I changed the two tests because (1) the instance now solved at the root node and therefore has the optimal solution but has status
interrupted(2) the primal heuristics now jumped quicker to the optimal solution, so I had to up the objective limit to still catch the event.