Se rendre au contenu

Nous suivons la recherche en optimisation et contribuons à l'open source

L'optimisation mathématique est publiée, discutée et améliorée depuis 1947. De nouvelles méthodes arrivent sans cesse. Nous les lisons, nous les évaluons sur les instances que nos clients envoient réellement, et nous changeons de moteur quand les chiffres le disent. Les connecteurs entre le langage de modélisation Julia et ces moteurs sont open source, et nous les maintenons au grand jour.

Organisation GitHub
NexOR-Optimization
Écrit en
Julia, Python
Contributions
Cœur de JuMP et passerelles de solveurs
Conférences
JuMP-dev, Odoo Experience
Attaches académiques
UCLouvain

Quatre-vingts ans de méthodes

Huit décennies de résultats, et aucune méthode qui l'ait emporté. Chaque entrée ci-dessous est une publication datée, avec les personnes qui l'ont écrite.

L'optimisation est née d'un problème de planification en temps de guerre avant de devenir une discipline. La méthode du simplexe arrive en 1947, et les quinze années qui suivent produisent l'essentiel de la machinerie encore en service : programmation dynamique, plans sécants, séparation et évaluation, plus courts chemins, et les décompositions qui permettent de résoudre un grand problème comme une suite de petits.

Puis Karp montre, en 1972, pourquoi le travail ne serait jamais terminé. Toute une famille de problèmes de planification ordinaires n'a aucun algorithme exact efficace connu, et aucun n'a été trouvé depuis. La réponse n'a pas été un meilleur algorithme, mais beaucoup, empruntés partout où on pouvait les prendre : le recuit simulé à la métallurgie, la recherche tabou à l'idée d'une mémoire courte, les algorithmes génétiques et l'optimisation par colonies de fourmis à la biologie, la programmation par contraintes à la logique, et la recherche à grand voisinage au constat qu'un bon plan est presque toujours à une petite retouche d'un meilleur.

Aucune ne l'a emporté, et c'est tout l'intérêt. Chacune est forte sur une forme de problème que les autres traitent mal, si bien que le domaine les a toutes gardées et a appris à les combiner : recherche exacte guidée par des heuristiques, propagation de contraintes adossée à l'apprentissage de clauses, et depuis peu des décisions de branchement apprises sur des données. Ces dernières années ont ajouté les méthodes du premier ordre et les GPU, qui rouvrent des programmes linéaires à des tailles pour lesquelles le simplexe n'a jamais été conçu.

années 1940

  • 1947
    Simplex method
    Dantzig

années 1950

  • 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

années 1960

  • 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

années 1970

  • 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

années 1980

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

années 1990

  • 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

années 2000

  • 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

années 2010

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

années 2020

  • 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

Suivre la recherche fait partie du métier

Un catalogue de moteurs qui s'agrandit

Le nombre de solveurs que nous prenons en charge ne cesse d'augmenter. Chaque nouveau moteur rejoint le catalogue par la même interface JuMP, évalué face aux moteurs déjà présents et publié avec son tarif.

Versions de solveurs

Chaque version d'un solveur déplace la frontière de ce qui est le plus rapide, et sur quel problème. Nous relançons notre jeu d'évaluation sur chaque nouvelle version et ne changeons de moteur par défaut que si le gain tient sur plus d'une instance.

La recherche publiée

La recherche opérationnelle est publiée au grand jour : une méthode peut donc être lue et vérifiée avant que quiconque ne construise dessus. Nous suivons la littérature sur les tournées et l'ordonnancement et implémentons ce qui fait ses preuves sur les données de nos clients.

L'atelier JuMP-dev

JuMP-dev est l'endroit où celles et ceux qui maintiennent la couche de modélisation et ses interfaces de solveurs passent en revue le travail de l'année, en personne. Nous y allons, et nous y présentons.

La conférence Odoo Experience

Odoo Experience réunit la feuille de route d'Odoo et ses clients dans une même salle. Nous y allons pour entendre ce dont ils ont besoin, montrer ce que nous faisons, et garder notre travail d'optimisation bien ajusté à la plateforme sur laquelle il tourne.

Notre propre jeu d'évaluation

