This upgrade breaks client-server compatibility. That means that if you installed a MOSEK 9.1.5+ client, you are using a floating license, and you are getting an error such as

Version of vendor daemon is too old

See also The licensing FAQ.

In version 9.1.5 we upgraded the FlexLM license manager to from version 11.14 to 11.16 because of a potential security issue reported by a user.

This upgrade breaks client-server compatibility. That means that if you installed a MOSEK 9.1.5+ client, you are using a floating license, and you are getting an error such as

then you should upgrade the license server to one that also comes from a 9.1.5+ distribution of MOSEK. It will be able to serve the new and all older client versions.

This upgrade breaks client-server compatibility. That means that if you installed a MOSEK 9.1.5+ client, you are using a floating license, and you are getting an error such as

Version of vendor daemon is too old

See also The licensing FAQ.

Today we released MOSEK 9.1, which is a direct continuation of version 9.0 with no changes to the optimizer or the existing API.

It introduces one new feature: the possibility to use the remote OptServer from Fusion via Model.solve(server, port).

We take this opportunity to announce that the following will be dropped in the next major release:

*MOSEK Team*

It introduces one new feature: the possibility to use the remote OptServer from Fusion via Model.solve(server, port).

We take this opportunity to announce that the following will be dropped in the next major release:

- support for Python 2.7 on all platforms,
- support for Java on Windows 32bit,
- support for all versions of Python on Windows 32bit.

Due to falling interest in our distribution for Windows 32bit platform and the fact that more and more software vendors are dropping it, we also plan to drop the Windows 32bit package in one of the minor or major releases in near future.

We will most likely continue to provide a minimal package consisting of the low-level C API and shared libraries.

If you rely on MOSEK for 32bit Windows please let us know at**support@mosek.com** so that we can best accommodate your needs.

Of course nothing changes on 64bit Windows.

MOSEK Team.

We will most likely continue to provide a minimal package consisting of the low-level C API and shared libraries.

If you rely on MOSEK for 32bit Windows please let us know at

Of course nothing changes on 64bit Windows.

MOSEK Team.

Joachim Dahl speaks at ICCOPT 2019 in Berlin:

**Title: **A primal-dual algorithm for exponential-cone optimization

**Session: **Advances in Algorithms for Conic Optimization

**Abstract: **We discuss a primal-dual algorithm for exponential-cone optimization. The algorithm is based on primal-dual scaling proposed by Tuncel, with similar properties as Nesterov-Todd scalings for symmetric cones. We also discuss a new corrector for nonsymmetric cones, which considerably reduces the number of iterations required to solve a number of test problems. This algorithm has recently been developed for version 9 of the MOSEK software.

**Time: **Thursday 08/08/2019, 10:45, room H2032

The logarithmic mean temperature difference

$$LMTD(x,y) = \frac{x-y}{\ln(x/y)}$$

can be used to model heat exchange, e.g., when optimizing the reuse of excess process heat onsite at industrial facilities. In the heat exchanger network synthesis problem due to Yee and Grossmann (link goes to a recent paper by Mistry and Misener), we find that its reciprocal raised to some power, that is

$$RecLMTD^\beta(x,y) = \left(\frac{\ln(x/y)}{x-y}\right)^\beta,$$

can be extracted as a separately contributing term in the objective function. Capitalizing on the convexity of this term on $(x,y) \in \mathbb{R}_+^2$, for all considered $\beta \geq 0$, this leads to better performance when solving the otherwise nonconvex problem as argued in the paper.

A challenge to find the conic reformulation of this function was posed under the Oberwolfach Workshop on Mixed-Integer Nonlinear Optimization (2019) and we accepted. Of course, this is trivial if no restrictions are put on the set of cones as one may just define

$$\mathcal{K} = \mathrm{cl}\{(t,s,x,y) \in \mathbb{R}_{++}^4 : t \geq s \cdot RecLMTD^\beta(x/s, y/s) \}$$

and call it a day. This cone is nonempty, closed and convex and hence obeys $K = (K^{*})^{*}$ as well as all the usual properties of conic duality. Computationally, however, the cone is not particularly desirable and we can do better with a bit of reformulation:

$$\begin{array}{lll} t \geq \left(\frac{\ln(x/y)}{x-y}\right)^\beta,\\t \geq \left(\frac{\ln(u/y + 1)}{u}\right)^\beta,& u = x-y,\\ y \geq \frac{u}{\exp(ut^{1/\beta})-1},& u = x-y,\\ y \geq \frac{u}{\exp(u/s)-1},& u = x-y, & s \geq t^{-1/\beta},\\ \end{array}$$

