Monday, December 18, 2023

Christmas lights

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)$:

Let us quickly recap problem (2): constraint (2.1) (with $\widetilde{\mathrm{il}_j}$ in place of $\mathrm{il}_j$) computes the approximate amount of light received by each ornament as a function of the distance $d_{ij}$ from the $i$-th ornament to the $j$-th bulb; that distance is computed in (2.2). Two consecutive lightbulbs cannot be spaced by more than the wire length between them, as in (2.3), while (2.5) ensures that the chain starts at the fixed bottom point of the tree, where the electric socket is. The complete MOSEK Fusion model can be found on GitHub; it is a mixed-integer (due to the disjunctive constraints) second-order cone optimization problem.

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

Tuesday, November 28, 2023

MOSEK in Abu Dhabi

Next week MOSEK will be in Abu Dhabi attending the dual conference Converging paths in commodity and financial market analysis. In consist of the established conferences Research in Options and Euro Working Group for Commodity and Financial Modelling

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!

Monday, October 9, 2023

Irreducible Infeasible Subsets

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!

Informs Annual meeting

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!

Monday, October 2, 2023

Autumn and MOSEK

The summer has been long here in Copenhagen, but now it feels like the fall is here to stay. For MOSEK the arrival of autumn means the arrival of thousands of new persons allegeable 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!

 

Thursday, September 21, 2023

Apple Silicon and Matlab R2023b

The MATLAB R2023b is the first stable release with native support for the Apple Silicon M1/M2 platform. 

The MOSEK Optimization Toolbox for MATLAB is available natively for Apple Silicon from MOSEK 10.1. It means that from version 10.1 there are two ways to use MOSEK in MATLAB on the M1/M2 platform:

  • (natively) Use the Apple Silicon release of MATLAB (version 2023b+, architecture MACA64) and the osxaarch64 MOSEK package, with its included toolbox for MATLAB.
  • (via Rosetta, the "old" way) Use the Intel release of MATLAB (any version, architecture MACI64) and the osx64x86 MOSEK package with its included toolbox for MATLAB. 
In other words, the architecture of MOSEK should match the architecture of the MATLAB installation.

The "old" way, with emulation via Rosetta, may be relevant for users of binary MATLAB packages which do not (yet) have native releases for M1/M2 but only for the Intel-based Macs. This is (currently) the case, for instance, with CVX.

Monday, September 18, 2023

MIP improvements in 10.1

 

In a previous blogpost we talked about additions made to MOSEK with the release of version 10.1. However, as usual with new releases improvements in the existing functionality have also been made.

One area where we have improved a lot with our latest release is with our mixed integer solver. On our internal benchmarking set we have seen an improvement of over 30 per cent on the geometric mean of the solution time compared to MOSEK 10.0.

Does this mean you will see a 30 per cent improvement on your mixed integer problems? No, or yes or maybe… It depends!

Mixed integer problems are hard, NP-complete in fact, and in the design of the solver algorithms there are tradeoffs to be made. These tradeoffs will make the solver good for certain problems and less so for others. Tuning the solver will determine which problems it will perform well on and on which it will not.  

At MOSEK we tune our solvers based on our internal benchmarking sets. These sets are mainly based on problems we have received from customers, and we feel they are representative of the problems being solved for practical applications.

So, does this mean you will see a 30 per cent improvement on your mixed integer problems? No, not for certain. But it might be worthwhile to upgrade to 10.1 and test and see!