tag:blogger.com,1999:blog-76666141096746995842022-01-20T13:40:28.011+01:00The MOSEK blogThis blog is about MOSEK.MOSEKhttp://www.blogger.com/profile/16182492737219707955noreply@blogger.comBlogger171125tag:blogger.com,1999:blog-7666614109674699584.post-1439935716002414982022-01-20T13:39:00.001+01:002022-01-20T13:39:28.444+01:00MIP 2022<p><span style="background-color: white; font-family: "Trebuchet MS", Trebuchet, Verdana, sans-serif; font-size: 15.4px;">Similarly to previous years MOSEK is proud to be one of the sponsors of MIP2022 - </span><i style="background-color: white; font-family: "Trebuchet MS", Trebuchet, Verdana, sans-serif; font-size: 15.4px;">Mixed Integer Programming Workshop 2022</i><span style="background-color: white; font-family: "Trebuchet MS", Trebuchet, Verdana, sans-serif; font-size: 15.4px;">, taking place </span><span style="background-color: white; font-family: "Trebuchet MS", Trebuchet, Verdana, sans-serif; font-size: 15.4px;">May 23–26, 2022 at </span><a href="https://www.google.com/url?q=http://dimacs.rutgers.edu/&sa=D&sntz=1&usg=AFQjCNE9ubuZiEwpUuQCcSQ8C-G0kRw5nw" style="background-color: white; color: #ff8832; font-family: "Trebuchet MS", Trebuchet, Verdana, sans-serif; font-size: 15.4px; text-decoration-line: none;">DIMACS</a><span style="background-color: white; font-family: "Trebuchet MS", Trebuchet, Verdana, sans-serif; font-size: 15.4px;">, Rutgers University.</span></p><p><span style="background-color: white; font-family: "Trebuchet MS", Trebuchet, Verdana, sans-serif; font-size: 15.4px;">More details at </span><span style="font-family: Trebuchet MS, Trebuchet, Verdana, sans-serif;"><span style="font-size: 15.4px;"><a href="https://www.mixedinteger.org/2022/">https://www.mixedinteger.org/2022/</a></span></span></p>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-73562305677348400372022-01-10T12:43:00.005+01:002022-01-10T12:43:55.503+01:00Planned end of support for version 8On <b>31-may-2022</b> we will be stopping active support for version 8 which was released back in 2016.<br /><br />For details of release and support policy see <a href="https://www.mosek.com/products/release-policy/">https://www.mosek.com/products/release-policy/</a>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-91615216957499860532021-12-14T11:26:00.001+01:002021-12-14T11:26:33.979+01:00Log4j statement<p>Neither MOSEK nor any of the tools shipped with the MOSEK package make use of Log4j. The MOSEK library is not vulnerable to the Log4j exploit.</p>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-20238057468929959642021-11-08T12:15:00.000+01:002021-11-08T12:15:35.808+01:00Some animals are more equal than others: least-squares vs Euclidean norm<p>A user recently reached out to MOSEK support because the solver returned an <i>UNKNOWN </i>problem/solution status on their (constrained) <a href="https://www.cvxpy.org/examples/basic/least_squares.html">Least-squares problem, that was implemented in CVXPY</a> . The solver log looked as shown in the first MOSEK log shown below.</p> <p>The solution we offered was to minimize the Euclidean norm instead of the sum-of-squares. Theoretically, both models are equivalent; their optimal points are the same. But as a great man once said: in theory, theory and practice are the same. In practice, well... Take a look at the MOSEK log for the problem that minimizes the Euclidean norm (second MOSEK log)</p> <script src="https://gist.github.com/Utkarsh-Detha/3f32d39ec0aa9c38a62f61ab80ac83e3.js"></script> <p>Note the following differences between the two MOSEK logs:</p><p></p><ul style="text-align: left;"><li>The problem status in the norm problem is primal and dual feasible and the solution status is optimal, in contrast to the least-squares problem.</li><li>The infinity-norm of the solutions in the norm problem are smaller by nearly 5 orders of magnitude compared to the solution of the least-squares problem. This is usually a desirable trait, as explained in the <a href="https://docs.mosek.com/latest/pythonfusion/debugging-log.html#continuous-problem">debugging section of MOSEK docs</a> </li><li>The number of iterations taken by the norm problem is far fewer.</li><li>The objective value of the norm problem is essentially the square root of the least-squares problem (the least-squares problem was not solved to optimality, hence the discrepancy) </li></ul><div> Observe that the solution is only guaranteed to be unique if the objective is strictly convex. The objective function is strictly convex if and only if the A matrix (following <a href="https://www.cvxpy.org/examples/basic/least_squares.html">this</a> notation) is of full column-rank. If this is not the case, then the two problems might output different optimal solution vectors (as is the case above), but as Orwell would put it, one of those solutions will be <i>more equal than the other</i>. </div><p></p> <p>So, at least for CVXPY-MOSEK users (and MOSEK Fusion users!), we recommend the Euclidean norm in place of the sum-of-squares, wherever possible.</p>Utkarsh Dethahttp://www.blogger.com/profile/15963053758247799356noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-37662409990338631122021-09-14T00:13:00.007+02:002021-10-12T15:24:51.667+02:00Portfolio Optimization Workshop and Cookbook<p>We are pleased to announce the <b>MOSEK Portfolio Optimization Workshop, </b>a one-day event on the theoretical and practical aspects of portfolio optimization using MOSEK. The workshop takes place at <b>our location in Copenhagen</b> (this is NOT a virtual event(!)) on Thursday, <b>November 18th, 2021.</b> Topics include:<br /></p><ul style="text-align: left;"><li>An introduction to portfolio optimization using MOSEK</li><li>Advanced topics in portfolio optimization</li><li>Tracking error and portfolio construction</li><li>MOSEK licensing, developments and news.</li></ul>There will also be ample time for discussions. We provide lunch for the participants. For the full program with abstracts see the poster:<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://docs.mosek.com/slides/2021/portfolio/poster.pdf" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1056" data-original-width="816" height="151" src="https://1.bp.blogspot.com/-aGTbIVujU9I/YT-_azVsfjI/AAAAAAAABBs/w3EYQt_1wWsYpO6gFxD_xC_WNyE_fLBpQCLcBGAsYHQ/w117-h151/posterthumbnail.jpg" width="117" /></a></div><div><br /></div>Participation is free and open to all but we would like you to register via <a href="https://forms.gle/QDFh2mtoocYmfjpN6" target="_blank">this form</a> in order to keep track of numbers.<div><br /><p>Announcing the workshop is also an opportunity to present the first version of the <b><a href="https://docs.mosek.com/portfolio-cookbook/index.html" target="_blank">MOSEK Portfolio Optimization Coookbook</a>,</b> which provides an introduction to the topic of portfolio optimization and discusses several branches of practical interest from this broad subject illustrated with examples using the MOSEK Fusion API. For more information about this topic, including links to the cookbook and accompanying Python notebooks visit our comprehensive <a href="https://www.mosek.com/resources/portfolio-optimization/" target="_blank">Portfolio Optimization Resource Page</a>.</p></div>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-25602916707830321492021-08-06T15:06:00.000+02:002021-08-06T15:06:19.066+02:00MOSEK 9.3 is released<p><span style="background-color: white; font-family: "Trebuchet MS", Trebuchet, Verdana, sans-serif; font-size: 15.4px;">We have released MOSEK 9.3. </span><span style="background-color: white; font-family: "Trebuchet MS", Trebuchet, Verdana, sans-serif; font-size: 15.4px;">Release notes:</span></p><div class="post-body entry-content" id="post-body-6131202209308632771" itemprop="description articleBody" style="background-color: white; font-family: "Trebuchet MS", Trebuchet, Verdana, sans-serif; font-size: 15.4px; line-height: 1.4; position: relative; width: 712px;"><p style="text-align: center;"><a href="https://docs.mosek.com/9.3/releasenotes/index.html" style="color: #ff8832; text-decoration-line: none;">https://docs.mosek.com/9.3/releasenotes/index.html</a></p><p>This version is a direct continuation of 9.2 with no changes to existing interfaces. The new features are:</p><p></p><ul style="line-height: 1.4; margin: 0.5em 0px; padding: 0px 2.5em;"><li style="margin: 0px 0px 0.25em; padding: 0px;"><b>support for Linux on ARM64 (aarch64), </b>including Optimizer API and Fusion API for C/C++,Java,Python,.NET.<b> </b>The interior-point and conic optimizers are single-threaded on that platform.</li><li style="margin: 0px 0px 0.25em; padding: 0px;">Updated FLEXlm to version 11.18. In particular, floating license users who upgrade clients to MOSEK 9.3 <b>must</b> also upgrade license server binaries (lmgrd) to the ones from the 9.3 MOSEK distribution for compatibility. The new license server is as always backwards compatible.</li><li style="margin: 0px 0px 0.25em; padding: 0px;">Improved performance when solving many tasks in parallel.</li></ul><p></p><div style="clear: both;"></div></div><div class="post-footer" style="background-color: #eeeeee; border-bottom: 1px solid rgb(238, 238, 238); color: #666666; font-family: "Trebuchet MS", Trebuchet, Verdana, sans-serif; font-size: 12.6px; line-height: 1.6; margin: 20px -2px 0px; padding: 5px 10px;"></div>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-61312022093086327712021-06-23T09:55:00.000+02:002021-06-23T09:55:15.348+02:00MOSEK 9.3 beta, support for linuxaarch64<p>We have released a beta version of MOSEK 9.3. It is currently only available for download from our website</p><p style="text-align: center;"><a href="https://www.mosek.com/downloads/9.3.0/">https://www.mosek.com/downloads/9.3.0/</a></p><p style="text-align: left;">Release notes:</p><p style="text-align: center;"><a href="https://docs.mosek.com/9.3/releasenotes/index.html">https://docs.mosek.com/9.3/releasenotes/index.html</a></p><p>This version is a direct continuation of 9.2 with no changes to existing interfaces. The new features are:</p><p></p><ul><li><b>support for Linux on ARM64 (aarch64), </b>including Optimizer API and Fusion API for C/C++,Java,Python,.NET.<b> </b>The interior-point and conic optimizers are single-threaded on that platform.</li><li>Updated FLEXlm to version 11.18. In particular, floating license users who upgrade clients to MOSEK 9.3 <b>must</b> also upgrade license server binaries (lmgrd) to the ones from the 9.3 MOSEK distribution for compatibility. The new license server is as always backwards compatible.</li><li>Improved performance when solving many tasks in parallel.</li></ul><p></p>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-36852239152220018682021-06-04T10:32:00.004+02:002021-06-04T10:32:55.809+02:00Price increase from October 2021<p>In February 2020 we announced a price increase, which was later postponed due to the COVID-19 events.</p><p>This price increase will now come into effect from <b>October 1st, 2021</b>. </p><p>Prices go up 5.4% on average: the basic PTS and PTON floating license prices increase by 100 USD each, and the remaining values are adjusted appropriately, following our common rule that a server license is worth 4 times the floating license and that annual maintenance for each part is 25% of the base price for the part. </p><p>New prices can be found at the top of</p><p style="text-align: center;"><a href="https://www.mosek.com/sales/commercial-pricing/">https://www.mosek.com/sales/commercial-pricing</a></p><p>The current prices remained unchanged since 2015.</p>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-40323364000213921982021-04-20T13:01:00.002+02:002021-04-20T13:03:53.340+02:00Data-driven distributionally robust optimization with MOSEK<p>We posted a <a href="https://www.youtube.com/watch?v=fF0pxZ3qzWo" target="_blank">video</a> where our very own Utkarsh Detha accompanied by the authors of the award-winning paper <span face="Roboto, Arial, sans-serif" style="background-color: #f9f9f9; color: #030303; font-size: 14px; white-space: pre-wrap;"> "</span><i style="color: #030303; font-family: Roboto, Arial, sans-serif; font-size: 14px; white-space: pre-wrap;">Data-driven distributionally robust optimization using the Wasserstein metric: performance guarantees and tractable reformulations</i><span face="Roboto, Arial, sans-serif" style="background-color: #f9f9f9; color: #030303; font-size: 14px; white-space: pre-wrap;">", </span>Assistant Prof. <a href="http://www.dcsc.tudelft.nl/~mohajerin/" target="_blank">Peyman Mohajerin Esfahani</a> and Prof. <a href="https://people.epfl.ch/daniel.kuhn" target="_blank">Daniel Kuhn</a>, discuss the work presented in that paper.</p><p>We also show how to quickly and easily implement such an approach using our Fusion API for Python. This video focuses on the key new feature: parameters in Fusion. <a href="https://docs.mosek.com/9.2/pythonfusion/tutorial-parametrization.html" target="_blank">Parametric Fusion</a> allows MOSEK to rapidly resolve a model, and combined with the warm-start capability of the Simplex optimizer, it becomes a powerful tool in every optimizer's garage.</p>See: <a href="https://www.youtube.com/watch?v=fF0pxZ3qzWo">the video</a>, <a href="https://nbviewer.jupyter.org/github/MOSEK/Tutorials/blob/master/dist-robust-portfolio/Data-driven_distributionally_robust_portfolio.ipynb">our notebook on the same topic</a>, <a href="https://link.springer.com/epdf/10.1007/s10107-017-1172-1">the research paper</a>.<br /><br /><div><br /> </div>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-15645234001533409512020-12-14T23:04:00.002+01:002020-12-14T23:06:29.377+01:00MOSEK in the browser and OptServer<p>Although both <a href="https://docs.mosek.com/latest/install/installation.html" target="_blank">installing MOSEK</a> and obtaining a <a href="https://www.mosek.com/try/" target="_blank">trial license</a> are very easy, it is now possible to get to know MOSEK directly in the browser <i>with one click and no setup at all.</i></p><h1 style="text-align: left;">Python</h1><div>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.</div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://colab.research.google.com/github/MOSEK/Tutorials/blob/master/online/trymosek.ipynb" style="margin-left: 1em; margin-right: 1em;" target="_blank"><img border="0" data-original-height="593" data-original-width="657" height="172" src="https://1.bp.blogspot.com/-8Zikhlz7LwM/X9fVXhVkfFI/AAAAAAAAAx0/UgeC-QTkeksqaC8pclsYYujkS37ZKAWRwCLcBGAsYHQ/w190-h172/Screenshot%2Bfrom%2B2020-12-14%2B22-12-16.png" width="190" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="https://colab.research.google.com/github/MOSEK/Tutorials/blob/master/online/trymosek.ipynb" target="_blank">Open in Colab</a></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">(You can also just <a href="https://github.com/MOSEK/Tutorials/blob/master/online/trymosek.ipynb" target="_blank">download the notebook</a> 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.</div><div class="separator" style="clear: both; text-align: left;"><br /></div><h1 style="clear: both; text-align: left;">Javascript Fusion</h1><div>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.</div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://solve.mosek.com/fusion.html" style="margin-left: 1em; margin-right: 1em;" target="_blank"><img border="0" data-original-height="370" data-original-width="576" height="138" src="https://1.bp.blogspot.com/-oKHQyf9oIXA/X9fYt-KwKoI/AAAAAAAAAyA/j1Gcp52cZjkqmKEHZeNrbzjEgGByUJS2ACLcBGAsYHQ/w215-h138/logo.png" width="215" /></a></div><div style="text-align: center;"><a href="https://solve.mosek.com/fusion.html">https://solve.mosek.com/fusion.html</a></div><div style="text-align: left;"><br /></div><div style="text-align: left;">An almost complete Fusion API is mapped through and you can run a number of ready examples.</div><div style="text-align: left;"><br /></div><h1 style="text-align: left;">How does it work?</h1><div>The key to the simplicity lies in the fact that the actual optimizations are performed on our freely available demo Optimization Server (<a href="https://docs.mosek.com/latest/opt-server/overview.html" target="_blank">OptServer</a>) running at <a href="https://solve.mosek.com">https://solve.mosek.com</a>. On that page you can also <a href="https://solve.mosek.com/static/pub/howto.html" target="_blank">find instructions</a> 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.</div><div><br /></div><div>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 <a href="https://github.com/MOSEK/Dockerfiles/tree/master/optserver-demo" target="_blank">docker container</a> and use that to optimize.</div>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-16597215662819709832020-11-16T13:49:00.003+01:002020-11-16T13:49:49.634+01:00Apple Silicon M1 plans<p>In response to the recent questions about MOSEK support for the new Apple Silicon M1 ARM64 architecture:</p><p>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.</p><p>Please contact us if you have questions or plans related to MOSEK on the new Mac.</p><p><i>The MOSEK team</i></p>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-28213942373927000672020-10-19T10:59:00.000+02:002020-10-19T10:59:34.100+02:00Fusion and the art of harvesting potatoes<p>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...</p><p>... 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:</p><div class="separator" style="clear: both; text-align: center;"><div style="text-align: center;"><a href="https://upload.wikimedia.org/wikipedia/commons/b/b6/Slitherlink-example.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="290" data-original-width="290" height="200" src="https://upload.wikimedia.org/wikipedia/commons/b/b6/Slitherlink-example.png" width="200" /></a><a href="https://upload.wikimedia.org/wikipedia/commons/8/88/Slitherlink-answer.png" style="margin-left: 1em; margin-right: 1em; text-align: right;"><img border="0" data-original-height="290" data-original-width="290" height="200" src="https://upload.wikimedia.org/wikipedia/commons/8/88/Slitherlink-answer.png" width="200" /></a></div></div><p>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:</p><p></p><ul style="text-align: left;"><li>(1) every vertex of the grid meets either 0 or 2 of the tour edges,</li><li>(2) every square with $i$ potatoes has exactly $i$ tour edges on its boundary.</li></ul><div>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 <a href="https://docs.mosek.com/9.2/pythonfusion/case-studies-tsp.html#doc-fusion-case-studies-tsp" target="_blank">used for TSP</a> 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 <a href="https://docs.mosek.com/9.2/pythonfusion/modeling.html#stacking-and-views" target="_blank">stacking and slicing</a> and that she can see it all and try it out live here:</div><div><br /></div><div style="text-align: center;"><b><a href="https://solve.mosek.com/fusion.html?ex=slitherlink" target="_blank">https://solve.mosek.com/fusion.html?ex=slitherlink</a></b></div><div style="text-align: left;"><br /></div><div style="text-align: left;">Finally, as much as Lærke is just our imaginary MIP user in the food industry, the puzzle actually exists and is known as <a href="https://en.wikipedia.org/wiki/Slitherlink" target="_blank">Slitherlink</a>.</div><div style="text-align: left;"><br /></div>Bon appétit!<p></p><p>(images by GLmathgrant, under <a href="http://creativecommons.org/licenses/by-sa/3.0/" target="_blank">CC BY-SA 3.0</a>, from Wikipedia)</p>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-7207044164186555292020-10-09T14:34:00.001+02:002020-10-09T14:35:11.140+02:00CVXPY 1.1.6<p>The latest release 1.1.6 of <a href="https://cvxpy.org" target="_blank">CVXPY</a> 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.</p><p>Here is roughly what you should expect. If you are modeling:</p><p></p><ul style="text-align: left;"><li>a mixed-integer problem: no change.</li><li>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).</li><li><b>all other linear and conic problems: </b>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 <a href="https://docs.mosek.com/latest/faq/faq.html#cvxpy" target="_blank">force the solver to dualize</a>.<br /><br />If you were already tuning some MOSEK parameters then you should reevaluate the settings. In case you were already forcing primal/dual form with <span style="font-family: courier;">iparam.intpnt_solve_form</span> then most likely you should change to the opposite.<br /><br />Finally, if you are studying the solver log output, keep in mind that it is operating with the dual of your CVXPY formulation (<span style="font-family: courier;">DUAL_INFEASIBLE</span> means your problem is primal infeasible, minimization becomes maximization etc.). </li></ul><p></p><p>See also <a href="https://www.cvxpy.org/tutorial/advanced/index.html#solveropts" target="_blank">a note in CVXPY docs</a>.</p>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-49915213125549733152020-10-05T23:51:00.000+02:002020-10-05T23:51:16.535+02:00Sharpe ratio - derivation and Fusion model<p>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 <a href="https://docs.mosek.com/modeling-cookbook/cqo.html#convex-quadratic-sets" target="_blank">here</a> or <a href="https://docs.mosek.com/modeling-cookbook/qcqo.html#example-factor-model" target="_blank">here</a>). 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.</p><p>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$).</p><p>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$.</p><p>A sample Fusion implementation can be found here:</p><p style="text-align: center;"><a href="https://solve.mosek.com/fusion.html?ex=sharpe">https://solve.mosek.com/fusion.html?ex=sharpe</a></p>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-46780732663104280642020-09-21T09:34:00.000+02:002020-09-21T09:34:00.630+02:00Sven Wiese at CO@Work<p>Our very own Sven Wiese talks about "Convex Optimization via Cones and MOSEK 9" at CO@Work. See the talk at:</p><p style="text-align: center;"><a href="https://youtu.be/cGpWM2mIpC4">https://youtu.be/cGpWM2mIpC4</a></p><p style="text-align: left;">PDF of the slides:</p><p style="text-align: center;"><a href="https://docs.mosek.com/slides/2020/cowork/wiese_mosek.pdf">https://docs.mosek.com/slides/2020/cowork/wiese_mosek.pdf</a></p><p style="text-align: left;">Full program:</p><p style="text-align: center;"><a href="http://co-at-work.zib.de/#schedule">http://co-at-work.zib.de/#schedule</a></p>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-50923970298667977822020-07-15T22:42:00.000+02:002020-07-15T22:42:27.937+02:00CO@Work 2020From our colleagues organizing the <b>Combinatorial Optimization at Work 2020</b> summer school <a href="http://co-at-work.zib.de/">CO@Work 2020</a> here is a short advert of this very interesting event:<br /><br /><br /><br />In its sixth instantiation, CO@Work will be a full online event, taking place from September 14 to 26, 2020.<br /><br />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.<br /><br />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).<br /><br />You can find more information and a registration link here: <a href="http://co-at-work.zib.de/">http://co-at-work.zib.de/</a><br /><br />Registration is for free, and as a TU Berlin course, it gives 10 ECTS credit points.Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-58069750093694243762020-06-05T12:53:00.000+02:002020-06-05T12:53:56.110+02:00To upgrade or not to upgrade that is the questionA 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. <div><br /></div><div>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</div><div><br /></div><div>AMD EPYC 7402P 24-Core Processor</div><div><br /></div><div>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.</div><div><br /></div><div>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.</div><div><br /></div><div>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.</div><div><br /></div><div>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.</div><div><br /></div><div><br /></div>Erling D. Andersenhttp://www.blogger.com/profile/12871077105817644633noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-31922323947068353572020-05-06T23:34:00.000+02:002020-05-06T23:34:41.292+02:00n-queens in FusionIn a nice <a href="https://www.linkedin.com/posts/soroudi_chess-onlineeducation-mathematics-activity-6663750145156366336-weOq">post on LinkedIn by Alireza Soroudi</a> the author presents a short GAMS integer model for the classical <a href="https://en.wikipedia.org/wiki/Eight_queens_puzzle">n-queens puzzle</a>: place the maximal number of non-attacking queens on an $n\times n$ chessboard. <br /><br />We couldn't resist writing it up in Python Fusion as well.<br /><br /><script src="https://gist.github.com/mosekadmin/cbac81adc2d36c3f85d9002025cfda86.js"></script> And here is the solution we get for $n=8$: <br /><div style="text-align: center;"><span style="font-family: inherit;">[[_ ♕ _ _ _ _ _ _]</span></div><div style="text-align: center;"><span style="font-family: inherit;"> [_ _ _ _ _ ♕ _ _]</span></div><div style="text-align: center;"><span style="font-family: inherit;"> [♕ _ _ _ _ _ _ _]</span></div><div style="text-align: center;"><span style="font-family: inherit;"> [_ _ _ _ _ _ ♕ _]</span></div><div style="text-align: center;"><span style="font-family: inherit;"> [_ _ _ ♕ _ _ _ _]</span></div><div style="text-align: center;"><span style="font-family: inherit;"> [_ _ _ _ _ _ _ ♕]</span></div><div style="text-align: center;"><span style="font-family: inherit;"> [_ _ ♕ _ _ _ _ _]</span></div><div style="text-align: center;"><span style="font-family: inherit;"> [_ _ _ _ ♕ _ _ _]]</span></div>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-34808625155404656822020-05-04T16:23:00.000+02:002020-05-04T16:23:15.895+02:00Grouping in FusionWe 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.<br /><br />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: <br /><ul><li>an upper bound $b_i$ on the total value within each group,</li><li>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$</li><li>the constraint that all values within one group have the same sign.</li></ul><br /><div><span style="font-size: large;"><b>Pick, slice</b></span></div><div>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.</div><div><script src="https://gist.github.com/mosekadmin/6fd4541593b67a4ac5ffa38f9a5c1eee.js"></script></div><div><br /></div><div><b><span style="font-size: large;">Loop-free</span></b></div><div>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 <i>membership matrix </i>$\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] .$$</div><div>This matrix is easy to construct in Fusion. </div><div><script src="https://gist.github.com/mosekadmin/3ab603437000f78c736a1a7c18a0c387.js"></script></div><div>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].$$</div><div>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.</div><div><script src="https://gist.github.com/mosekadmin/faa3a28374a1666ee6a6a2d8844f827a.js"></script></div><div><span style="font-size: large;"><b>Loop-free same sign</b></span></div><div>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:</div><div><script src="https://gist.github.com/mosekadmin/7d2b160c406dc1f1a40a119cc403e445.js"></script></div><div><br /><br /></div>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-39056797174280117772020-04-06T09:14:00.001+02:002020-04-06T09:14:05.653+02:00Easter 2020Support and sales are closed from <b>Thursday</b>, Aptil 9th, until <b>Monday</b>, April 13th, inclusive.<br /><br />The MOSEK team wishes everyone safe Easter.Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-47030095249417535052020-03-11T22:19:00.002+01:002020-03-16T08:51:24.682+01:00Coronavirus COVID-19<b>March 11th: </b>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.<br /><br /><b>March 16th: </b>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.<br /><br />We will update this post if there is important new information.Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-4893408341573126862020-03-09T12:44:00.003+01:002020-05-04T16:23:42.528+02:00Parametrized Fusion - benchmarksWe present some indicative benchmarks of the new <i>Parametrized Fusion,</i> to be released in <a href="https://themosekblog.blogspot.com/2020/02/mosek-92-beta-parametrized-fusion.html">MOSEK 9.2</a>. We compare a few typical optimization models being reoptimized in two scenarios:<br /><br /><ul><li>the model is constructed from scratch with new data for each optimization, MOSEK version 9.1 (<span style="background-color: lime;">green bars</span>)</li><li>the parametrized model is constructed once and parameters are set before every optimization, MOSEK version 9.2 (<span style="background-color: #6fa8dc;">blue bars</span>)</li></ul><div>The <span style="background-color: #ea9999;">red bar</span> in all cases represents the amount of time spent in the optimizer.</div><div><br /></div><h2>1. Markowitz portfolio optimization</h2><div>Here we consider a simple model</div><div>$$\begin{array}{ll}\mbox{maximize} & \mu^T x \\ \mbox{subject to} & e^Tx=1,\\ & \gamma \geq \|Fx\|_2, \\ & x\geq 0, \end{array}$$</div><div><br /></div><div>where</div><div><ul><li>$x\in\mathbb{R}^{2000}$,</li><li>$F\in \mathbb{R}^{200\times 2000}$ is a dense matrix,</li><li>$\gamma$ is the only parameter changed between optimizations,</li><li>we resolve the model for 200 values of $\gamma$.</li></ul><div>Note that by parametrizing we avoid inputting the same big matrix $F$ over and over again.</div></div><h2><span id="docs-internal-guid-e570fc3e-7fff-6b46-788d-6a3a62b9f390" style="font-weight: normal;"><span style="font-family: "arial"; font-size: 16pt; vertical-align: baseline; white-space: pre-wrap;"><span style="border: none; display: inline-block; height: 468px; overflow: hidden; width: 624px;"><img height="468" src="https://lh3.googleusercontent.com/ZgJKTbtHDRK11xVbmitQfgsEx4fdmp0LsD3N79HgA8LODCIpkNyc3_-o4qAIy0JJoqXYLRmJYsoBRgCvrV-NpGiRXIFhYyh6zi00INwAvECL0Ap69bn_LI7es2tdALuLylRFD9LP" style="margin-left: 0px; margin-top: 0px;" width="624" /></span></span></span></h2><h2>2. Various models</h2><div>Next we run a few models implemented in Python only.</div><div><ul><li>MPC - Model Predictive Control similar as in <a href="https://colab.research.google.com/github/cvxgrp/cvx_short_course/blob/master/intro/control.ipynb">this demo</a> with 15 states, 8 inputs, horizon length $T=80$, parametrized by the initial state, 100 resolves,</li><li>Polytopes - a geometric<a href="https://docs.mosek.com/modeling-cookbook/powo.html#maximum-volume-cuboid"> polytope containment</a> problem, the parameter is a $3\times 3$ matrix $P$ which enters in many constraints of the form $Px=y$, 1000 resolves.</li><li>Elastic - a <a href="https://docs.mosek.com/9.2/pythonfusion/tutorial-parametrization.html">linear regression</a> 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.</li><li>Option - a big <a href="https://nbviewer.jupyter.org/github/MOSEK/Tutorials/blob/master/option-pricing/utility-option-pricing.ipynb">option pricing model</a> with complicated structure and multiple parameters, 10 resolves.</li></ul><div><span id="docs-internal-guid-ea0193ec-7fff-2156-d39d-d591c6079caa"><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"><span style="border: none; display: inline-block; height: 468px; overflow: hidden; width: 624px;"><img height="468" src="https://lh5.googleusercontent.com/Ck89VuFldq-EZO6YWeKJfaa13M9uaHdY-0lEQ3KSGQH2DkWMYFcc-0OArxJMWANSyeKOrPIqBk9M9INnAKNLTaGfAksmdPIJqu_H149UExxPyZjEo8ZnBb_z3lkFzjWBSHARNWVc" style="margin-left: 0px; margin-top: 0px;" width="624" /></span></span></span></div></div>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-32098448593669154602020-03-03T09:30:00.000+01:002020-03-03T09:33:02.737+01:00CVX 2.2 supports exponential cone in MOSEKNew features in <a href="http://cvxr.com/cvx/">CVX</a>!<br /><br />The <a href="http://cvxr.com/cvx/download/">last release 2.2</a> of CVX comes with support for the exponential cone in MOSEK. It means that problems involving <span style="font-family: "courier new" , "courier" , monospace;">log, exp, rel_entr, log_det, kl_div</span> and other variants of logarithms and exponentials will be passed directly to a single MOSEK solve without employing a successive approximation method.<br /><br />CVX 2.2 also comes bundled with the very recent MOSEK 9.1.9.<br /><br />For an example of a log_det problem with MOSEK output in CVX 2.2 see:<br /><br /><a href="http://web.cvxr.com/cvx/examples/log_exp/html/sparse_covariance_est.html">http://web.cvxr.com/cvx/examples/log_exp/html/sparse_covariance_est.html</a><br /><br />(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.)Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-64421351056591770432020-02-28T10:51:00.001+01:002021-06-04T10:21:36.354+02:00Price list change from June 1st, 2020Our price list will change from <b>June 1st, 2020</b>. Prices change for the first time since June 2015 and increase on average by 5.4%.<br /><br />New prices can be found at <a href="https://www.mosek.com/sales/prices-from-june-1st-2020/">https://www.mosek.com/sales/prices-from-june-1st-2020/</a>.<div><br /></div><div>(This move was postponed until October 2021 due to COVID-19).<br /><br /><br /></div>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.comtag:blogger.com,1999:blog-7666614109674699584.post-61594560444768220942020-02-21T14:42:00.000+01:002020-02-21T14:42:07.928+01:00MOSEK 9.2 Beta - Parametrized FusionWe are releasing a beta version of MOSEK 9.2. It is a direct continuation of version 9.1 and fully compatible with its predecessor.<br /><br />The new feature introduced in version 9.2 is <b>parametrization of Fusion models</b>, 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.<br /><br />For more information, with links to examples in C++, Python, Java and C#, see our website:<br /><br /><div style="text-align: center;"><a href="https://www.mosek.com/content/version-9-beta/">https://www.mosek.com/content/version-9-beta/</a></div><div style="text-align: center;"><br /></div><div style="text-align: left;">In near future we will publish more examples of parametrized models as well as related benchmarks.</div>Michal Adamaszekhttp://www.blogger.com/profile/02629946505878541732noreply@blogger.com