Skip to Content

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

  • 1947
    Simplex method
    Dantzig

1950s

  • 1954
    Cutting planes for the TSP
    Dantzig, Fulkerson and Johnson
  • 1957
    Dynamic programming
    Bellman
  • 1958
    Integer cutting planes
    Gomory
  • 1959
    Shortest paths
    Dijkstra
  • 1959
    The vehicle routing problem
    Dantzig and Ramser

1960s

  • 1960
    Branch and bound
    Land and Doig
  • 1960
    Dantzig-Wolfe decomposition
    Dantzig and Wolfe
  • 1961
    Column generation
    Gilmore and Gomory
  • 1962
    Benders decomposition
    Benders
  • 1964
    Clarke-Wright savings
    Clarke and Wright

1970s

  • 1970
    Lagrangian relaxation
    Held and Karp
  • 1972
    NP-completeness
    Karp
  • 1973
    Lin-Kernighan
    Lin and Kernighan
  • 1975
    Genetic algorithms
    Holland
  • 1977
    Arc consistency
    Mackworth
  • 1979
    Ellipsoid method
    Khachiyan

1980s

  • 1983
    Simulated annealing
    Kirkpatrick, Gelatt and Vecchi
  • 1984
    Interior point methods
    Karmarkar
  • 1986
    Tabu search
    Glover
  • 1987
    Constraint logic programming
    Jaffar and Lassez

1990s

  • 1991
    Branch and cut
    Padberg and Rinaldi
  • 1992
    Ant colony optimisation
    Dorigo
  • 1994
    The alldifferent constraint
    Regin
  • 1996
    Conflict-driven clause learning
    Marques-Silva and Sakallah
  • 1997
    Variable neighbourhood search
    Mladenovic and Hansen
  • 1998
    Branch and price
    Barnhart and others
  • 1998
    Large neighbourhood search
    Shaw

2000s

  • 2005
    Feasibility pump
    Fischetti, Glover and Lodi
  • 2006
    Adaptive large neighbourhood search
    Ropke and Pisinger
  • 2007
    MiniZinc
    Nethercote and others
  • 2009
    Lazy clause generation
    Ohrimenko, Stuckey and Codish

2010s

  • 2017
    JuMP
    Dunning, Huchette and Lubin
  • 2019
    Learned branching heuristics
    Gasse and others

2020s

  • 2020
    Neural diving for mixed-integer programs
    Nair and others
  • 2021
    First-order methods for large linear programs
    Applegate and others
  • 2023
    Linear programming on GPUs
    Lu 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.

Built on JuMP, algebraic modelling language Julia programming language

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.

The player loads from YouTube only after you press play.

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