MOSEK in the browser and OptServer

Although both installing MOSEK and obtaining a trial license are very easy, it is now possible to get to know MOSEK directly in the browser with one click and no setup at all.

Python

With a Google account you can run MOSEK in Google Colab notebooks. Click below to open the sample MOSEK Colab notebook in your user space and run it.

Open in Colab

(You can also just download the notebook and run it in Jupyter or your favorite environment, but that's more than one click). Since this is a complete MOSEK installation in Python, the full Optimizer and Fusion APIs are available.

Javascript Fusion

The Fusion API is experimentally available in Javascript. Just click below to open the editor in the browser and start coding and solving optimization problems in our Fusion API.

https://solve.mosek.com/fusion.html

An almost complete Fusion API is mapped through and you can run a number of ready examples.

How does it work?

The key to the simplicity lies in the fact that the actual optimizations are performed on our freely available demo Optimization Server (OptServer) running at https://solve.mosek.com. On that page you can also find instructions for invoking remote optimization in all other MOSEK interfaces; that's how the Python notebooks calls the OptServer. The Javascript package runs the Fusion layer modeling in the browser and sends a JSON task object for remote optimization.

Our online demo server has problem size limits. If you like the concept of remote optimization it is almost as easy as this to set up your own demo OptServer in a docker container and use that to optimize.

Apple Silicon M1 plans

In response to the recent questions about MOSEK support for the new Apple Silicon M1 ARM64 architecture:

We plan to support the new Apple chips in the next major release, that is MOSEK 10. The release date is not yet set. Until we have access to the new platform we cannot make any guarantees regarding the MOSEK performance.

Please contact us if you have questions or plans related to MOSEK on the new Mac.

The MOSEK team

Fusion and the art of harvesting potatoes

Week 42 in Denmark was "kartoffelferie" - fall school vacation originally designed to allow children help with the potato harvest on the farm. The vacation is still present even though kids no longer collect potatoes, except for...

... Lærke. Lærke has her own little potato field arranged in an $n\times n$ grid. For some squares of the grid she knows the exact number of potatoes that can be harvested from that square, between $0$ and $3$. She wants to design a round trip around her little field so that each of those squares will be passed by just the right number of times to pick the potatoes, one on each pass. Other squares can be passed by any number of times. A picture with a sample layout and its solution is worth a thousand words:

Now Lærke notices that she can easily write a mixed-integer model of her problem. She will associate a binary variable with each edge of the grid, to indicate if it appears in the tour, and then needs to ensure that:

• (1) every vertex of the grid meets either 0 or 2 of the tour edges,
• (2) every square with $i$ potatoes has exactly $i$ tour edges on its boundary.

That will not necessarily give Lærke one closed tour, but possibly a disjoint union of cycles. A subtour elimination scheme similar to the one used for TSP could be built on top to get a single tour. Luckily, Lærke is not so worried about that - her basket is quite small so she is happy to make a few trips anyway. What she is much more interested in is that each of the constraints (1) and (2) can be implemented basically as a one-liner in Fusion by appropriate stacking and slicing and that she can see it all and try it out live here:

https://solve.mosek.com/fusion.html?ex=slitherlink

Finally, as much as Lærke is just our imaginary MIP user in the food industry, the puzzle actually exists and is known as Slitherlink.

Bon appétit!

(images by GLmathgrant, under CC BY-SA 3.0, from Wikipedia)

CVXPY 1.1.6

The latest release 1.1.6 of CVXPY includes a completely rewritten MOSEK interface. It will, in particular, reformulate conic and linear problems in a different way than until now before passing it to the solver, so you may experience different behavior, especially in numerically challenging cases.

Here is roughly what you should expect. If you are modeling:

• a mixed-integer problem: no change.
• a sparse LMI: the new version should be much more efficient, both in terms of CVXPY modeling and solution time (the problem is dualized before calling MOSEK).
• all other linear and conic problems: the problem will be dualized before calling the solver. Ideally you should see no difference or perhaps an improvement, but it can go either way, especially if the dualized version is more challenging for any reason. In many cases MOSEK will internally choose the correct form to solve. In the remaining cases it may be necessary to explicitly force the solver to dualize.
  
  If you were already tuning some MOSEK parameters then you should reevaluate the settings. In case you were already forcing primal/dual form with iparam.intpnt_solve_form then most likely you should change to the opposite.
  
  Finally, if you are studying the solver log output, keep in mind that it is operating with the dual of your CVXPY formulation (DUAL_INFEASIBLE means your problem is primal infeasible, minimization becomes maximization etc.). 

See also a note in CVXPY docs.

Sharpe ratio - derivation and Fusion model

We are being frequently asked about the Sharpe ratio, its formulation in the conic framework, and implementation in Fusion. This involves a class of problems with an objective of the type $$\mathrm{maximize}_x\quad \frac{r^Tx-r_f}{\|Fx\|_2}$$ i.e. an affine function over a 2-norm, where $r^Tx-r_f>0$, $x\in\mathbb{R}^n$. In practical portfolio optimization $r$ would be the vector of expected returns, $r_f$ is the risk-free return rate, $x$ is the vector of asset allocations and $\|Fx\|_2 = \sqrt{x^T\Sigma x}$ is the risk associated with the covariance matrix $\Sigma$ (formulating the risk term as a 2-norm is standard and we don't go into details, see here or here). Typically there will be various constraints on $x$, for example $$\mathbb{1}^Tx=1,\ x\geq 0$$ would correspond to a fully invested portfolio with no short-selling.

Let us explain step by step how one can derive a conic formulation of (1) suitable for a solver like MOSEK. We present it in detail so that the reader can apply it almost verbatim to more complicated models of this kind. First, note that if we could fix $$r^Tx-r_f=\mathrm{const}$$ then the objective would be equivalent to minimizing $\|Fx\|_2$, that is a standard second-order cone problem. However, we don't know in advance what "const" should be. (In fact solving the problem for all values of "const" corresponds to computing the efficient frontier.) Therefore, for reasons which will become clear in a moment, we denote the "const" value by $1/z$, where $z\geq0$ is a new scalar variable, i.e. $$r^Tx-r_f=1/z$$ that is $$zr^Tx-r_fz=1.$$ Denoting $y=zx$ ($y$ is now a new vector variable) the last equation becomes $$r^Ty-r_fz=1.$$ Now $x=y/z$ and the objective function becomes $$\frac{r^Tx-r_f}{\|Fx\|_2} = \frac{1/z}{\|F\frac{y}{z}\|_2} = \frac{1}{\|Fy\|_2}$$ hence we can write the original problem as $$\begin{array}{rl}\mathrm{minimize}&\|Fy\|_2\\ \mathrm{s.t.} & r^Ty-r_fz=1,\\ & z\geq 0.\end{array}$$ Note that the new problem involves variables $y$ and $z$, but $x$ has been eliminated. Any additional constraints must also be reformulated by substituting $x=y/z$, for example $\mathbb{1}^Tx=1,\ x\geq 0$ becomes $$\mathbb{1}^Ty=z,\ y\geq 0$$ and in fact any other linear constraint $Ax=b$ becomes $$Ay=bz.$$ A solution $(y,z)$ to the reformulation gives a solution $x=y/z$ to the original problem (assuming that the problem has a feasible point with $r^Tx-r_f>0$, so that the reformulation has a solution with $z>0$).

Certain other types of constraints can also be carried through the reformulation. For example a cardinality constraint on $x$ (at most $k$ entries in $x$ are nonzero) can be imposed on $y$ using the same mixed-integer model. Another quadratic bound of the form $\|Hx\|_2\leq 1$ will become $\|Hy\|_2\leq z$ using $x=y/z$.

A sample Fusion implementation can be found here:

https://solve.mosek.com/fusion.html?ex=sharpe

Sven Wiese at CO@Work

Our very own Sven Wiese talks about "Convex Optimization via Cones and MOSEK 9" at CO@Work. See the talk at:

https://youtu.be/cGpWM2mIpC4

PDF of the slides:

https://docs.mosek.com/slides/2020/cowork/wiese_mosek.pdf

Full program:

http://co-at-work.zib.de/#schedule

CO@Work 2020

From our colleagues organizing the Combinatorial Optimization at Work 2020 summer school CO@Work 2020 here is a short advert of this very interesting event:



In its sixth instantiation, CO@Work will be a full online event, taking place from September 14 to 26, 2020.

This summer school addresses master students (in their final year), PhD students, post-docs and everyone else interested in combinatorial optimization and mathematical programming in industrial applications. Lectures will be held by around 30 experts from all over the world, including leading researchers from TU Berlin, FU Berlin, Polytechnique Montréal, RWTH Aachen, University of Southern California, University of Edinburgh, TU Darmstadt, University of Exeter as well as developers and managers of FICO, Google, Amazon, SAP, Siemens, IBM, SAS, Gurobi, Mosek, GAMS, Litic, and many more speakers.

We arranged a setup that allows us to cover all time zones: pre-recorded lectures plus two live Q&A sessions and two hands-on exercise sessions per day (11 hours apart).

You can find more information and a registration link here: http://co-at-work.zib.de/

Registration is for free, and as a TU Berlin course, it gives 10 ECTS credit points.

To upgrade or not to upgrade that is the question

A customer complained yesterday that Mosek version 7.1 did not run on a recent AMD CPU. Perhaps not that surprising since the last version 7.1 release was in 2016 and any case that version is no longer supported. 

Now we tried to run Mosek version 8.1 and 9.2 on the public available benchmark problem pds-90 on a recent Dell server with a

AMD EPYC 7402P 24-Core Processor

CPU. Version 8.1 took 169 seconds whereas 9.2 took 67 seconds. The reason for the huge difference is that Mosek normally employs the Intel MKL Blas library to perform dense matrix operations quickly. However, it performs poorly on recent AMD CPUs. Therefore starting in version 9 we switch to the Blis library when running on AMD CPUs. That switch provides the big boost.

So from this we can learn that upgrading to a newer Mosek version can provide a huge performance boost. Particularly when Mosek is employed on brand new hardware.

Now the customer was not too keen to upgrade from version 7.1 to version 9.2. Supposedly fearing compability issues which is understandable. However, if he had upgraded to version 8.1 earlier then the upgrade to version 9.2 would have been smaller. Therefore, by not upgrading you of course save some hassle but you pay the price the date you are forced upgrade. That date might be the date when your old Mosek version performs poorly on your brand new hardware.

Therefore, we recommend not to fall too much behind with upgrading. In particular if for instance version 9 is the current major version then you should at least be using a version 8.

n-queens in Fusion

In a nice post on LinkedIn by Alireza Soroudi the author presents a short GAMS integer model for the classical n-queens puzzle: place the maximal number of non-attacking queens on an $n\times n$ chessboard.

We couldn't resist writing it up in Python Fusion as well.

And here is the solution we get for $n=8$:

[[_ ♕ _ _ _ _ _ _]

 [_ _ _ _ _ ♕ _ _]

 [♕ _ _ _ _ _ _ _]

 [_ _ _ _ _ _ ♕ _]

 [_ _ _ ♕ _ _ _ _]

 [_ _ _ _ _ _ _ ♕]

 [_ _ ♕ _ _ _ _ _]

  [_ _ _ _ ♕ _ _ _]]

Grouping in Fusion

We sometimes get asked how to efficiently perform a "group by" operation on a variable. That is, we have a variable $x=(x_0,\ldots,x_{n-1})$ naturally divided into groups and we want to add constraints for each group or constraints on aggregate values within groups. This arises for instance in portfolio optimization where the groups are assets, each consisting of a (varying) number of tax lots.

To keep the discussion more concrete, suppose we have a variable $x=(x_0,x_1,x_2,x_3,x_4,x_5)$ which consists of 3 groups $(x_0,x_1,x_2)$, $(x_3)$ and $(x_4,x_5)$. Let's say we want to express:

• an upper bound $b_i$ on the total value within each group,
• a joint volatility constraint such as $$\gamma\geq\left\|G\cdot \left[\begin{array}{c} x_0+x_1+x_2-i_0 \\ x_3-i_1 \\ x_4+x_5-i_2\end{array}\right]\right\|_2$$ for some matrix $G$ and constant index weights $i_0,i_1,i_2$
• the constraint that all values within one group have the same sign.

Pick, slice

A straightforward solution is to pick (Expr.pick) the content of each group into a separate view and add relevant constraints in a loop over the groups. One could also take slices (Expr.slice) when the groups form contiguous subsequences. This approach is implemented below in Python Fusion.

Loop-free

The previous solution requires picking and stacking expressions in a loop over all groups. This can sometimes be slow. A nicer and more efficient solution uses a bit of linear algebra to perform the grouping. We first encode the groups via a sparse membership matrix $\mathrm{Memb}$, where the rows are groups, columns are entries of $x$, and there is a $1$ whenever an entry belongs to a group. In our example $$\mathrm{Memb}=\left[\begin{array}{cccccc}1&1&1&0&0&0\\0&0&0&1&0&0\\0&0&0&0&1&1\end{array}\right] .$$

This matrix is easy to construct in Fusion. 

Note that $\mathrm{Memb}\cdot x$ is the vector of all group sums, in our case $$\mathrm{Memb}\cdot x = \left[\begin{array}{c} x_0+x_1+x_2 \\ x_3 \\ x_4+x_5\end{array}\right].$$

That means we can express both of the previous models in a single call without looping. Since $\mathrm{Memb}$ is very sparse, this becomes a very efficient representation. Of course it is important to keep $\mathrm{Memb}$ as a sparse matrix.

Loop-free same sign

We can now use the same matrix to model the last problem from the introduction: all entries within each group must have the same sign. We introduce a sequence of binary variables $z=(z_0,\ldots,z_{g-1})$, one for each of the $g$ groups. The $j$-th variable will determine the sign of elements in the $j$-th group. That is imposed by constraints $$-M(1-z_j)\leq x_i\leq Mz_j,$$ whenever $x_i$ belongs to $j$-th group. We can use the pick/slice strategy per group, as before, or observe that $\mathrm{Memb}^T\cdot z$ produces the vector with the correct binary variable for each entry in $x$. I our case, if $z=(z_0,z_1,z_2)$ then $$\mathrm{Memb}^T\cdot z = (z_0,z_0,z_0,z_1,z_2,z_2)^T.$$ Now each inequality in (4) can be written as a single constraint:

Easter 2020

Support and sales are closed from Thursday, Aptil 9th, until Monday, April 13th, inclusive.

The MOSEK team wishes everyone safe Easter.

Coronavirus COVID-19

March 11th: As of now Denmark locks down for at least 2 weeks in response to the coronavirus pandemic. In the interest of public health we close the MOSEK physical office and continue working from home. At the moment we don't expect any major disruptions, although small delays in e-mail responses are possible. Thank you in advance for your patience.

March 16th: If you are working from home and for this reason require some special arrangements regarding the license, send us an email to support@mosek.com.

We will update this post if there is important new information.

Parametrized Fusion - benchmarks

We present some indicative benchmarks of the new Parametrized Fusion, to be released in MOSEK 9.2. We compare a few typical optimization models being reoptimized in two scenarios:

• the model is constructed from scratch with new data for each optimization, MOSEK version 9.1 (green bars)
• the parametrized model is constructed once and parameters are set before every optimization, MOSEK version 9.2 (blue bars)

The red bar in all cases represents the amount of time spent in the optimizer.

1. Markowitz portfolio optimization

Here we consider a simple model

$$\begin{array}{ll}\mbox{maximize} & \mu^T x \\ \mbox{subject to} & e^Tx=1,\\                                & \gamma \geq \|Fx\|_2, \\                              & x\geq 0, \end{array}$$

where

• $x\in\mathbb{R}^{2000}$,
• $F\in \mathbb{R}^{200\times 2000}$ is a dense matrix,
• $\gamma$ is the only parameter changed between optimizations,
• we resolve the model for 200 values of $\gamma$.

Note that by parametrizing we avoid inputting the same big matrix $F$ over and over again.

2. Various models

Next we run a few models implemented in Python only.

• MPC - Model Predictive Control similar as in this demo with 15 states, 8 inputs, horizon length $T=80$, parametrized by the initial state, 100 resolves,
• Polytopes - a geometric polytope containment problem, the parameter is a $3\times 3$ matrix $P$ which enters in many constraints of the form $Px=y$, 1000 resolves.
• Elastic - a linear regression model with main term $\|Ax-b\|_2$, where $A\in\mathbb{R}^{3000\times 100}$ is dense, parametrized by $b\in\mathbb{R}^{3000}$, 60 resolves.
• Option - a big option pricing model with complicated structure and multiple parameters, 10 resolves.

CVX 2.2 supports exponential cone in MOSEK

New features in CVX!

The last release 2.2 of CVX comes with support for the exponential cone in MOSEK. It means that problems involving log, exp, rel_entr, log_det, kl_div and other variants of logarithms and exponentials will be passed directly to a single MOSEK solve without employing a successive approximation method.

CVX 2.2 also comes bundled with the very recent MOSEK 9.1.9.

For an example of a log_det problem with MOSEK output in CVX 2.2 see:

http://web.cvxr.com/cvx/examples/log_exp/html/sparse_covariance_est.html

(Note, though, that the CVX warning about using the successive approximation method is still displayed, but if your log output consists of a single Mosek solve like above then it can be ignored.)

Price list change from June 1st, 2020

Our price list will change from June 1st, 2020. Prices change for the first time since June 2015 and increase on average by 5.4%.

New prices can be found at https://www.mosek.com/sales/prices-from-june-1st-2020/.

(This move was postponed until October 2021 due to COVID-19).

MOSEK 9.2 Beta - Parametrized Fusion

We are releasing a beta version of MOSEK 9.2. It is a direct continuation of version 9.1 and fully compatible with its predecessor.

The new feature introduced in version 9.2 is parametrization of Fusion models, that is the ability to build a Fusion model containing parameters and reoptimize it multiple times for varying input data without rebuilding the model from scratch.  This is particularly useful for optimizing many instances of a problem with identical structure, where some of the input data change.

For more information, with links to examples in C++, Python, Java and C#, see our website:

https://www.mosek.com/content/version-9-beta/

In near future we will publish more examples of parametrized models as well as related benchmarks.

MIP 2020

MOSEK is proud to be one of the sponsors of MIP2020 - Mixed Integer Programming Workshop 2020 feat. DANniversary, taking place May 18–21, 2020 at DIMACS, Rutgers University.

See https://sites.google.com/view/mipworkshop2020 for more details.