Une méthode gagne sa place dans le catalogue en battant ce qui s'y trouve déjà. Nous le mesurons sur des instances conservées de problèmes clients réels, pas sur les jeux d'essai choisis par ses auteurs.

Julia, et la couche dans laquelle le domaine modélise

Julia est le langage dans lequel s'écrit une grande partie de la recherche actuelle en optimisation. Il tourne à la vitesse dont les solveurs ont besoin et se lit au plus près des mathématiques, si bien qu'un article et son implémentation restent visiblement la même chose.

JuMP se pose par-dessus. Décrivez un problème une seule fois, dans une syntaxe proche des mathématiques, puis confiez-le à l'un des plus de 30 solveurs derrière une interface unique. C'est le standard de fait dans la communauté Julia et la colonne vertébrale de la recherche en optimisation dans les universités européennes, dont l'UCLouvain, où une partie de notre équipe s'est formée.

Nous y travaillons, et pas seulement avec. Des membres de l'équipe proposent des pull requests sur les paquets centraux, maintiennent des interfaces de solveurs et présentent à l'atelier JuMP-dev.

Construit sur JuMP, langage de modélisation algébrique Langage de programmation Julia

Présenté à JuMP-dev

Benoît Legat, l'un de nos fondateurs et développeur du cœur de JuMP, présente à la communauté qui construit JuMP la pile qui fait tourner NexOR.

Le lecteur ne se charge depuis YouTube qu'après avoir appuyé sur lecture.

Ce que nous maintenons en public

Les passerelles vers les solveurs, les couches de modélisation et le client qui atteint nos serveurs. Ils restent sur GitHub sous leurs propres licences.

Hexaly.jl

Interface JuMP vers Hexaly, un solveur commercial haute performance de programmation par contraintes et de métaheuristiques. Permet aux modèles Julia de piloter Hexaly directement.

MaxiCP.jl

Interface JuMP vers MaxiCP, un solveur académique de programmation par contraintes maintenu à l'UCLouvain. Open source, solveur compris.

Vroom.jl

Interface JuMP vers VROOM, un solveur open source de tournées de véhicules largement utilisé. Amène VROOM dans la boîte à outils Julia et JuMP.

OscaRCBLS.jl

Interface JuMP vers OscaR.cbls, une bibliothèque de recherche locale à base de contraintes du CETIC. Place la recherche locale derrière le même langage de modélisation que les solveurs exacts.

MathOptVRP.jl

Extension JuMP pour les problèmes de tournées de véhicules. Modélise les arrêts, les capacités et les créneaux horaires sous forme de modèle de tournées que JuMP peut confier à n'importe quel solveur.

JuMPy

Une interface Python vers MathOptInterface. Les modèles s'écrivent une fois sous forme de gabarits et sont développés en Julia compilé, si bien que construire un grand modèle ne coûte plus davantage que le résoudre.

ContractionHierarchies.jl

Calcul de plus courts chemins sur les graphes OpenStreetMap par hiérarchies de contraction. Il construit les matrices de distances et de temps de parcours qu'un modèle d'optimisation prend en entrée.

NexOR.jl

Client Julia pour notre API de résolution. Un modèle écrit en JuMP se résout sur nos serveurs plutôt que sur la machine locale, et les résultats reviennent dans la même session.

Les mathématiques ouvertes l'emportent sur les boîtes noires.

Modèles auditables

Les passerelles de solveurs sont dans du code que chacun peut lire, et les solveurs qu'elles atteignent aussi. Les mathématiques ne sont pas une boîte noire à prendre sur parole.

Validé par la recherche

JuMP et ses solveurs sont utilisés dans les laboratoires de recherche opérationnelle du monde entier. Les modèles que nous livrons sont examinés par la communauté mondiale.

Aucun verrouillage

Les passerelles restent sur GitHub sous leurs propres licences ouvertes, quoi qu'il nous arrive. Vos données et votre base de données sont à vous, exportables à tout moment.

Adapté à vos besoins

Un solveur qui ne modélise pas votre réalité n'est qu'un logiciel lent. Nous étendons les paquets open source dès qu'une contrainte client n'est pas déjà prise en charge.

Le code d'optimisation que nous écrivons est open source

github.com/NexOR-Optimization