CasADi - A software framework for nonlinear optimization and optimal control

Abstract

Install Grab a binary from the table: Windows Linux Mac classic (High Sierra or above) Mac M1 Matlab R2018b or later R2018b or later R2018b or later R2023b or later (Apple Silicon) R2018b or later (Rosetta) Octave 6.2.0 or later 6.2.0 or later 6.2.0 or later 6.2.0 or later Python pip install casadi (needs pip -V>=8.1) or wheel below. Note that we adopted Python Stable ABI, so Python 3.12, 3.13, 3.14, etc should all work with the `cp311-abi3` variant. Javascript npm install @casadi/casadi-wasm For Matlab/Octave, unzip in your home directory and adapt the path: addpath(' /casadi-3.8.1-windows64-matlab2018b') Check your installation: Matlab/Octave Python Javascript import casadi.* x = MX.sym('x') disp(jacobian(sin(x),x)) from casadi import * x = MX.sym("x") print(jacobian(sin(x),x)) require("@casadi/casadi-wasm")() .then(ca => { const x = ca.MX.sym("x"); const J = ca.jacobian(ca.sin(x), x); console.log(J.toString()); }); Get started with the example pack. Onboarding pointers have been gathered by the community at our wiki. Troubleshooting Release notes These notes cover the 3.8 series; additions specific to the patch release are marked 3.8.1. New frontends CasADi gains two new language front-ends, each with a set of examples under docs/examples shipped in the example pack. This is experimental work. Users are encouraged to try it out and post any bugs. Julia CasADi can now be driven from Julia without Python intermediary, thanks to an extension of SWIG. The example docs/examples/julia/simple_nlp.jl should look fairly familiar to seasoned CasADi Python users: import CasADi as ca x = ca.SX.sym("x", 2) f = x[1]^2 + x[2]^2 # objective g = x[1] + x[2] - 10 # constraint: x0 + x1 - 10 >= 0 nlp = Dict("x" => x, "f" => f, "g" => g) solver = ca.nlpsol("solver", "ipopt", nlp) sol = solver(lbg = 0) println("primal solution = ", sol["x"]) 3.8.1: Updated the Julia bindings for Julia 1.13 compatibility (commit). JavaScript / WebAssembly CasADi now runs in the browser and in Node.js as a WebAssembly module (#4355), distributed on npm. As JavaScript has no operator overloading, expressions are built with functional forms such as ca.plus/ca.times (from docs/examples/javascript/simple_nlp.js): const ca = await require("@casadi/casadi-wasm")(); // load the WebAssembly module const x = ca.SX.sym("x", 2); const [x0, x1] = ca.vertsplit(x); const nlp = { x: x, f: ca.plus(ca.times(x0, x0), ca.times(x1, x1)), // objective g: ca.minus(ca.plus(x0, x1), ca.SX(10)) }; // x0 + x1 - 10 >= 0 await ca.load_nlpsol("ipopt"); // 3.8.1: load the plugin before use const solver = ca.nlpsol("solver", "ipopt", nlp); const sol = solver.call({ lbg: ca.DM(0) }); console.log("primal solution = " + sol["x"]); The same module loads straight from a CDN (e.g. unpkg.com/@casadi/casadi-wasm), so if you are into vibecoding self-contained HTML pages, you can now drop a full CasADi optimization - IPOPT and all - into a single static .html file with no build step (see docs/examples/javascript/unpkg_demo.html). 3.8.1: Fixed WebAssembly plugin packaging, transitive dependencies and browser loading. Await ca.load_nlpsol("ipopt") (or the appropriate load_* method) before constructing a solver; concurrent loads share a request and failed loads can be retried (commit). ONNX interoperability CasADi can now bridge to the ONNX ecosystem in two complementary ways, so that trained neural networks and other ONNX graphs can participate directly in CasADi computations: Black-box evaluation (#4209): an ONNX model can be loaded and evaluated as a CasADi Function, backed by ONNX Runtime. The model is treated as an opaque, dtype-aware box; derivatives are provided through finite differences, or by AD if the ONNX writer augmented the graph with appropriately-named output nodes. Symbolic translation (#4246): an ONNX graph can instead be imported into native CasADi expressions, and CasADi expressions can be exported back to ONNX. Imported this way, a model is differentiated analytically by CasADi like any other expression and takes part in code generation. Both modes are driven through a new GraphBuilder class: # Black-box: load an ONNX model and evaluate it as a CasADi Function f = ca.GraphBuilder("model.onnx").create("f") print(f(ca.vertcat(0.5, 1.0, -2.0))) # Symbolic: import the model into native, differentiable CasADi expressions ... g = GraphBuilder("model.onnx").create("g", {"symbolic": True}) # ... or export a CasADi Function back to ONNX GraphBuilder(f).export_onnx("roundtrip.onnx") This is a new capability and still evolving. The symbolic translation is available when CasADi is built with WITH_ONNX; the ONNX Runtime black-box backend additionally requires WITH_ONNX_RUNTIME (which forces WITH_ONNX). 3.8.1: Black-box ONNX Functions can discover derivatives in sibling files: for f.onnx, supply fwd_f.onnx, adj_f.onnx or jac_f.onnx. Models are loaded on demand, and the same convention supports nested derivatives such as adj_adj_f.onnx (#4411). 3.8.1: Improved symbolic import of PyTorch-exported models, including Constant, Reshape and Slice handling. Structural integer constants retain their precision, and floating-point inputs/outputs are identified as differentiable (import fix, integer and differentiation fix). 3.8.1: Fixed ONNX Runtime packaging: builds using the runtime adaptor can load a real ONNX Runtime library via CASADI_ONNXRUNTIME_LIB, replacing the non-functional stub previously shipped (#4406). ONNX code generation also received runtime and header fixes (runtime fix, header fix). More efficient matrix multiplication CasADi was historically targeted at small/medium heterogeneous dynamic systems, where dense-dense multiplication is typically rare and not a computational bottleneck (though large sparse-sparse products do play an important role). This release closes the remaining gaps so that dense-heavy workloads are no longer penalized: The CasADi runtime now has a specialization for dense-dense multiplication (previously only the code generator had one) (#4292). The CasADi runtime and code generator now have a specialization for dense-sparse multiplication. mtimes, in both the runtime and the generated code, now takes an extra "BLAS argument" that selects which multiplication kernel is used. For dense problems you can choose between the built-in reference kernel, whatever BLAS CasADi was built against, and blasfeo: mtimes(A, B) # default: built-in reference kernel (triple loop) mtimes(A, B, "reference") # same -- explicit mtimes(A, B, "classic") # whatever was built into CasADi via WITH_LAPACK (typically OpenBLAS) mtimes(A, B, "blasfeo") # uses blasfeo The blas argument is ignored when either operand is sparse. Symbolic expressions det(A, lsolver) computes a determinant through a linear-solver factorization (e.g. CSparse LU, symbolic_qr) instead of cofactor expansion, making determinants of large, sparse matrices practical (#2821). Thanks @nielsvd (Niels van Duijkeren). B-splines now accept symbolic knots: the bspline constructor takes its knots (and coefficients) as MX, so knot positions can be supplied or differentiated at evaluation time rather than baked in at construction. The specialized blazing_spline now supports up to five input dimensions and a parametric-knots variant whose knots are a symbolic input. A new dump node provides an alternative to monitor for inspecting intermediate values during evaluation (#4306). kron (Kronecker product) is now backed by a dedicated MX node (#939). breaking: comparing an SX and an MX with == now raises an error instead of silently returning False (#2817). Reverse-mode derivatives of Functions with structurally-sparse (e.g. upper-triangular) inputs now behave consistently between SX and MX (#4345). Using linspace with MX symbols as start/end points no longer causes the number of nodes to blow up (#3531). Computing the Jacobian of a subset of constraints no longer produces more nodes than the Jacobian of all constraints in certain cases (#4354). Multiplying with a complex matrix now raises a TypeError instead of segfaulting (#4216). Fixed a zero-by-N inconsistency (#3977) and a non-identity transform issue in eval_mx (#2934). SX::set_precision is now respected when printing SX (#