where I substitute in the first step, rewrite assuming either $u > 0$ or $u <0$ (both leads to the same) in the second, and extract a power cone representable subexpression in the third. This means that the representation problem of $RecLMTD^\beta$ have been reduced to the representation problem of

$$\mathcal{K} = \mathrm{cl}\left\{(t,s,x) \in \mathbb{R}_{+}^2 \times \mathbb{R}_{++} : t \geq \frac{x}{\exp(x/s)-1} \right\},$$

which, just like the quadratic, power and exponential cones, is defined as the epigraph of the perspective of a univarite convex function; in this case $\frac{x}{\exp(x)-1}$. Whether this cone can be written in terms of the others, or has potential for computationally efficient implementations itself, remains open. We invite anyone interested in barrier functions and interior-point algorithms to take a crack at it.

**What is possible right now?**

The logarithmic mean is bounded from above and below by, respectively, the arithmetic and the geometric mean, both of which are representable in MOSEK. There is also Chen's approximation which corresponds to a power cone. Finally it can be observed that $\log(\exp(-x)+1)$ is a fairly good underestimator of $\frac{x}{\exp(x)-1}$. This means that the set described by the inequality from above,

$$y \geq \frac{u}{\exp(u/s)-1},$$

can be outer approximated by

$$y \geq s \log(\exp(-u/s)+1),$$

which is representable in MOSEK as the homogenization of the softplus function. Beware that the usefulness of any of these alternatives is unknown to the author.

The logarithmic mean is bounded from above and below by, respectively, the arithmetic and the geometric mean, both of which are representable in MOSEK. There is also Chen's approximation which corresponds to a power cone. Finally it can be observed that $\log(\exp(-x)+1)$ is a fairly good underestimator of $\frac{x}{\exp(x)-1}$. This means that the set described by the inequality from above,

$$y \geq \frac{u}{\exp(u/s)-1},$$

can be outer approximated by

$$y \geq s \log(\exp(-u/s)+1),$$

which is representable in MOSEK as the homogenization of the softplus function. Beware that the usefulness of any of these alternatives is unknown to the author.

Here is feedback on power cones in Mosek 9 we received (published with permission of the user, anonymous for the purpose of this post).

Back to the power cones: we were excited about this feature because it allows us to implement market impact constraints with exponents that are arbitrary greater than one.

We benchmarked a simple portfolio optimization problem. The goal was to maximize an expected return on a 10 000 instrument portfolio under a market impact constraint. We chose this particular problem because it contains ten thousand power cones in order to implement the exponent part of the market impact constraint.

With Mosek 8.1 we were limited to powers 1, 3/2, 5/3 and 2 because other powers would have taken a gigantic effort to implement. With Mosek 9 all the powers above one are now easily available. As can be seen in the following timings (in seconds), in our case, the power cones are roughly as fast as the implementation using multiple rotated quadratic cones. This is great news as we were expecting a 10x degradation. Some oddities though: power 5/3 seems to be slower in Mosek 9 than in Mosek 8.1 and power 2 seemed faster in power cones than in rotated cones.

Back to the power cones: we were excited about this feature because it allows us to implement market impact constraints with exponents that are arbitrary greater than one.

We benchmarked a simple portfolio optimization problem. The goal was to maximize an expected return on a 10 000 instrument portfolio under a market impact constraint. We chose this particular problem because it contains ten thousand power cones in order to implement the exponent part of the market impact constraint.

With Mosek 8.1 we were limited to powers 1, 3/2, 5/3 and 2 because other powers would have taken a gigantic effort to implement. With Mosek 9 all the powers above one are now easily available. As can be seen in the following timings (in seconds), in our case, the power cones are roughly as fast as the implementation using multiple rotated quadratic cones. This is great news as we were expecting a 10x degradation. Some oddities though: power 5/3 seems to be slower in Mosek 9 than in Mosek 8.1 and power 2 seemed faster in power cones than in rotated cones.

Version | Mosek 8.1 | Mosek 9.0 | Mosek 9.0 | |

Implementation | Rotated Cones | Rotated Cones | Power Cones | |

Exponent | 3/2 | 2.41 | 2.37 | 5.23 |

5/3 | 7.84 | 11.53 | 6.93 | |

2 | 2.95 | 2.93 | 2.65 | |

3.14 | N/A | N/A | 10.87 |

In conclusion, we are really happy with Mosek 9. The power cones are going to replace all the rotated cone shenanigans we previously had, they are as fast and a lot more powerful/simpler to use.

Subscribe to:
Posts
(
Atom
)