Friday, March 4, 2016

Reformulating a non convex MINLP as MISOCP


Few weeks ago we read a nice and interesting post here.

The author took inspiration from a previous post on an open forum to show how the intuitive formulation of a simple problem can lead to a non convex MINLP when a MIQP can be used instead.

In this post we will
  • show how to reformulate the proposed MIQP problem as an MISOCP,
  • implement the MISOCP model using MOSEK Fusion API,
  • derive a more compact MISOCP formulation and
  • implement the second model using MOSEK Fusion API as well.

The problem is the following: we are given $N$ power unit (in the original post ovens) that must be used to provide a required amount $T$ of energy. Each plant contributes an amount $x_i$ of energy.

The inefficiency of each plant is given by

\[
g_i(x_i) = \left\lbrace \begin{array}{ll} 100 \sum_ i \frac{(a_i - x_i)^2}{a_i} & x_i>0,\\
0& x_i=0.  \end{array}\right.
\]

where $a_i$ is the optimal operational level of the plant. Moving away from $a_i$ leads to inefficient use of the plant. Here there is an example for $a_i = 10 $.





The overall inefficiency is then

\[
f(x) = \sum_i g_i(x_i).
\]

We want to minimize the inefficiency still providing the amount $T$ of energy.

A simple approach is to use an indicator variable $y_i$ to represent the $i-$th plant activation. Assuming we know an upper bound $M_i$ to the power each plant can produce, the model takes the form

\begin{equation}
\begin{array}{lll}
\min & 100\sum_i y_i \frac{(a_i - x_i)^2}{a_i} \\
&\\
s.t. & \sum_i x_i = T\\
& x_i \leq y_i M_i & i=1, \ldots, N\\
& x_i \geq 0 & i=1, \ldots, N,
& y_i \in \{0,1 \} & i=1, \ldots, N.\\ \end{array}
\end{equation}


As noted in the original post, this is a non-convex NLP. A simple reformulation allows to remove the bilinear term $x_i y_i$:



\begin{equation}
\begin{array}{lll}
\min & \sum_i \frac{d_i^2}{a_i} \\
&\\
s.t. & \sum_i x_i = T\\
& x_i \leq y_i M_i & i=1, \ldots, N\\
& -M_i(1- y_i) \leq s_i \leq M_i(1-y_i)  & i=1, \ldots, N\\
& d_i = a_i - x_i +s_i  & i=1, \ldots, N\\
& x_i \geq 0 & i=1, \ldots, N,\\
& y_i \in \{0,1 \} & i=1, \ldots, N.\\ \end{array}
\end{equation}


The trick is simple: an active plant $y_i=1$ implies $s_i=0$ and therefore $d_i = a_i - x_i$. But for $y_i =0$ the slack variable $s_i$ is free, while $x_i=0$. This implies that $d_i$ is free to assume any value, and since we are minimizing its second power, it will be driven to zero as well.

In conic form the problem reads



\begin{equation}
\begin{array}{lll}
\min & t\\
&\\
s.t. & \sum_i x_i = T\\
& x_i \leq y_i M_i & i=1, \ldots, N\\
& -M_i(1- y_i) \leq s_i \leq M_i(1-y_i)  & i=1, \ldots, N\\
& d_i = a_i - x_i +s_i  & i=1, \ldots, N\\
& (1/2, t, d_1/\sqrt{a_1}, \ldots,  d_n/\sqrt{a_N}) \in \mathcal{Q_r}\\
& x_i \geq 0 & i=1, \ldots, N,\\
& y_i \in \{0,1 \} & i=1, \ldots, N.\\ \end{array}
\end{equation}

Those not used to conic formulation may refer to our modeling cookbook.

The Fusion implementation is the following 





The code is very compact and readable, no need for many comments. The only operators one may wonder about are

  • vstack - it returns an array stacking its argument vertically,  
  • mulElm - it performs element wise multiplications.


Now we ask: is there a more compact formulation? 

The answer is yes: the purpose of the slack variables is to remove the contribution to the inefficiency that a deactivated oven will provide anyway. That contribution is simply equal to $a_i$. Therefore we only need to subtract $a_i$ if $y_i=1$.



\begin{equation}
\begin{array}{lll}
\min & t - \sum_i a_i ( 1- y_i)\\
&\\
s.t. & \sum_i x_i = T\\
& x_i \leq y_i M_i & i=1, \ldots, N\\
& (1/2, t, (a_1 -x_1)/\sqrt{a_1}, \ldots, (a_N - x_N)/\sqrt{a_N}) \in \mathcal{Q_r}\\
& x_i \geq 0 & i=1, \ldots, N,\\
& y_i \in \{0,1 \} & i=1, \ldots, N.\\ \end{array}
\end{equation}



which translates to the following code:





As one can see, the code is more compact, clean and readable. Fusion helps implementing conic optimization models in short time with a remarkable simplicity.


Last observation: the proposed problem is indeed simple to formulate, but the intuition leads to a non-convex MINLP. That is typical, but luckily in this case with a bit of work we can actually move to a MIQP formulation first, and a MISOCP then. And the final MISOCP comes with no additional variables at all.

