We don't just use solvers. We build the bridges.
NexOR's optimisation team contributes to JuMP, the Julia ecosystem's modelling language for mathematical optimisation. Several of the connectors between JuMP and the solvers underneath our VRP engine live in our public repos. Run NexOR knowing the math underneath is auditable.
- 4 Public Julia packages
- EU Belgium-based
- MIT Open licences
An open-source modelling language for mathematical optimisation.
JuMP lets researchers describe an optimisation problem, routing, scheduling, network flow, mixed-integer programming, in close-to-mathematics syntax, then solve it with any of thirty-plus solver backends behind a single interface.
It is the de-facto standard in the Julia ecosystem and the backbone of optimisation research across European universities, including UCLouvain, where parts of our optimisation team trained.
- Created at MIT, used in academic research worldwide
- One model, thirty-plus solver backends
- MIT-licensed, community-maintained
Solver bridges for the Julia ecosystem.
These are some of the connectors we maintain. The bridges between JuMP's modelling language and the solvers behind the NexOR VRP engine. Open source by design.
Open math beats black-box math.
Four reasons NexOR's open-source posture is a feature, not a footnote.
Auditable models
The math behind your routes is in code anyone can read. No proprietary black box deciding what your trucks do.
Vetted by research
JuMP and its solvers are used in operations-research labs worldwide. The models we ship are scrutinised by the global community.
No lock-in
If we vanish tomorrow, the solver bridges stay alive on GitHub. You keep the math, you keep the code, you keep running.
Customer-shaped
A solver that doesn't model your reality is just slow software. We extend the open packages when a customer constraint isn't already supported.
Operations research, in the cab.
NexOR's optimisation work is grafted into the Julia language ecosystem. Members of the team are active contributors to JuMP itself, shipping pull requests against the core packages, maintaining solver interfaces, and presenting at the JuMP-dev workshop. The bridges above are not a side project. They're how we work.
- Active contributors to the JuMP core packages
- Talks at the JuMP-dev workshop
- Solver interfaces published as open source on the org
- Daily product work and research run on the same code
Got an optimisation problem we should look at?
Send us the constraints you can't model in your current tool. We come back with what's already in JuMP and what we'd build.