Open N-Wouda opened 1 year ago
Solving general mathematical programming problems should also be possible. There has been some work on this in recent years (e.g., Hendel (2022)), but more can be done to simplify/improve the integration of heuristic methods for general optimization problems.
Returning to this issue, I think it can be interesting if we can solve general CP/MIP problems in standard form. We could 'hijack' Pyomo or OR-Tools to provide the modelling interface, letting users pass such a model into our own ALNS metaheuristic to solve them. Implementing a performant ALNS for general CPs/MIPs is a significant amount of (research) work, but could be very worthwhile for the reasons Serdar already explained above.
@leonlan and @skadio: would either/both of you be interested in working with me on this? Timewise it'd probably be no earlier than the second half of this year, after the summer.
Yea I'm definitely interested in working on this!
I'm currently familiarizing myself with constraint programming and I plan to make an LNS-based CP solver for large-scale flow shop scheduling problems. I'm working on this for the next few months, so I'll make sure to add my ideas/prototypes to this thread before we work on this together.
I am very much inclined in this direction --but a few call outs, having re-read the thread and the referenced papers.
Broadly speaking; on one hand we have A) A1) LNS algorithm on top of CP solvers exists (see Choco for example) A2) ALNS algorithm on top of MIP solvers exists (see SCIP for example) (side note I am not aware of ALNS + CP in general sense, except problem specific applications) In A), for both cases (A)LNS is implemented within/on-top of a specific solver.
On the other hand, in theory, we can have B) where.
A and B differs which part of the solver is fix. A fixes the constraint solver, B fixes the ALNS solver.
But at the end of the day, both solutions yield roughly the same result for the user with a trade-off depending of whether the constraint solver is fixed or alns solver is fixed. That is not to say that, there are some nice properties of integrating tightly with a constraint solver (as in A) for efficiency. MiniLNS paper discusses some of this.
So.. the scope here needs to be sharpened to decide whether this will be a practical exercise (some form of reviving A into B) OR whether there is open angle in the research not explored before. The answer is not immediately clear to me.
Happy to brainstorm.
@leonlan @skadio great to hear you're both interested! Since we won't start working on this for a little while longer, I suggest we wait until, say, July/August before planning a brainstorm meeting. In the meantime it's probably a good idea to use this issue to:
The approaches of "A" and "B" are both superficially OK for me, as long as we can make work and make it work sufficiently generally that it is of value to many users.
For (3): my own interest here lies mostly in the combination of heuristics (e.g., ALNS) and exact methods. I don't mind if we make this a practical exercise, but in the interest of my (and @leonlan, I assume) PhD a research component with an eventual paper would be easier to 'sell'. We can discuss later what that research component should be. I should have some time next month to collect some readings and develop my own thinking on the research aspect further. I will report back here then.
One high-level idea I like is doing something with leaf fathoming in branch-and-bound trees. If we explore a leaf heuristically rather than exactly, we might be able to do things much faster without sacrificing too much quality.
All sounds good!
Sounds good to me as well!
I don't mind if we make this a practical exercise, but in the interest of my (and @leonlan, I assume) PhD a research component with an eventual paper would be easier to 'sell'.
Yes, the same holds for me :-)
In https://github.com/openjournals/joss-reviews/issues/5028, @skadio wrote: