Single variable per cone in MOSEK

1

Hello,

I’m using CVX with MOSEK to solve Radial Distribution Load Flow Using Conic Programming. One set of the constraints in my code is the following
for k = 1:NL i = f(k); j = t(k); norm([R(k); T(k); u(i)-u(j)]) <= u(i)+u(j) end
where f and t are integer vectors in which certain numbers are contained more than once. This means that certain variables from vector u will be member of more than one cone which is not allowed in MOSEK.

I wonder if CVX introduces additional variables and linear constraints such that no variable belongs to two different cones or I have to do it myself?

2

CVX will do that for you. You should only worry about formulation a valid cvx model.

1 Like
3

Thank you for your response. I have managed to run my optimization. However, I have encountered some strange results. I run the following

clear
load('case69.mat')
cvx_begin
    cvx_solver mosek; cvx_precision('low')
    % cvx_solver sdpt3; cvx_precision('medium')
    variable R(NL)
    variable T(NL)
    variable u(NB)
    maximize(sum(R))
    subject to
        Aeq * [R; T; u] == beq
        u(1) == uslack
        u >= 0
        R >= 0
        for k = 1:NL
            i = f(k);
            j = t(k);
            norm([R(k); T(k); u(i)-u(j)]) <= u(i)+u(j)
        end
cvx_end

which is practically the problem of voltage calculation in radial power distribution network. Also I know an optimal solution, i.e. a solution obtained with a standard method for voltage calculation in distribution networks.

The case I’m trying to solve is probably badly scaled: the smallest coefficient in Aeq is around 3 and the biggest is around 45000, but I hope it is not to badly scaled.

I have tried SDPT3 and MOSEK. Surprisingly SDPT3 gives me Status: Solved with variables differing from the known optimal values by 1e-10, while MOSEK reports Status: Inaccurate/Solved and also gives Mosek error: MSK_RES_TRM_STALL () and its results are differing from the optimal ones by 0.1 to 0.3. I should mention that the range of values are about 1 for R, about 0 for T and about 0.5 for u.

The authors of this paper claim that they have solved the same problem with MOSEK. Obviously, I’m doing something wrong. I have tried some suggestions from the user guide without success.

Should I try to perform variable scaling before running MOSEK or maybe add/or remove constraints? In this particular case some of the variables have so much close values so for any practical applications I may add equality constraint for them.

4

You are aware computations are done in finite precision. So you will only get an approximate answer. So an error 1.0e-10 in the objective value is very small and most likely negible. Indeed the objective is typically correct up to 8 figures using the default stopping criteria.

MOSEK says stall if it runs into numerical problems. This can be caused by bad scaling and other bad formulations e.g. near infeasibility, badly scaled solution etc. If you send the problem support@mosek.com we can take look at it.

Note the author in the paper did not use CVX and maybe another version of MOSEK. This will change many things that may make the problem easier or harder to solve.

5

Thank you for the advice to contact support@mosek.com. They were very kind and helpful.

After getting some suggestions from them I tried to solve the problem without CVX. I added additional variables and equality constraints so that my new variables appear in only one cone. After running mosekopt I still get MSK_RES_TRM_STALL but the results are very close to the known optimum so for practical application they are OK.