Introducing MosekCOModel for Rust

A few years a ago we introduced an official rust API for MOSEK. The API extended our optimizer API to the rust language. The optimizer API is designed to be a thin interface to the native C optimizer API.

 However, MOSEK has in addition to the optimizer API also the fusion API. The fusion API is specifically designed to build conic optimization models in a simple and expressive manner. With its focus on model building the fusion API acts as a compliment to the optimizer API. That compliment has now been extended to Rust.

However, due to some language specific attributes of Rust in combination of how the fusion API is constructed there is not a straight forward way to extend the fusion API to Rust. Hence, we like to introduce mosekcomodel!   

The Rust crate mosekcomodel is a Rust package for formulating and solving convex conic optimization models.  While it looks somewhat like the MOSEK fusion API (for Python, Java, .NET and C++), it is a
fully Rust native package exploiting Rust's type system zero-cost abstractions to make it simpler and faster to write correct models.

The crate provides a model-oriented interface for defining conic models and a
library of functionality for formulating affine expressions.

The model

The models that mosekcomodel can formulate has the form 

$min/max$ $c^Tx + c_f$

$subject$ $to:$ $A x + b \in K_1  \times ... \times K_m$

                        $x \in C_1 \times ... \times C_k$

Where $Ax+b$ is an affine expression in the variable $x$ and $K_i$ and $C_i$ are conic sets. Additionally, mosekcomodel supports integer variables and disjunctive constraints  

Currently mosekcomodel supports all cone types that MOSEK supports:

• Linear bounds: Equalities and inequalities,
• Second order conic constraints: Quadric cone and rotated quadratic cone,
• Semidefinite cone and scaled vectorized semidefinite cone,
• primal and dual power cones
• Primal and dual geometric mean cones, and 
• Primal and dual exponential cones.

The API

The three basic concepts in the API are the model, the variable and the constraint.

The model object defines the API for setting up the model and communicating it to an underlying solver. Through this object constraints and variables are created. A variable can be regarded as an n-dimensional array of scalar variables, the dimensionality is part of the type, while the actual dimensions are only defined at runtime. By extension, expressions created from variables are also n-dimensional arrays of scaler affine expressions. When a constraint is created from an expression and a domain, the shape of the expression and the domain must match, and the constraint inherits this dimensionality and shape.

The outline of a simple model could look like this:

	use mosekcomodel::*;
	let mut model = Model::new(Some("MyModel"));
	let x = model.variable(Some("x"), nonnegative().with_shape(&[3]));
	model.constraint(Some("c"), x.add(x.mul(2.0)), in_range(-5.0,5.0));
	...
	model.solve();
	...
	let xsol = model.primal_solution(SolutionType::Default, &x);

view raw simpleModel.rs hosted with ❤ by GitHub

Unfortunately, while Rust does allow operator overloading, the definitions for the operators for plus, minus, multiplication and indexing, that would be useful are too restrictive for this use. So for now we are stuck with functions like .add() and .mull()

Constraint expressions are purely linear, and the crate provides functions to create and manipulate expressions: Reshaping, transposing, stacking, slicing and multiplying by matrices, vectors and constants and so on.

Expression evaluation is lazy, meaning that an expression is only evaluated once it is used in a constraint.

Example: Portfolio optimization

The following is a working example of a basic conic quadratic Markowitz portfolio model implemented with mosekcomodel.

	use mosekcomodel::*;
	/// Computes the optimal portfolio for a given risk
	///
	/// # Arguments
	/// * `n` Number of assets
	/// * `mu` An n dimmensional vector of expected returns
	/// * `gt` A matrix with n columns so (GT')*GT = covariance matrix
	/// * `x0` Initial holdings
	/// * `w` Initial cash holding
	/// * `gamma` Maximum risk (=std. dev) accepted
	/// # Returns
	/// The expected return for the optimal portfolio.
	fn basic_markowitz( n : usize,
	mu : &[f64],
	gt : &NDArray<2>,
	x0 : &[f64],
	w : f64,
	gamma : f64) -> f64 {
	let mut model = Model::new(Some("Basic Markowitz"));
	// Redirect log output from the solver to stdout for debugging.
	// if uncommented.
	model.set_log_handler(|msg| print!("{}",msg));
	// Defines the variables (holdings). Shortselling is not allowed.
	let x = model.variable(Some("x"), nonnegative().with_shape(&[n])));
	// Maximize expected return
	model.objective(Some("obj"), Sense::Maximize, x.dot(mu));
	// The amount invested must be identical to intial wealth
	model.constraint(Some("budget"), x.sum(), equal_to(w+x0.iter().sum::<f64>()));
	// Imposes a bound on the risk
	model.constraint(Some("risk"),
	vstack![Expr::from(gamma).reshape(&[1]),
	gt.mul(&x)], in_quadratic_cone());
	// Solves the model.
	model.solve();
	let xlvl = model.primal_solution(SolutionType::Default, &x).unwrap();
	mu.iter().zip(xlvl.iter()).map(|(&a,&b)| a*b).sum()
	}

view raw portfolioExample.rs hosted with ❤ by GitHub

Conclusions

While the mosekcomodel is under active development, it is already a very useful tool for formulating optimization models in Rust. What it needs most right now is people using it and giving us feedback!

Geometric Programming Toolbox

As highlighted in a recent linkedIn post by Elmor Peterson Geometric Programming (GP) is an old subfield within optimization with applications in integrated circuit design, aircraft design and control theory amongst others.

Although GP models them self are not convex they can always be converted into a convex model.

To facilitate GP modeling we have made a GP toolbox that makes these transformations for you. To learn more about GP and play around with the toolbox check out the Marimo notebook.

Credit for the notebook goes to our student worker Izgi Tulunay.