We follow optimisation research and contribute to open source
Mathematical optimisation has been published, argued over and improved since 1947. New methods keep arriving. We read them, benchmark them against the instances our customers actually send, and move the engines when the numbers say so. The connectors between the Julia modelling language and those engines are open source, and we maintain them in public.
- GitHub org
- NexOR-Optimization
- Written in
- Julia, Python
- Contributions
- JuMP core and solver bridges
- Conferences
- JuMP-dev, Odoo Experience
- Academic ties
- UCLouvain
Eighty years of methods
Eight decades of results, and no single method that won. Every entry below is a dated publication, with the people who wrote it.
Optimisation started as a wartime planning problem and turned into a field. The simplex method arrived in 1947, and the fifteen years after it produced most of the machinery still running today: dynamic programming, cutting planes, branch and bound, shortest paths, and the decompositions that let one large problem be solved as a series of small ones.
Then Karp showed, in 1972, why the work would never be finished. A whole family of ordinary planning problems has no known efficient exact algorithm, and none has been found since. The response was not one better algorithm but many, borrowed from wherever they could be found: simulated annealing from metallurgy, tabu search from the idea of a short memory, genetic algorithms and ant colony optimisation from biology, constraint programming from logic, and large neighbourhood search from the observation that a good plan is usually a small edit away from a better one.
None of them won, and that is the point. Each is strong on a shape of problem the others handle badly, so the field kept all of them and learned to combine them: exact search steered by heuristics, constraint propagation backed by clause learning, and lately branching decisions learned from data. The last few years added first-order methods and GPUs, which reopened linear programs at sizes the simplex method was never built for.
1940s
-
1947Simplex methodDantzig
1950s
-
1954Cutting planes for the TSPDantzig, Fulkerson and Johnson
-
1957Dynamic programmingBellman
-
1958Integer cutting planesGomory
-
1959Shortest pathsDijkstra
-
1959The vehicle routing problemDantzig and Ramser
1960s
-
1960Branch and boundLand and Doig
-
1960Dantzig-Wolfe decompositionDantzig and Wolfe
-
1961Column generationGilmore and Gomory
-
1962Benders decompositionBenders
-
1964Clarke-Wright savingsClarke and Wright
1970s
-
1970Lagrangian relaxationHeld and Karp
-
1972NP-completenessKarp
-
1973Lin-KernighanLin and Kernighan
-
1975Genetic algorithmsHolland
-
1977Arc consistencyMackworth
-
1979Ellipsoid methodKhachiyan
1980s
-
1983Simulated annealingKirkpatrick, Gelatt and Vecchi
-
1984Interior point methodsKarmarkar
-
1986Tabu searchGlover
-
1987Constraint logic programmingJaffar and Lassez
1990s
-
1991Branch and cutPadberg and Rinaldi
-
1992Ant colony optimisationDorigo
-
1994The alldifferent constraintRegin
-
1996Conflict-driven clause learningMarques-Silva and Sakallah
-
1997Variable neighbourhood searchMladenovic and Hansen
-
1998Branch and priceBarnhart and others
-
1998Large neighbourhood searchShaw
2000s
-
2005Feasibility pumpFischetti, Glover and Lodi
-
2006Adaptive large neighbourhood searchRopke and Pisinger
-
2007MiniZincNethercote and others
-
2009Lazy clause generationOhrimenko, Stuckey and Codish
2010s
-
2017JuMPDunning, Huchette and Lubin
-
2019Learned branching heuristicsGasse and others
2020s
-
2020Neural diving for mixed-integer programsNair and others
-
2021First-order methods for large linear programsApplegate and others
-
2023Linear programming on GPUsLu and Yang
Reading the field is part of the job
A growing engine catalogue
The number of solvers we support keeps going up. Each new engine reaches the catalogue through the same JuMP interface, measured against the engines already there and published with its rate.
Solver releases
Every solver release shifts which engine is fastest on which problem. We re-run our benchmark set against each new version and move the default only when the improvement holds on more than one instance.
Published research
Operations research is published in the open, so a method can be read and checked before anyone builds on it. We follow the routing and scheduling literature and implement what proves itself on customer data.
The JuMP-dev workshop
JuMP-dev is where the people who maintain the modelling layer and its solver interfaces review the year's work in person. We attend, and we present.
The Odoo Experience conference
Odoo Experience puts Odoo's roadmap and its customers in one room. We go to hear what they need, to show what we do, and to keep our optimisation work fitting the platform it runs inside.
Our own benchmark set
A method earns a place in the catalogue by beating what is already there. We measure that on instances kept from real customer problems, not on the benchmarks its authors selected.
Julia, and the layer the field models in
Julia is where a lot of current optimisation research is written. It runs at the speed the solvers need and reads close to the mathematics, so a paper and its implementation stay recognisably the same thing.
JuMP sits on top of it. Describe a problem once, in near-mathematical syntax, then hand it to any of more than 30 solver backends behind one interface. It is the de-facto standard in the Julia community and the backbone of optimisation research across European universities, including UCLouvain, where parts of our team trained.
We work on it rather than only with it. Members of the team ship pull requests against the core packages, maintain solver interfaces, and present at the JuMP-dev workshop.
Shown at JuMP-dev
Benoît Legat, one of our founders and a JuMP core developer, showing the stack that runs NexOR to the community that builds JuMP.
What we maintain in the open
The solver bridges, the modelling layers and the client that reaches our servers. They stay on GitHub under their own licences.
Hexaly.jl
JuMP interface to Hexaly, a commercial constraint-programming and metaheuristics solver. Lets Julia models drive Hexaly directly.
MaxiCP.jl
JuMP interface to MaxiCP, an academic constraint programming solver maintained at UCLouvain. Open source, solver included.
Vroom.jl
JuMP interface to VROOM, a widely used open-source Vehicle Routing solver. Brings VROOM into the Julia and JuMP toolbox.
OscaRCBLS.jl
JuMP interface to OscaR.cbls, a constraint-based local-search library from CETIC. Puts local search behind the same modelling language as the exact solvers.
MathOptVRP.jl
JuMP extension for Vehicle Routing Problems. Expresses stops, capacities, and time windows as a routing model JuMP can hand to any solver backend.
JuMPy
A Python interface to MathOptInterface. Models are written once as templates and expanded in compiled Julia, so building a large model stops costing more than solving it.
ContractionHierarchies.jl
Shortest-path computation on OpenStreetMap graphs using contraction hierarchies. It builds the distance and travel-time matrices an optimisation model takes as input.
NexOR.jl
Julia client for our solve API. A model written in JuMP solves on our servers instead of the local machine, and the results come back into the same session.
Open maths beats black-box maths
Auditable models
The solver bridges are in code anyone can read, and so are the solvers they reach. The maths is not a black box you have to take on trust.
Vetted by research
JuMP and its solvers are used in operations-research labs worldwide. The solvers we build on are scrutinised by the global community.
No lock-in
The bridges stay on GitHub under their own open licences, whatever happens to us. Your data and your database are yours to export at any time.
Customer-shaped
A solver that does not model your reality is just slow software. We extend the open packages when a customer constraint is not already supported.
The optimisation code we write is open source
github.com/NexOR-Optimization