Merge stable/1.2 features to master

coin-or / MibS

A solver for mixed integer bilevel programs

Eclipse Public License 1.0

50 stars 20 forks source link

Merge stable/1.2 features to master #94

Open yuxies opened 2 years ago

yuxies commented 2 years ago

Update Interdiction type problem data reading in MibSModel;
Update two Benders cuts to reflect the changes in MibS valid inequality paper;
Add a fractional cut option to multiple cuts and update related control parameter settings; update print messages for several cuts;
Fix bugs and clean up redundant statements or variables;
All changes above are applied to (only) deterministic blocks in the master branch.

CLAassistant commented 2 years ago

All committers have signed the CLA.

tkralphs commented 2 years ago

So all the commits attributed to me were cherry-picked? What about the additional ones by you? I guess those were also cherry-picked?

yuxies commented 2 years ago

The commits before the force-push + yesterday's last two commits were cherry-picked from stable/1.2.

And other commits not related to stable/1.2 but I pushed to the same branch so they are still showing up here are

a1bbeee1cbd818b69f2c01f7335ede78f91929ef: cleaned the rounding procedure of LR relaxation solution when creating bilevel; it also fixed a bug;
76cb6bebc6e005f843aaf2f239fe5ae2b3d2dda3 and e166facd9ba4128d57354348b17439f9497a3b50 are preparation for the heurstic solution tag reorg, as the current open PR in stable/1.2... I am still working on it.

tkralphs commented 2 years ago

OK, so should I merge this then?

yuxies commented 2 years ago

will run some tests tonight and report the results here. After that should be yes.

yuxies commented 2 years ago

Ran experiments using version f735ff288a171d3e2bc8c83538000fce1e1ae3a5 on both dataIBLP-DEN (w or w/o linking pool + different cut options) and MIBLP-XU(default, i.e. fractional + hypercube IC). The objective values obtained agree with previous builds. So the commits above should be ready to merge.

(Again, all the changes above are not tested with stochastic cases, and will need to do so sometime in the future.)

tkralphs commented 1 year ago

I'm looking at this again now and I don't really understand how you approached this. We merged the changes from stable to master around 29 Nov 2019 in f19a5a5. I think we should be able to do the same now to just make sure that no commits get lost. Once we have the merge done, then we can separately add your commits on top, as needed. But I also wonder whether any of your commits are also appropriate in stable. Should we commit them to stable first and then merge?

yuxies commented 1 year ago

Some of my (most recent) commits listed here have already been merged to stable/1.2, and some of them may not be applied now because they may be conflict with other commits merged in the past year.

The feasibility check module looks very different in the master version due to the introduction of stochastic scenarios. I will need to read through and think again before clean up.

tkralphs commented 1 year ago

OK, but it's still the case that all the changes from stable/1.2 were merged not that long ago. There haven't been a lot of commits since then. I don't see that we need to cherry pick, just a plain merge should be OK. There might be a few conflicts to resolve, but I don't see it as being something very difficult, unless I'm wrong.