search

PyVRP / PyVRP

Open-source, state-of-the-art vehicle routing problem solver in an easy-to-use Python package.
https://pyvrp.org/
MIT License
299 stars 51 forks source link

High-level interfaces `solve_cvrp` and `solve_vrptw` #132

Closed leonlan closed 1 year ago

leonlan commented 1 year ago

From https://github.com/N-Wouda/PyVRP/issues/48#issuecomment-1406684143

I think we should do the following.

First, we offer two high-level solver routines in the pyvrp package: solve_cvrp() and solver_vrptw(). These take only the bare minimum of arguments (perhaps only a ProblemData instance) and are intended for users that only want to solve the problem, and do not care at all about how. This is intentionally a black box. These routines return a Result object that contains some statistics, and the best solution, and everything else is basically a hidden implementation detail.

For these functions, we compile two versions of our codebase: one where we use the TWS data, and another where we do not, using compile time flags. The compiler will optimise for each case. In the high-level solver routines, we then use the appropriate binary to implement the solver function.

For people's own use cases, we expose only the full/complete components, not the faster, problem-specific implementations.

N-Wouda commented 1 year ago

Purely realistically, I don't think this is something we're going to do before the initial submission. We already have the different compilation modes, and that's a good step up towards this.

When we do this we'll need to rethink how we package things - standalone objects, or one big object like hgspy for Euro/NeurIPS? The latter is easier to compile: then there's just _cvrp, and _vrptw, and the like. Else we might need many objects for different variants.

N-Wouda commented 1 year ago

The interface for this can be something like solve_<variant>(data: ProblemData, stop: StoppingCriterion, seed: int = 0). Together with the high-level interface of #217 it should then be pretty easy to model and solve each variant.

N-Wouda commented 1 year ago

We promised this in the paper, but I just tinkered with it a bit and would like not to do this (yet). It's particularly tricky because we have native objects that are also wrapped in Python (#107) - those have hardcoded dependencies on the location of a particular native extension. If we want this, we need to think about a way to do that differently.

For now it's enough for me that we support this via compilation flags.

N-Wouda commented 1 year ago

OK, I just checked the paper again, and I don't think we explicitly promise this. We just talk about PyVRP being easy to use. Then I think #217 and the associated PR are enough for now.

N-Wouda commented 1 year ago

@leonlan @wouterkool shall we close this?

leonlan commented 1 year ago

Sure #236 closes this for me