The new prices will come into effect on June 1st, 2024.
The price for the basic PTS and PTON floating licenses increases with 100 USD each. Our other prices follows accordingly. With NODE licenses costing 4 times the price of their floating license counterpart and the annual maintenance 25% of the base price of the part.
This equates to a price increase of 5.1% on average.
The new prices can be found at the top of our commercial pricing page on our website.
On Monday (January 22) MOSEK CEO and chief scientist Erling Dalgaard Andersen will be giving a talk at Linköping University. The talk will, maybe unsurprisingly, be about conic optimization.
The seminar will take place at 13.15 in Hopningspunkten (B-huset) on the campus of LiU. It is open for everybody who are interested :)
We here at MOSEK have had a good start to the new year and we hope the same is true for all of you!
For those who have had a less than optimal start to the year we would like to share some resources that might bring you on to the fast path to optimum.
We know many users of MOSEK use it for portfolio optimization, in light of that we gladly recommend the recently published paper Markowitz Portfolio Construction at Seventy.
Further there is now an unofficial package for CVX with native Apple Silicon support. This package due to the work of Dr. Wenyuan (Mike) Wang and MOSEKs own Michal Adamaszek with permission from Michael C. Grant.
We hope these resources can be of use and that you will have a great 2024!
In this year's Christmas blogpost, we explain how to properly hang the Christmas lights on the Christmas tree 🎄.
Let us fix some notation. The 🎄 in dimension $D\geq 2$ is (surprise!) a reflected and rescaled quadratic cone:
$$(x_1,\ldots,x_D) \in \unicode{x1F384} \subseteq\mathbb{R}^D\quad \iff\quad W(1-x_D/T)\geq \|x_{1:D-1}\|_2,\ x_D\geq 0$$
where $T$ is the coordinate of the top and $W$ is a width rescaling parameter. The tree comes decorated with $P$ ornaments located at $c_1,\ldots,c_P\in\unicode{x1F384}$. Here is an example in dimension $D=2$.
The Christmas lights chain consists of $N$ bulbs evenly spaced in distance $L$ along the wire. Their locations $x_1,\ldots,x_N\in \unicode{x1F384}$ are to be determined. If, like us, you have been collecting and repairing your lights for almost 25 years then it is possible that each of the lightbulbs shines with different power $I_1,\ldots,I_N$.
The main requirement we have is that each of the ornaments is nicely illuminated, more precisely we wish to maximize the total amount of light received by the worst-illuminated ornament. Let $\mathrm{il}_j(d)$ be the amount of light that a point in distance $d$ from the light source receives from the $j$-th lightbulb. Obviously $\mathrm{il}_j(d)$ is a decreasing function of the distance $d$ to the bulb. That leads us to the optimization problem:
$$\begin{array}{llrr}\mathrm{maximize} & \mathrm{il}_{MIN} & &\\ \mathrm{s.t.} & \mathrm{il}_{MIN}\leq \sum_{j=1}^N \mathrm{il}_j(d_{ij}) & i=1,\ldots,P & (2.1) \\ & d_{ij}\geq \|x_j-c_i\|_2 & i=1,\ldots,P,\ j=1,\ldots,N &(2.2) \\ & \|x_j-x_{j+1}\|_2\leq L & j=1,\ldots,N-1 & (2.3) \\ & x_j \in \unicode{x1F384} & j=1,\ldots,N &(2.4) \\ & x_1 = (W,0,\ldots) & &(2.5)\end{array}$$
In principle we should let the brightness of the $j$-th bulb decay as $\mathrm{il}_j(d)=I_j/d^{D-1}$, but that does not lead to a convex constraint in (2.1). Instead, let us use a piecewise-linear approximation $\widetilde{\mathrm{il}_j}(d)=\mathrm{max}(I_i-d,0)$. This function is not concave either, so it cannot be used directly in (2.1) in a continuous fashion, but when written as
$$(d\in[0,I_j]\ \mathrm{and}\ \widetilde{\mathrm{il}_j}(d) = I_j-d)\ \mathrm{or}\ (d\geq I_j\ \mathrm{and}\ \widetilde{\mathrm{il}_j}(d) = 0)$$
it becomes evidently definable via a disjunctive constraint. Here is a rough comparison between $\mathrm{il}_j(d)$ and $\widetilde{\mathrm{il}_j}(d)$:
We end with some examples. The ornaments have been given intensity according to the amount of light received. The disk sizes correspond to the brightness of lightbulbs.
 |
