After optimizing a problem with MOSEK it is time to retrieve the results. This post explains the philosophy behind the responses and statuses MOSEK returns.
The first thing to know is if the optimization completed successfully. This is indicated by the response code. Anything other than "OK" indicates an error. Typical error responses are "out of memory", "internal error", "error in input data" and so on. A non-OK response means there are no reliable solutions to look for.
Assuming the optimizer terminated without error, the next thing to ask is "why did it terminate?". The answer is provided by the termination code. "OK" means standard termination, reaching the numerical termination criteria at hand. Other termination codes, however, are not errors. They can indicate such reasons for stopping as "reached a given number of solutions", "reached the time limit", "could not make more progress (stall)", "user interruption from a callback function" and so on. In these cases there is usually a useful solution.
Having checked why the optimizer stopped the next question is "What does it think about my problem?". This is answered by the problem status, which, roughly, indicates if the problem was determined to be feasible or not. Problem status can also be unknown if no conclusion was reached.
Finally we can ask "How do I interpret the solution the optimizer returns?". This is indicated by the solution status. Besides a standard primal-dual feasible solution the solver can for instance return a certificate of primal or dual infeasibility. For integer problems solution status will indicate whether the solution is optimal or just feasible. Again, "unknown" is always a possible answer.
If we are happy with problem and solution status it is now time to fetch the results.
Some users will next want to analyze the solution on their own to check that it is numerically satisfying in that violations and gaps are sufficiently small. The last word on whether the solution is satisfactory always belongs to the user; the answer may be good enough even when the problem status is unknown and/or the termination code indicates "stall".
Finally some users may want to know in greater detail how the optimization process proceeded: data such as time taken by the optimizer, number of iterations, solution quality, etc. which normally appear in the log are available as information items.
This completes the discussion mostly from the perspective of the Optimizer API. In other interfaces implementation details will differ, for instance an exception will be thrown in place of a non-OK response code. Details and an example can be found in the "Accessing a solution" section of your API's tutorial and the corresponding response.* example.
Thursday, April 25, 2019
Monday, February 18, 2019
Porting Fusion for MATLAB code
Fusion for MATLAB is discontinued starting with MOSEK version 9. If you wish to continue using MOSEK in MATLAB through the Fusion interface, this document describes how to adapt existing code to use the standard Fusion for Java.
First, use mosek.jar instead of mosekmatlab.jar in the Java path in MATLAB, for instance:
Next, every time you explicitly index into an object of a class from mosek.fusion use 0-based indexing, standard for Java, instead of 1-based indexing familiar from MATLAB. This applies to classes such as Variable, Expression, Matrix and to all operations such as index, pick, slice. For example, if you define a variable then its individual entries are
whereas in the old interface they would be indexed from 1 through 4.
This applies only to indexing Java objects from mosek.fusion. Nothing changes with regard to MATLAB arrays, so operations which don't use explicit indexes are not affected, and whenever the input/output of a method is a MATLAB array, it will be 1-based indexed as always. So the following piece of code works both in the old and new regime:
Finally note that Java 1.8+ is required.
First, use mosek.jar instead of mosekmatlab.jar in the Java path in MATLAB, for instance:
Next, every time you explicitly index into an object of a class from mosek.fusion use 0-based indexing, standard for Java, instead of 1-based indexing familiar from MATLAB. This applies to classes such as Variable, Expression, Matrix and to all operations such as index, pick, slice. For example, if you define a variable then its individual entries are
whereas in the old interface they would be indexed from 1 through 4.
This applies only to indexing Java objects from mosek.fusion. Nothing changes with regard to MATLAB arrays, so operations which don't use explicit indexes are not affected, and whenever the input/output of a method is a MATLAB array, it will be 1-based indexed as always. So the following piece of code works both in the old and new regime:
Finally note that Java 1.8+ is required.
Wednesday, January 30, 2019
Planned end of support for version 7
In connection with the recent beta release of MOSEK 9, we will be stopping support for version 7 which was released in 2013. According to our policy of supporting version $n$ at least two years after the release of version $n+1$, we plan to:
- end support for version 7 on 31-jun-2019 (ie. over three years after the release of version 8)
- support version 8 (current stable release) until at least 15-jan-2021 (and potentially longer)
For details see https://www.mosek.com/content/release-policy/ .
Friday, January 25, 2019
DTU CEE Energy Systems Summer School 2019
DTU CEE Summer School 2019 "Data-Driven Analytics and Optimization for Energy Systems" takes place June 16-21 2019 at DTU in Copenhagen. This is the 4th edition in a very successful series of workshops about optimization in power systems.
MOSEK sponsors the school and two MOSEK scholarships will be awarded to outstanding student applicants.
Program, speakers, deadlines and more can be found at:
Program, speakers, deadlines and more can be found at:
Tuesday, January 15, 2019
MOSEK version 9.0 BETA
We start the new year 2019 with a Beta version release of MOSEK 9.
All information and instructions on this page:
All information and instructions on this page:
Thursday, December 13, 2018
Christmas tree denoising via SDP
In our last year's Christmas special we ran logistic regression on a sampled Christmas tree. By public demand this year we treat the tree with some semidefinite programming.
We start with a $50 \times 100$ binary image with noise.
We start with a $50 \times 100$ binary image with noise.
It is convenient to encode the image as a sequence of pixels $x_i\in\{-1,1\}$. Then we can write (see eg. here) a simple binary quadratic denoising model
$$\mathrm{maximize} \sum_{i\sim j}z_iz_j+\gamma\sum_i x_iz_i,\quad z_i\in\{-1,1\}$$
which favors similarity between neighboring ($i\sim j$) pixels in $z$ and the similarity between $z$ and the original $x$, with tradeoff between the two measures provided by $\gamma$.
Binary quadratic problems have a natural SDP relaxation, in this case
$$ \begin{array}{ll} \mathrm{mazimize} & \sum_{i\sim j} Z_{ij} +\gamma x^Tz \\ \mathrm{s.t.} & \left[ \begin{array}{cc}Z&z\\z^T&1\end{array} \right] \succeq 0, \\ & \mathrm{diag}(Z)=1.\end{array} $$
We solve the SDP for various $\gamma$ ($Z$ has dimension $5000$; this is not the most efficient image processing algorithm ever invented). To further simplify we don't round but let the raw $z$ interpolate between shades of green.
Merry Christmas from the MOSEK team.
Tuesday, November 27, 2018
Geometric programming preview
Geometric programs (GP) can be conveniently expressed in conic form using the exponential cone
$$ x\geq y\exp(z/y),\quad y>0$$
in the upcoming version 9 of MOSEK. Here is a preview implementation of some signal-to-interference-and-noise optimization problems in Python Fusion:
You can read more about modeling GPs in our Modeling Cookbook:
MOSEK's previous GP interface (scopt/dgopt/expopt), which is being phased out, relied on the slower and less accurate general nonlinear optimizer. You can read more about version 9 plans in
$$ x\geq y\exp(z/y),\quad y>0$$
in the upcoming version 9 of MOSEK. Here is a preview implementation of some signal-to-interference-and-noise optimization problems in Python Fusion:
The key log-sum-exp constraint is just a few lines:
Subscribe to:
Posts
(
Atom
)