Wednesday, August 28, 2024

Autumn is coming!

 Currently we are experiencing some lovely summer weather here in Copenhagen, but there is a feeling that the autumn is right around the corner. For MOSEK the arrival of autumn means the arrival of thousands of new persons eligible to use MOSEK for free.

This is because MOSEK, through our academic initiative, grants free licenses for research or educational purposes at degree-granting academic institutions.

Whether you are a new student or a seasoned academic why not use this opportunity to try MOSEK!

Friday, July 19, 2024

MOSEK is a proud sponsor ISMP 2024

Next week the 25th International Symposium on Mathematical Programming will take place in Montreal. MOSEK is a proud sponsor of this conference. We will also have a presence at the conference. 

If you have inquiries about MOSEK that you want to address in person, your best bet is to look out for our CEO Erling D. Andersen at the conference.

If your happy with having your inquiry answered through email you can always reach out to support@mosek.com.  


Tuesday, June 25, 2024

Mosek is proud to sponsor EUROPT 2024.

This week starting on Wednesday June 26 EUROPT 2024 will be held at Lund university, hosted by the Department of Automatic Control.  

Moseks industrial phd student Utkarsh, along with his academic supervisor Martin S. Andersen, will be hosting a track on developments on the interior point method.

So if you are attending the conference and want to know more about Mosek, and maybe get your hands on a hard copy of our  Modelling Cookbook, keep on eye out for Utkarsh!

If you're not attending the conference you can always find our cookbook online and reach us at support@mosek.com or sales@mosek.com if you have any inquires.


Thursday, June 13, 2024

Mosek support for Windows on an ARM CPU

Until recently mainly Intel and AMD CPUs were employed in mainstream laptop and server computers. However, recently ARM based CPU has gained popularity, especially in the Apple world. Since there is a Windows version for ARM then a natural question is: when Mosek will support Windows on ARM?

Ultimately, Mosek is likely to be available for Windows on ARM. However, at least the following 3 conditions must be satisfied for that to happen:  
  1. Appropriate hardware must be available, e.g. we must be able to buy ARM based servers from DELL.
  2. The whole software ecosystem must be sufficiently mature, e.g. all the tools we require to build Mosek must be available.
  3. Some external software libraries such as an appropriate BLAS library must be available.
Based on historical experience it is unlikely that Mosek will be available for Windows on ARM  within the next 12 months. However, feel free to contact Mosek support if you would like to use Mosek on Windows ARM in the near future.

Note Mosek is available for Linux run on an ARM CPU.

Wednesday, June 5, 2024

The dangers of large bounds

Let's say we have a well scaled optimization problem with a very good and robust primal-dual optimal solution, which solves without any numerical difficulties. It could be a linear problem in standard form $$\begin{equation}\begin{array}{ll}\textrm{minimize}&c^Tx\\ \textrm{subject to}& Ax\leq b,\end{array}\end{equation}$$ where the primal solution $x$ and dual solution $y$ are of reasonable magnitude and satisfy $Ax\leq b$, $y\geq 0$, $A^Ty+c=0$, $b^Ty=c^Tx$ with the best achievable precision. In other words, everything is as nice as it could be.

Obviously (right?) nothing should change if we extend the problem with huge bounds on $x$, so large that they are completely redundant for the given problem: $$\begin{equation}\begin{array}{ll}\textrm{minimize}&c^Tx\\ \textrm{subject to}& Ax\leq b,\\ & x\leq M.\end{array}\end{equation}$$ 

To see what might go wrong let us first understand what the solver might think about problems whose feasible set lies very far out. The simplest example might be $$\begin{equation}\begin{array}{ll}\textrm{minimize}&x\\ \textrm{subject to}& x=10^{12}.\end{array}\end{equation}$$ with the optimal solution $x=10^{12}$. But is that problem feasible from a practical perspective? If we work in the realm of practical applications with solutions of reasonable magnitude, then one might argue that this simple problem is for all intents and purposes infeasible, since the first feasible point lives further than we care to look. This can be made precise using Farkas lemma: the infeasibility certificate for this problem would be a value $y$ such that $y\leq 0$ and $10^{12}y=1$. A very good practical example of such a $y$ is $y=10^{-12}$ - it violates the conditions by only $10^{-12}$, failing to satisfy $y\leq 0$ by this narrow margin. This was just a toy example, but it easy to imagine that for a nontrivial optimization problem the solver might converge either to a solution or to such an infeasibility certificate, both of great quality! That makes problems with large solutions potentially hard to numerically distinguish from infeasible.