It remains to wish all readers a very well-lit 🎄 and Happy New year 2024!
The MOSEK team
If you are going to the conference or if you are based in Abu Dhabi and would like to discuss MOSEK, don’t hesitate to reach out to sales@mosek.com.
See you in Abu Dhabi!
When an optimization problem is infeasible it is common to ask for the reason for infeasibility. It is very typical that the model is infeasible because it contains a set of mutually contradicting constraints which is relatively small compared to the total size of the problem. Locating and analyzing such a subset is usually helpful in understanding the reasons for infeasibility.
Such considerations have led the OR community to come up with the notion of Irreducible Infeasible Set (IIS) - a subset of constraints which is infeasible but cannot be reduced to a smaller infeasible set (all its proper subsets are already feasible). Every infeasible problem has an IIS - possibly many, possibly of different sizes. For example the problem bgdbg1 (see below) has a few hundred bounds but its infeasibility is caused already by the small segment
X104_JY >= 0.0
X104_JH >= 36.0
X104_JY + X104_JH <= 6.0
consisting of 3 bounds, which is an IIS. In fact the same model has also another IIS
X199_CM1 >= 96.0
X199_CM1 <= 86.0
with just 2 bounds (it doesn't get any better - a single linear bound is always feasible on its own).
An IIS can be found by a simple iterative algorithm which tries to remove one bound at a time and checks if the problem remains infeasible. We have implemented it for linear and mixed-integer linear problems in a recently published python notebook, where you can also read more details of the algorithm and its implementation. You can also download the python code directly.
Below are the results produced by our sample code on the infeasible problems from NETLIB. We report the number of bounds in the problem, the size of the (Farkas) infeasibility certificate (these are the bounds that will appear in the infeasibility report or in the task.getinfeasiblesubproblem() function) and finally the size of the smallest IIS out of 5 runs of the algorithm (the IIS found depends on an ordering of the bounds, which we randomize).
bgdbg1.gz: OK, all bounds = 926, Farkas size = 2, IIS size = 2
bgetam.gz: OK, all bounds = 1577, Farkas size = 31, IIS size = 25
bgindy.gz: OK, all bounds = 14694, Farkas size = 196, IIS size = 154
bgprtr.gz: OK, all bounds = 68, Farkas size = 12, IIS size = 10
box1.gz: OK, all bounds = 723, Farkas size = 10, IIS size = 9
ceria3d.gz: OK, all bounds = 3576, Farkas size = 117, IIS size = 198
chemcom.gz: OK, all bounds = 1416, Farkas size = 86, IIS size = 37
cplex2.gz: numerical issues, all bounds = 733, Farkas size = 177, IIS size = 715
ex72a.gz: OK, all bounds = 609, Farkas size = 61, IIS size = 60
ex73a.gz: OK, all bounds = 597, Farkas size = 28, IIS size = 25
forest6.gz: OK, all bounds = 196, Farkas size = 96, IIS size = 92
galenet.gz: OK, all bounds = 26, Farkas size = 5, IIS size = 5
gosh.gz: OK, all bounds = 15353, Farkas size = 9, IIS size = 9
gran.gz: OK, all bounds = 8386, Farkas size = 2, IIS size = 2
grbeai.gz: OK, all bounds = 10402, Farkas size = 93, IIS size = 54
itest2.gz: OK, all bounds = 13, Farkas size = 3, IIS size = 3
itest6.gz: OK, all bounds = 21, Farkas size = 3, IIS size = 3
klein1.gz: OK, all bounds = 108, Farkas size = 55, IIS size = 54
klein2.gz: OK, all bounds = 531, Farkas size = 57, IIS size = 55
klein3.gz: numerical issues, all bounds = 1082, Farkas size = 97, IIS size = 192
mondou2.gz: OK, all bounds = 1832, Farkas size = 24, IIS size = 23
pang.gz: OK, all bounds = 942, Farkas size = 34, IIS size = 32
pilot4i.gz: OK, all bounds = 1886, Farkas size = 43, IIS size = 47
qual.gz: OK, all bounds = 1360, Farkas size = 217, IIS size = 370
reactor.gz: OK, all bounds = 1652, Farkas size = 15, IIS size = 9
refinery.gz: OK, all bounds = 1360, Farkas size = 206, IIS size = 120
vol1.gz: OK, all bounds = 1360, Farkas size = 275, IIS size = 196
woodinfe.gz: OK, all bounds = 173, Farkas size = 2, IIS size = 2
The work reported here and in the notebook was carried out by Adam Bosák during his student internship at MOSEK. Thanks!
Next week Informs annual meeting will take place in Phoenix and MOSEK will of course be there. If you are going to Informs annual meeting and would like to discuss MOSEK, don’t hesitate to reach out to sales@mosek.com.
See you
in Phoenix!