Investing time on the model pays!


Tuesday, February 23, 2016

Personal Academic Licenses


We have recently experienced technical issues that have prevented us to provide personal academic licenses (see our recent blog post). Academic users trying to apply or renew personal academic licenses have got an error message instead.

The service is now up and running and academic users can obtain fully-featured personal academic licenses at



Please let us know if any other issues arises.

We do apologize for the inconvenience.


The MOSEK Team.

Thursday, February 4, 2016

Trial license server not working

Our academic trial license server is currently malfunctioning. 

Due to a technical issue, academic license requester will get an error from our server.

The error has been introduced by a recent update.

We are working on the issue and hope to resolve it as soon as possible. In the mean time, please grab 30 days commercial trial licenses instead at



Contact us at info@mosek.com if any other issue arises.

We apologize for the inconvenience.

The MOSEK team

Friday, July 24, 2015

MOSEK on GitHub

We are glad to announce that MOSEK has open its own page on GitHub:


The main purpose is to host repositories where we will publish additional material such as

  • utilities,
  • tutorials,
  • simple toolboxes,

that we develop as part of our daily activities. GitHub is the natural tool to make such small tools available to the general public: it is free, many people already have an account and works well!

We think it is another great way to share our work with users and help them get the most out of MOSEK. 

You are encouraged to submit issues and propose enhancements, as well as feedback! Nothing is more valuable than user experience... 

The code available on the GitHub comes as-is, and it does not fall under the terms of the MOSEK EULA.  Suitable licenses are included, typically MIT license for code and Creative Common BY for tutorial and other training material.


Monday, May 4, 2015

Price list change from June the 1st 2015


With effect on the June the 1st 2015 our price list will change. 


  • PTS floating license: \$1950  (annual maintenance fee \$487.5)
  • PTS server license: \$7800 (annual maintenance fee \$1950)


All other prices remain unchanged.

The change reflects the new functionality and interfaces provided in the PTS package.

Contact us for more information by email at sales@mosek.com

Friday, April 17, 2015

MOSEK and platform support

At MOSEK we are occasionally asked if we can support new platforms such as
  • Dspace MicroAutoBox
  • HP UX (has been supported)
  • Various mainframe operating systems
  • QNX (did a port in 2014)
  • Solaris (has been supported)
  • VxWorks 
Although we are quite sure we can adapt MOSEK to run on almost any platform, we are reluctant to accommodate such requests. We will now explain why.

Currently MOSEK is available for the following platforms
  • Linux 32 and 64 bit on Intel X86.
  • MAC OSX  64 bit on Intel X86.
  • Windows 32 and 64 bit on Intel X86.
These are well support mainstream platforms with plenty of tools such as a good C tool chain and Python support.

In general to port MOSEK to a new platform then the platform
  • should preferably be a Linux like operating system.
  • support double precision floating point computations.
  • should have a mature C compiler tool chain with all the usual libraries 
  • dynamic memory allocation should be available.
  • provide a good optimized sequential BLAS/LAPACK library if performance is important. This is particularly important if support for semidefnite optimization is required.
In practice if it is not possible to cross compile MOSEK for the platform under Linux or Windows then we require:
  • Python 2.7 should be available so we can run our Scons based build system.
  • Perforce, our source control system, should be supported on the platform
  • Some other tools that we currently have forgotten about.
Note most of our customers of course expect us to test and support our software for long time. If that is the case we should be able to hook the platform into the Jenkins continuous integration system, so we can build and test automatically regularly. If that is not possible, then the cost of supporting the platform increases.

MOSEK is a complex piece of software i.e. it is not just a few 1000s lines of code that can be compiled with a make script. This implies that porting it to a new platform usually requires at least 1 months of work from a senior developer and in many cases more.  In particular if the platform is far from the standard Linux 64 bit x86 platform, then a port is cumbersome and time consuming.

To summarize we can without doubt adapt MOSEK to run on almost any platform. However, porting MOSEK to a new platform is a costly undertaking. Therefore, if you want us to port MOSEK to a new platform then you to present a decent business case that shows we will recover our costs with a reasonable probability.

As a postscript let us tell you about our experience with QNX which we ported MOSEK to recently. QNX is a real time OS that looks pretty much like Linux. You can get QNX to run as a virtual machine under Windows (it seems under Windows only). In theory a port should be easy. However, the keyboard and mouse support is less than optimal, not to say lousy. It is actually very hard to get the network connection working so moving files to and from the virtual machine is a pain. After quite a lot of  hassle we got a QNX build cross compiled on Linux and verified that it worked under QNX and we gave it to a potential customer. The potential customer said he did not have time to test it yet unfortunately.



Monday, March 30, 2015

Easter Holidays

MOSEK team will be on vacation during the Easter period!



Support and sales will be closed from Thursday the 2nd of April 2015 to Monday the 6th of April 2015, both included.

Normal service will be restored from Tuesday the 7th of April 2015.



We wish an happy Easter to all of you!