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
-
1947Simplex methodDantzig
années 1950
-
1954Cutting planes for the TSPDantzig, Fulkerson and Johnson
-
1957Dynamic programmingBellman
-
1958Integer cutting planesGomory
-
1959Shortest pathsDijkstra
-
1959The vehicle routing problemDantzig and Ramser
années 1960
-
1960Branch and boundLand and Doig
-
1960Dantzig-Wolfe decompositionDantzig and Wolfe
-
1961Column generationGilmore and Gomory
-
1962Benders decompositionBenders
-
1964Clarke-Wright savingsClarke and Wright
années 1970
-
1970Lagrangian relaxationHeld and Karp
-
1972NP-completenessKarp
-
1973Lin-KernighanLin and Kernighan
-
1975Genetic algorithmsHolland
-
1977Arc consistencyMackworth
-
1979Ellipsoid methodKhachiyan
années 1980
-
1983Simulated annealingKirkpatrick, Gelatt and Vecchi
-
1984Interior point methodsKarmarkar
-
1986Tabu searchGlover
-
1987Constraint logic programmingJaffar and Lassez
années 1990
-
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
années 2000
-
2005Feasibility pumpFischetti, Glover and Lodi
-
2006Adaptive large neighbourhood searchRopke and Pisinger
-
2007MiniZincNethercote and others
-
2009Lazy clause generationOhrimenko, Stuckey and Codish
années 2010
-
2017JuMPDunning, Huchette and Lubin
-
2019Learned branching heuristicsGasse and others
années 2020
-
2020Neural diving for mixed-integer programsNair and others
-
2021First-order methods for large linear programsApplegate and others
-
2023Linear programming on GPUsLu 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.
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.
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