The same logic can now be applied to the problem (2) with redundant large bounds. The infeasibility certificate for it will be a pair of vectors $y,\tilde{y}$ such that $$A^Ty+\tilde{y}=0,\quad b^Ty+M\cdot \mathbb{1}^T\tilde{y}=-1,\quad y\geq 0,\quad \tilde{y}\geq 0.$$ If we let $y$ be the dual solution to the original problem (1) then by choosing a very small negative $\tilde{y}$ (in the order of $M^{-1}$) we can easily satisfy the second condition in (4), while the first and fourth one will only be violated by a tiny amount (of order $\tilde{y}$). As counterintuitive as it might be the math works out and we get certificate of primal infeasibility perfectly acceptable in finite precision arithmetic, with only tiny violations.

The rule of thumb one can remember connecting examples (2) and (3) is the following: the bound $x\leq M$ can be written in equality form as $x+\tilde{x}=M,\ \tilde{x}\geq 0$, so even with reasonable values of $x$ we get that the value of $\tilde{x}$ in any solution must be huge, putting us in position of example (3).

Similar considerations apply to distinguishing primal and dual infeasibility from feasibility in the case of large coefficients in the objective and other scaling problems; this applies for instance to big-M models in integer optimization, large penalties etc.

Will this come up in practice? Yes. Perhaps not for simple linear problems and with the extensive presolve MOSEK has, but it is not hard to set up a relatively straightforward conic problem, solve it, add huge bounds, turn presolve off and see MOSEK return a high quality infeasibility certificate. We leave these experiments to the reader.

Wednesday, May 22, 2024

Mosek 10.2 and floating licenses

MOSEK 10.2 ships with the licensing software (FlexLM) upgraded to version 11.19.6. This has two implications.

  • On Linux, the new floating license server drops the long-lasting dependency on the LSB (Linux Standard Base) package. In particular, it can be installed on Linux distributions without LSB, primarily RHEL9 and Debian.
  • All floating license users who want to upgrade the clients to Mosek 10.2 must also upgrade the token server to one from Mosek 10.2, as the new clients will not talk to older token servers. As always, an upgrade of the token server does not affect older Mosek clients which will continue to work. See the licensing manual for more info.

Have a look at the installation manual for the token server and the release notes for MOSEK 10.2.

MOSEK 10.2 and Pythonic Fusion API

MOSEK 10.2 introduces a feature that we hope will be interesting for all users of our Python Fusion API, which we call Pythonic Fusion

Pythonic Fusion is an overlay on top of the current Fusion API (or, as some would call it, syntactic sugar) which implements standard Python operators for Fusion objects (variables, parameters, expressions). There are operators for manipulating linear expressions:

+, -, *, @, [:], .T

relational operators for introducing constraints:

==, <=, >=

and operators for introducing AND- and OR-clauses in disjunctive constraints:

&, |

The operators are used in the most natural way familiar from NumPy, CVXPY, Pandas or any other data processing tool in Python, so we restrict to giving a simple example. The following Python Fusion constraint

M.constraint(Expr.mul(G, Expr.sub(x.transpose(), y.slice(0, n))),                          Domain.lessThan(c))

will be written in Pythonic Fusion as

M.constraint(G @ (x.T - y[:n]) <= c)

A more comprehensive introduction to the new syntax can be found in the manual. Examples using Pythonic Fusion are scattered throughout the manual, in particular in the portfolio optimization case study, and with time we will adapt our other Python Fusion resources to the new syntax. You are welcome to share your suggestions, comments or bug reports with us.

Important. In MOSEK 10.2 Pythonic Fusion is a separate add-on, available only after importing:

import mosek.fusion.pythonic