We are thrilled to announce the release of JuMP v0.19. Work on this release started nearly two years ago at the first JuMP-dev meetup.
As introduced in an earlier post and at the second JuMP-dev meetup, JuMP has undergone a major refactoring to replace its solver interface from MathProgBase (MPB) to the new MathOptInterface (MOI), receiving many new features and improvements along the way.
While MPB had three different interfaces: linear/quadratic, conic and nonlinear, MOI is completely generic and extensible by design:
- The objective function is described by any scalar function and the constraints are described either in the form “scalar function-in-scalar set” or “vector function-in-vector set”. The functions and sets can either be one of those defined in MOI (see http://www.juliaopt.org/MathOptInterface.jl/v0.8.1/apimanual/#Standard-form-problem-1) or any function or set defined independently in a separate package (see http://www.juliaopt.org/JuMP.jl/dev/extensions/).
- The result informations (e.g. primal/dual values, iteration count, solver time, objective bounds, statuses (which are now a lot more detailed), …) as well as model attributes and solver parameters have a unified interface, see http://www.juliaopt.org/MathOptInterface.jl/v0.8.1/apireference/#Attributes-1
MOI offers more flexibility in specifying an optimization problem than MPB, so there might be a large gap between what a solver natively supports and what is required to implement the interface. For this reason, MOI includes several utilities that can lift a solver with restricted functionality to a fully functional MOI object.
- A cache for solvers not supporting certain MOI operations (e.g. modifying a constraint, …),
- Result fallbacks for solvers not supporting certain result information
- Constraint bridges that act as recipes for transforming a constraint into an equivalent forms (See http://www.juliaopt.org/MathOptInterface.jl/stable/apireference/#Bridges-1 and https://youtu.be/C8dHxJCUHYw).
These MOI utilities are automatically used by JuMP when needed. In order to be interfaced directly with the solver without any MOI facilities in-between, we have introduced a direct mode. In direct mode, no model cache nor constraint or variable names are stored in the JuMP model. All operations are directly managed by the solver. In this mode, JuMP and MOI constitute a thin wrapper on top of the solver API. One benefit of direct mode is that it reduces the number of copies of a model kept in memory.
See the NEWS for a detailed list of changes between JuMP v0.18 and JuMP v0.19 as well as the list of known regressions from v0.18 that will be addressed in future releases.
We would like to acknowledge the following major contributors to the 0.19 release, including solver wrappers and supporting infrastructure:
- Chris Coey (for MathOptFormat)
- Carleton Coffrin (for MINLPTests)
- Oscar Dowson (for MOI, JuMP, MathOptFormat, LinQuadOptInterface, AmplNLWriter, Gurobi, and GLPK)
- Joaquim Dias Garcia (for MOI, Xpress, GLPK, and LinQuadOptInterface)
- Twan Koolen (for OSQP)
- Benoît Legat (for MOI, JuMP, SumOfSquares/PolyJuMP, StructJuMP, SemidefiniteOptInterface, CDCS, CSDP, DSDP, ECOS, Mosek, SDPA, SCS, and SeDuMi)
- Miles Lubin (for MOI, JuMP, and Ipopt)
- Vitor Nesello (for Cbc)
- François Pacaud (for Artelys Knitro)
- Robert Schwarz (for SCIP)
- Issam Tahiri (for Clp and CPLEX)
- Juan Pablo Vielma (for solver binaries: ASLBuilder, CbcBuilder, CglBuilder, ClpBuilder, ECOSBuilder, GLPKBuilder, IpoptBuilder, OsiBuilder, COINBLASBuilder, COINLapackBuilder, COINMumpsBuilder, COINMetisBuilder, CoinUtilsBuilder, SCSBuilder, and SDPABuilder)
- Ulf Worsøe (for Mosek)
Thanks to Iain Dunning for performance and testing infrastructure improvements.
We also thank all the other contributors who submitted patches, reported bugs, or provided feedback.
At JuMP-dev in Santiago next month, Miles will present the roadmap for JuMP 1.0. Stay tuned!