Slow sdp setup

464 views
Skip to first unread message

zoharl

unread,
Jun 6, 2014, 10:53:42 AM6/6/14
to yal...@googlegroups.com
I need tips to make the code below faster. It seems that slicing and assignment of sdpvar is very slow (see lines with 'slow' comment).

 
   m = size(T,1);
   
    Q
= sdpvar(szP(1), szP(2), 'full');
    t
= sdpvar(1);
   
   
Objective = t;

    dpsi
= sdpvar(3, 3*m, 'full');
   
for i = 1:3
        dpsi
(:, i:3:(3*(m-1)+i)) = Q(:,T(:,i+1)) - Q(:,T(:,1)); % slow
   
end
   
   
if 0
        J
= sdpvar(3, 3*m, 'full');        
       
for i = 0:m-1
            j
= (1:3)+3*i;
            J
(:,j) = dpsi(:,j) * dphii(:,j);
       
end
   
else
        dpsi
= mat2cell(dpsi, 3, 3*ones(1,m)); % slow
        dphii
= mat2cell(dphii, 3, 3*ones(1,m));
        J
= cellfun(@mtimes, dpsi, dphii, 'uni', 0); % slow
        J
= [J{:}]; % slow
   
end
   
    dd
= J - Rs;
    dd
= reshape(dd, 9, m);        

   
if ~isempty(Ceq)
        eq_con
= [Ceq * Q' == deq];
    end

    cones = [t * bt(bt==1)'
kl(bt==0)'; dd(:,bt==1) dd(:,bt==0)];
   
    Constraints = [eq_con; cone(cones)];
   
    options = sdpsettings('
verbose',2,'solver','cplex','savesolverinput',1,'debug',1,'showprogress',1);

    sol = solvesdp(Constraints, Objective, options);



Johan Löfberg

unread,
Jun 6, 2014, 12:36:27 PM6/6/14
to yal...@googlegroups.com
Much easier to give performance recommendations if the code can be run

zoharl

unread,
Jun 6, 2014, 12:51:30 PM6/6/14
to yal...@googlegroups.com

Runnable code (main.m):

https://www.dropbox.com/s/7km86y449627ebr/yal.zip

while you are at it, cplex runs out of memory ;)

Johan Löfberg

unread,
Jun 6, 2014, 2:25:53 PM6/6/14
to yal...@googlegroups.com
I would do

index1 = zeros(1,3*m);
index0
= zeros(1,3*m);

for i = 1:3

  index1
(i:3:(3*(m-1)+i))=T(:,i+1);
  index0
(i:3:(3*(m-1)+i))=T(:,1);              
end
dpsi
= Q(:,index1)-Q(:,index0);

and

[i,j,k] = find(dphii);i = i + 3*floor((j-1)/3);
S
= sparse(i,j,k);
J
= dpsi*S;
% This implements
% S = [];
% for i = 0:m-1
%   j = (1:3)+3*i;
%   S = blkdiag(S,sparse(dphii(:,j)));
% end

The problem is huge though. After setting up the problem (takes 1s) gurobi, mosek and sdpt3 all crash due to memory (and YALMIPs interface to cplex runs into memory issues, but I suspect cplex would fail if it actually was called)

zoharl

unread,
Jun 6, 2014, 6:38:23 PM6/6/14
to yal...@googlegroups.com

Black magic!

Man, it reduced the time from 333 sec to 1 sec; nice trick.

The thing is that now the problem is huge (1e8 nnz compared to (AFAIR) 1e6 nnz previously), and mosek solves it slowly (4 iter in 300 sec, and I stopped it). Previously, after the slow setup, mosek solved it in 10 sec (AFAIR). So, there was a fundamental change that tripped yalmip?

On the other hand, your trick worked well with cvx; to run it toggle the comments on:

[Q, success] = solve_cvx(size(P), dphii, Rs, T, Ceq, deq, bt, kl);
%[Q, success] = solve_yalmip(size(P), dphii, Rs, T, Ceq, deq, bt, kl);

Here is the updated code:



Johan Löfberg

unread,
Jun 7, 2014, 2:31:39 AM6/7/14
to yal...@googlegroups.com
That is odd. The new approach should not change the end result. Could you please post a smaller instance for easier debugging/analysis

zoharl

unread,
Jun 7, 2014, 10:51:34 AM6/7/14
to yal...@googlegroups.com

Johan Löfberg

unread,
Jun 7, 2014, 11:13:29 AM6/7/14
to yal...@googlegroups.com
Do you see the same difference in nnz on the small instance? Everything looks the same to me regardless of approach (gurobi printout)

Presolved: 90 rows, 103 columns, 216 nonzeros
Presolved model has 12 second-order cone constraints
Ordering time: 0.00s

Barrier statistics:
 
Free vars  : 12
 AA
' NZ     : 8.100e+02
 Factor NZ  : 2.381e+03
 Factor Ops : 7.321e+04 (less than 1 second per iteration)



zoharl

unread,
Jun 7, 2014, 12:37:46 PM6/7/14
to yal...@googlegroups.com
Okay, I confused it with cvx. Indeed the change doesn't affect the problem formulation.

But please note the following logs:


cvx (code in previous posts) formulates the problem such that there are 43k constraints, and 2.8e6 nnz (after factorization), while yalmip has 215k constraints, and 1.4e8 nnz.
cvx solves the problem in 7 sec, while I stopped yalmip on the third iteration after 141 sec. So here is a suggestion where yalmip can be improved.

zoharl

unread,
Jun 8, 2014, 12:56:47 AM6/8/14
to yal...@googlegroups.com
Coming to think of it, my suggestion is not fair. yalmip is a wrapper, and it does a good job in setting up the problem. mosek later eliminates the variables, and is responsible for this side of the optimization. Hell knows how cvx does a better job at it than mosek.

Johan Löfberg

unread,
Jun 8, 2014, 3:46:45 AM6/8/14
to yal...@googlegroups.com
Surely a fair comparison. CVX and YALMIP are both modelling layers interfacing, e.g., mosek.

However, it looks like this model is preferably viewed from a dual viewpoint, and cvx automatically switches strategy. YALMIP has a command/option called dualize, but unfortunately it is not supported here (don't know if that is by design or a bug). I'll try to have a look at it.

Erling D. Andersen

unread,
Jun 8, 2014, 8:56:50 AM6/8/14
to yal...@googlegroups.com
If take at look at the log you will see the following in the CVX log. So CVX says:

# Begin

Calling Mosek 7.0.0.75: 237248 variables, 43151 equality constraints
   For improved efficiency, Mosek is solving the dual problem.
------------------------------------------------------------

# End

In other words CVX choose to dualize before solving that makes a hell of a difference in this case.
MOSEK (most likely all other optimizers) does not dualize automatically when deemed worthwhile unless for LPs.




Erling D. Andersen

unread,
Jun 8, 2014, 9:00:19 AM6/8/14
to yal...@googlegroups.com
Btw it would be nice if we could add your problem to CBLIB.

zoharl

unread,
Jun 8, 2014, 1:59:36 PM6/8/14
to yal...@googlegroups.com
Erling,
I sent an email to Ambros, suggesting to add the problem to cblib. I also suggested that It would be convenient if he had a code similar to mosekopt that writes a .cbf from a prob struct (instead of minimizing).

Let's say I have a prob struct for mosekopt. How do I tell mosek to solve for the dual?

Johan,
Speaking of which; in cvx I can get the prob structure that was sent to mosek. Is there a way to get it from yalmip?

Johan Löfberg

unread,
Jun 8, 2014, 2:06:20 PM6/8/14
to yal...@googlegroups.com
Tun on the option savesolverinput when solving and model will be available in the output from solvesdp, or use the option savedebug to save to file mosekdebug, or use the command export to simply export the model without actually calling the solver

Erling D. Andersen

unread,
Jun 10, 2014, 4:57:30 AM6/10/14
to yal...@googlegroups.com
Except for LP you will have to feed the dual problem into MOSEK if you want MOSEK to solve the dual problem. There is no automatic method implemented in MOSEK currently.

zoharl

unread,
Jun 10, 2014, 5:02:27 AM6/10/14
to yal...@googlegroups.com

Maybe I should write one, and then the export option that Johan mentioned could be used.

Erling D. Andersen

unread,
Jun 10, 2014, 5:22:53 AM6/10/14
to yal...@googlegroups.com
Most likely the easiest is to form the dual problem explicitly in Yalmip.

zoharl

unread,
Jun 10, 2014, 5:31:54 AM6/10/14
to yal...@googlegroups.com

I was thinking more along the line of doing something general that would work for everything. I wouldn't want any problem that I have to formulate both in primal and dual to see which one is faster. But since any primal problem can be converted to the canonical structure (for mosekopt), one needs only a function that converts the canonical structure to another canonical structure that represents the dual problem.

More specifically, convert (19.2.1) to (19.2.1.1)

Johan Löfberg

unread,
Jun 11, 2014, 4:11:46 PM6/11/14
to yal...@googlegroups.com
It all of a sudden struck me that things didn't make sense. YALMIP interprets models in a dual setting by default, hence the efficient model should have been sent to Mosek. Looked at the code and all of a sudden I recalled the "temporary copy-paste fix, will be done properly soon" piece of code related to mosek 7 updates (quick hack, wouldn't give an efficient model no matter how you implemented it since it introduced stupid auxiliary variables just to make the book-keeping easy). I am rewriting the whole thing. The code for your case (no SDP/integer) was easily updated, but I still have to do some refactoring , clean-up and testing before declaring it ready for release. Contact me if you want updated code.

tic; [Qres, success] = arap_Linf(Rs, P, Q, dphii, T, anc_id); toc;
Elapsed time is 10.765344 seconds.


Erling D. Andersen

unread,
Jun 12, 2014, 12:22:00 AM6/12/14
to yal...@googlegroups.com
Btw Johan if someone press control C while MOSEK running, then Yalmip does not report a proper error code even though MOSEK does I think. 

zoharl

unread,
Jun 12, 2014, 1:29:57 AM6/12/14
to yal...@googlegroups.com

Interesting; but it's not urgent, since I already cast my (similar problem) problem as dual.

Johan Löfberg

unread,
Jun 12, 2014, 1:47:57 AM6/12/14
to yal...@googlegroups.com
With YALMIP? As I understand my own code, the current version should not be able to send an efficient model to Mosek no matter how you formulate the problem.

Johan Löfberg

unread,
Jun 12, 2014, 1:55:43 AM6/12/14
to yal...@googlegroups.com
OK, will fix

zoharl

unread,
Jun 12, 2014, 2:00:13 AM6/12/14
to yal...@googlegroups.com
Yes, with yalmip. It seems that mosek doesn't need something efficient (and does its own thing), but only the correct primal/dual.

Johan Löfberg

unread,
Jun 12, 2014, 2:31:58 AM6/12/14
to yal...@googlegroups.com
That's odd, considering the weird model YALMIP sends.

zoharl

unread,
Jun 12, 2014, 2:41:50 AM6/12/14
to yal...@googlegroups.com
Here is a small comparison that I did on a similar model:

Johan Löfberg

unread,
Jun 12, 2014, 2:55:30 AM6/12/14
to yal...@googlegroups.com
As you can see, the numbers are huge in YALMIP no matter how you model it. Can you send me the file that gereates those YALMIP models. Would like to see how the fixed code runs

zoharl

unread,
Jun 12, 2014, 3:16:44 AM6/12/14
to yal...@googlegroups.com


I'm not sure which numbers you are looking at. Comparing to cvx, yalmip dual has the same number of nnz after factorization, and I came to realize that the rest is immaterial.


Unrelated; if you have insights on the following:

Johan Löfberg

unread,
Jun 12, 2014, 3:35:30 AM6/12/14
to yal...@googlegroups.com
Thank you. The updated code sets up a problem from your original model which is solved in 2.2s. The old code solved your version of the dual in 3.6s. The new code runs slow on your manually dualized model, which is to be expected as YALMIP interprets everything from a dual perspective, and the dual interpretation of something which is dualized, will not be efficient on this model (it is sort of back to square one)

Warmstarting: Depends on which data is warmstarted. YALMIP has support for warmstarts in nonlinear solvers (and integer solvers), but it is trickier for primal-dual versions since these solvers typically require initial primal/dual/slacks

zoharl

unread,
Jun 12, 2014, 5:11:14 AM6/12/14
to yal...@googlegroups.com

Sounds good, but I'll need to test it on a larger data.

I have a problem with the export. 


I export the dual problem, and run it with mosekopt, but I get MSK_RES_TRM_STALL.

Johan Löfberg

unread,
Jun 12, 2014, 5:16:40 AM6/12/14
to yal...@googlegroups.com
I get that too, but if you look at the diagnostics, it looks pretty fine. Here from my model

24  6.0e-007 6.2e-011 1.0e-009 1.00e+000  -8.782900126e-001 -8.782900115e-001 6.0e-011 2.81  
Interior-point optimizer terminated. Time: 2.81.

Optimizer terminated. Time: 2.89    

Interior-point solution summary
 
Problem status  : PRIMAL_AND_DUAL_FEASIBLE
 
Solution status : NEAR_OPTIMAL
 
Primal.  obj: -8.7829001265e-001  Viol.  con: 5e-007   var: 0e+000   cones: 0e+000
 
Dual.    obj: -8.7829001147e-001  Viol.  con: 0e+000   var: 5e-011   cones: 0e+000

7 digits in the primal-dual objectivedifference  and constraint violations on the order of 10^-7. I don't think you can expect much better on a big model like this

Do you have some larger dataset to test?


Erling D. Andersen

unread,
Jun 12, 2014, 5:18:40 AM6/12/14
to yal...@googlegroups.com
Note when MOSEK says near optimal then the solution may for all practical purposes be good enough. Even if had said optimal the solution would still be an approximated solution (to an approximated problem). 

zoharl

unread,
Jun 12, 2014, 5:49:10 AM6/12/14
to yal...@googlegroups.com
Bigger model:


load it instead of data.mat.
mosek time for yalmip_dual formulation: 21sec, for cvx formulation: 18sec.

------

Right, that's not the problem. I'm using the assign incorrectly. What should I do for x,t in solve_yalmip_dual_export() to have the same values as in solve_yalmip_dual()?

zoharl

unread,
Jun 12, 2014, 5:50:47 AM6/12/14
to yal...@googlegroups.com

Ho, and in yalmip2mosek.m change line 61 from

    prob.a = [prob.a [zeros(K.f,nof_new);zeros(K.l,nof_new);eye(nof_new)]];

to

    prob.a = [prob.a [sparse(K.f,nof_new);sparse(K.l,nof_new);speye(nof_new)]];

Johan Löfberg

unread,
Jun 12, 2014, 6:43:25 AM6/12/14
to yal...@googlegroups.com
That's weird, when I run solve_yalmip_dual(n, m, bt, kl, Ceq, deq, Cineq), using the old version which thus should be the same as you use, mosek takes 180 secs of which 140 is spent in presolve. Can you show me the complete log from that one. I do have very little memory, which could be an issue here. The numbers match for the smaller data set.






Johan Löfberg

unread,
Jun 12, 2014, 6:44:52 AM6/12/14
to yal...@googlegroups.com
Yes, I noticed that. You should also delete the line

prob.a(1+K.f+K.l:end,1:length(c)) = prob.a(1+K.f+K.l:end,1:length(c));

which must be some old debug experiment, taking loads of time on my machine.

zoharl

unread,
Jun 12, 2014, 6:55:19 AM6/12/14
to yal...@googlegroups.com
finished init
Elapsed time is 1.650960 seconds.
+ Solver chosen : MOSEK-SDP
+ Processing objective h(x)
+ Processing F(x)
+ Calling MOSEK


MOSEK
Version 7.0.0.75 (Build date: 2013-7-1 14:54:58)
Copyright (c) 1998-2013 MOSEK ApS, Denmark. WWW: http://mosek.com


Computer
 
Platform               : Windows/64-X86  
 
Cores                  : 4              


Problem
 
Name                   :                
 
Objective sense        : min            
 
Type                   : CONIC (conic optimization problem)
 
Constraints            : 630061          
 
Cones                  : 104358          
 
Scalar variables       : 1047492        
 
Matrix variables       : 0              
 
Integer variables      : 0              


Optimizer started.
Conic interior-point optimizer started.
Presolve started.
Linear dependency checker started.
Linear dependency checker terminated.
Eliminator started.
Total number of eliminations : 3716
Eliminator terminated.
Eliminator started.
Total number of eliminations : 3717
Eliminator terminated.
Eliminator - tries                  : 2                 time                   : 0.00            
Eliminator - elim's                 : 3717            
Lin. dep.  - tries                  : 1                 time                   : 0.67            
Lin. dep.  - number                 : 0              
Presolve terminated. Time: 1.97    
GP based matrix reordering started.
GP based matrix reordering terminated.
Optimizer  - threads                : 4              
Optimizer  - solved problem         : the primal      
Optimizer  - Constraints            : 104554
Optimizer  - Cones                  : 104358
Optimizer  - Scalar variables       : 521986            conic                  : 521790          
Optimizer  - Semi-definite variables: 0                 scalarized             : 0              
Factor     - setup time             : 5.63              dense det. time        : 1.66            
Factor     - ML order time          : 0.14              GP order time          : 2.81            
Factor     - nonzeros before factor : 9.25e+005         after factor           : 6.41e+006      
Factor     - dense dim.             : 1                 flops                  : 1.31e+009      
Factor     - GP saved nzs           : 1.16e+006         GP saved flops         : 8.58e+008      
ITE PFEAS    DFEAS    GFEAS    PRSTATUS   POBJ              DOBJ              MU       TIME  
0   1.0e+005 1.0e+000 1.0e+000 0.00e+000  0.000000000e+000  0.000000000e+000  1.0e+000 7.86  
1   5.3e+003 5.1e-002 5.1e-002 -9.99e-001 -3.687447512e+001 -1.844433904e+001 5.1e-002 8.42  
2   3.5e+002 3.3e-003 3.3e-003 -7.95e-001 -1.402945955e+002 -8.070119303e+001 3.3e-003 8.89  
3   1.6e+002 1.6e-003 1.6e-003 2.71e+000  -3.658494938e+001 -3.533229551e+001 1.6e-003 9.36  
4   1.1e+002 1.0e-003 1.0e-003 5.80e+000  -1.258195797e+001 -1.174873587e+001 1.0e-003 9.81  
5   2.0e+001 1.9e-004 1.9e-004 3.18e+000  -3.950322890e+000 -3.908683055e+000 1.9e-004 10.27
6   1.4e+001 1.4e-004 1.4e-004 4.79e+000  -1.909798765e+000 -1.882751319e+000 1.4e-004 10.75
7   1.0e+001 9.7e-005 9.7e-005 2.97e+000  -1.239889734e+000 -1.225816415e+000 9.7e-005 11.23
8   7.0e+000 6.7e-005 6.7e-005 2.25e+000  -9.445874766e-001 -9.370848004e-001 6.7e-005 11.70
9   5.0e+000 4.8e-005 4.8e-005 1.79e+000  -8.251338215e-001 -8.205109374e-001 4.8e-005 12.19
10  2.9e+000 2.8e-005 2.8e-005 1.47e+000  -7.577202960e-001 -7.552773175e-001 2.8e-005 12.66
11  1.4e+000 1.3e-005 1.3e-005 1.18e+000  -7.373004139e-001 -7.363431170e-001 1.3e-005 13.13
12  5.9e-001 5.7e-006 5.7e-006 1.07e+000  -7.251031644e-001 -7.247424808e-001 5.7e-006 13.61
13  2.6e-001 2.5e-006 2.5e-006 1.02e+000  -7.205099114e-001 -7.203771484e-001 2.5e-006 14.09
14  1.1e-001 1.1e-006 1.1e-006 1.01e+000  -7.187494922e-001 -7.186985924e-001 1.1e-006 14.56
15  4.4e-002 4.2e-007 4.2e-007 1.00e+000  -7.180203201e-001 -7.180034067e-001 4.2e-007 15.03
16  2.0e-002 1.9e-007 1.9e-007 1.00e+000  -7.177960491e-001 -7.177896829e-001 1.9e-007 15.53
17  1.0e-002 9.7e-008 9.7e-008 1.00e+000  -7.177162770e-001 -7.177134632e-001 9.7e-008 16.02
18  4.8e-003 4.6e-008 4.6e-008 1.00e+000  -7.176759040e-001 -7.176748063e-001 4.6e-008 16.47
19  2.5e-003 2.4e-008 2.4e-008 1.00e+000  -7.176602821e-001 -7.176597440e-001 2.4e-008 16.94
20  9.8e-004 9.4e-009 9.4e-009 1.00e+000  -7.176500354e-001 -7.176498695e-001 9.4e-009 17.39
21  5.7e-004 5.5e-009 5.5e-009 1.00e+000  -7.176475422e-001 -7.176474510e-001 5.5e-009 17.86
22  2.3e-004 2.2e-009 2.2e-009 1.00e+000  -7.176454554e-001 -7.176454248e-001 2.2e-009 18.33
23  1.0e-004 9.7e-010 1.0e-009 1.00e+000  -7.176446758e-001 -7.176446649e-001 9.7e-010 18.80
24  5.2e-005 5.0e-010 6.0e-010 1.00e+000  -7.176444002e-001 -7.176443957e-001 4.9e-010 19.28
25  2.3e-005 2.3e-010 4.4e-011 1.00e+000  -7.176442517e-001 -7.176442498e-001 2.2e-010 19.98
26  7.9e-006 7.6e-011 9.4e-010 1.00e+000  -7.176441717e-001 -7.176441706e-001 7.5e-011 20.47
27  2.0e-006 2.0e-011 6.5e-010 1.00e+000  -7.176441430e-001 -7.176441425e-001 1.9e-011 20.98
28  6.8e-007 8.3e-012 2.4e-009 1.00e+000  -7.176441347e-001 -7.176441364e-001 6.4e-012 21.45
29  2.7e-007 3.5e-012 1.8e-008 1.00e+000  -7.176441476e-001 -7.176441346e-001 2.5e-012 22.19
30  2.7e-007 3.5e-012 1.8e-008 1.00e+000  -7.176441476e-001 -7.176441346e-001 2.5e-012 22.97
Interior-point optimizer terminated. Time: 22.97.


Optimizer terminated. Time: 23.45  


Interior-point solution summary
  Problem status  : PRIMAL_AND_DUAL_FEASIBLE
  Solution status : NEAR_OPTIMAL
  Primal.  obj: -7.1764414764e-001  Viol.  con: 6e-006   var: 0e+000   cones: 0e+000
  Dual.    obj: -7.1764413460e-001  Viol.  con: 0e+000   var: 3e-012   cones: 0e+000
Optimizer summary
  Optimizer                 -                        time: 23.45  
    Interior-point          - iterations : 30        time: 22.97  
      Basis identification  -                        time: 0.00    
        Primal              - iterations : 0         time: 0.00    
        Dual                - iterations : 0         time: 0.00    
        Clean primal        - iterations : 0         time: 0.00    
        Clean dual          - iterations : 0         time: 0.00    
        Clean primal-dual   - iterations : 0         time: 0.00    
    Simplex                 -                        time: 0.00    
      Primal simplex        - iterations : 0         time: 0.00    
      Dual simplex          - iterations : 0         time: 0.00    
      Primal-dual simplex   - iterations : 0         time: 0.00    
    Mixed integer           - relaxations: 0         time: 0.00    


Mosek error: MSK_RES_TRM_STALL ()
>>

Johan Löfberg

unread,
Jun 12, 2014, 7:27:41 AM6/12/14
to yal...@googlegroups.com

Problem
 
Name                   :                
 
Objective sense        : min            
 
Type                   : CONIC (conic optimization problem)
 
Constraints            : 630061          
 
Cones                  : 104358          
 
Scalar variables       : 1047492        
 
Matrix variables       : 0              
 
Integer variables      : 0              

Optimizer started.
Conic interior-point optimizer started.
Presolve started.
Linear dependency checker started.
Linear dependency checker terminated.
Eliminator started.
Total number of eliminations : 108073
Eliminator terminated.
Eliminator started.
Total number of eliminations : 108074

Eliminator terminated.
Eliminator - tries                  : 2                 time                   : 0.00            
Eliminator - elim's                 : 108074          
Lin. dep.  - tries                  : 1                 time                   : 1.29            

Lin. dep.  - number                 : 0              
Presolve terminated. Time: 118.08  

The model looks to be the same, but the presolve is very slow here (and eliminates a lot more). I am running a later version of Mosek than you (april 2014) so maybe we have found a regression here

Can you please run the extracted data on your machine to make sure we are running the same data

https://dl.dropboxusercontent.com/u/58143974/mosekdebug.mat

load mosekdebug
[res,sol] = mosekopt('minimize info',prob,param);


zoharl

unread,
Jun 12, 2014, 7:32:37 AM6/12/14
to yal...@googlegroups.com
>> cd \8

>> load mosekdebug
[res,sol] = mosekopt('minimize info',prob,param);



MOSEK
Version 7.0.0.75 (Build date: 2013-7-1 14:54:58)

Copyright (c) 1998-2013 MOSEK ApS, Denmark. WWW: http://mosek.com


Computer
 
Platform               : Windows/64-X86  
 
Cores                  : 4              


Problem
 
Name                   :                
 
Objective sense        : min            
 
Type                   : CONIC (conic optimization problem)
 
Constraints            : 630061          
 
Cones                  : 104358          
 
Scalar variables       : 1047492        
 
Matrix variables       : 0              
 
Integer variables      : 0              


Optimizer started.
Conic interior-point optimizer started.
Presolve started.
Linear dependency checker started.
Linear dependency checker terminated.
Eliminator started.
Total number of eliminations : 3716
Eliminator terminated.
Eliminator started.
Total number of eliminations : 3717

Eliminator terminated.
Eliminator - tries                  : 2                 time                   : 0.00            
Eliminator - elim's                 : 3717            
Lin. dep.  - tries                  : 1                 time                   : 0.69            

Lin. dep.  - number                 : 0              
Presolve terminated. Time: 2.03    

GP based matrix reordering started.
GP based matrix reordering terminated.
Optimizer  - threads                : 4              
Optimizer  - solved problem         : the primal      
Optimizer  - Constraints            : 104554
Optimizer  - Cones                  : 104358
Optimizer  - Scalar variables       : 521986            conic                  : 521790          
Optimizer  - Semi-definite variables: 0                 scalarized             : 0              
Factor     - setup time             : 5.64              dense det. time        : 1.73            
Factor     - ML order time          : 0.16              GP order time          : 2.78            

Factor     - nonzeros before factor : 9.25e+005         after factor           : 6.41e+006      
Factor     - dense dim.             : 1                 flops                  : 1.31e+009      
Factor     - GP saved nzs           : 1.16e+006         GP saved flops         : 8.58e+008      
ITE PFEAS    DFEAS    GFEAS    PRSTATUS   POBJ              DOBJ              MU       TIME  
0   1.0e+005 1.0e+000 1.0e+000 0.00e+000  0.000000000e+000  0.000000000e+000  1.0e+000 7.94  
1   5.3e+003 5.1e-002 5.1e-002 -9.99e-001 -3.687447512e+001 -1.844433904e+001 5.1e-002 8.59  
2   3.5e+002 3.3e-003 3.3e-003 -7.95e-001 -1.402945955e+002 -8.070119303e+001 3.3e-003 9.06  
3   1.6e+002 1.6e-003 1.6e-003 2.71e+000  -3.658494938e+001 -3.533229551e+001 1.6e-003 9.50  
4   1.1e+002 1.0e-003 1.0e-003 5.80e+000  -1.258195797e+001 -1.174873587e+001 1.0e-003 9.94  
5   2.0e+001 1.9e-004 1.9e-004 3.18e+000  -3.950322890e+000 -3.908683055e+000 1.9e-004 10.38
6   1.4e+001 1.4e-004 1.4e-004 4.79e+000  -1.909798765e+000 -1.882751319e+000 1.4e-004 10.83
7   1.0e+001 9.7e-005 9.7e-005 2.97e+000  -1.239889734e+000 -1.225816415e+000 9.7e-005 11.27
8   7.0e+000 6.7e-005 6.7e-005 2.25e+000  -9.445874766e-001 -9.370848004e-001 6.7e-005 11.72
9   5.0e+000 4.8e-005 4.8e-005 1.79e+000  -8.251338215e-001 -8.205109374e-001 4.8e-005 12.19
10  2.9e+000 2.8e-005 2.8e-005 1.47e+000  -7.577202960e-001 -7.552773175e-001 2.8e-005 12.64
11  1.4e+000 1.3e-005 1.3e-005 1.18e+000  -7.373004139e-001 -7.363431170e-001 1.3e-005 13.09
12  5.9e-001 5.7e-006 5.7e-006 1.07e+000  -7.251031644e-001 -7.247424808e-001 5.7e-006 13.58
13  2.6e-001 2.5e-006 2.5e-006 1.02e+000  -7.205099114e-001 -7.203771484e-001 2.5e-006 14.03
14  1.1e-001 1.1e-006 1.1e-006 1.01e+000  -7.187494922e-001 -7.186985924e-001 1.1e-006 14.47
15  4.4e-002 4.2e-007 4.2e-007 1.00e+000  -7.180203201e-001 -7.180034067e-001 4.2e-007 14.91
16  2.0e-002 1.9e-007 1.9e-007 1.00e+000  -7.177960491e-001 -7.177896829e-001 1.9e-007 15.34
17  1.0e-002 9.7e-008 9.7e-008 1.00e+000  -7.177162770e-001 -7.177134632e-001 9.7e-008 15.80
18  4.8e-003 4.6e-008 4.6e-008 1.00e+000  -7.176759040e-001 -7.176748063e-001 4.6e-008 16.23
19  2.5e-003 2.4e-008 2.4e-008 1.00e+000  -7.176602821e-001 -7.176597440e-001 2.4e-008 16.67
20  9.8e-004 9.4e-009 9.4e-009 1.00e+000  -7.176500354e-001 -7.176498695e-001 9.4e-009 17.11
21  5.7e-004 5.5e-009 5.5e-009 1.00e+000  -7.176475422e-001 -7.176474510e-001 5.5e-009 17.55
22  2.3e-004 2.2e-009 2.2e-009 1.00e+000  -7.176454554e-001 -7.176454248e-001 2.2e-009 17.98
23  1.0e-004 9.7e-010 1.0e-009 1.00e+000  -7.176446758e-001 -7.176446649e-001 9.7e-010 18.44
24  5.2e-005 5.0e-010 6.0e-010 1.00e+000  -7.176444002e-001 -7.176443957e-001 4.9e-010 18.89
25  2.3e-005 2.3e-010 4.4e-011 1.00e+000  -7.176442517e-001 -7.176442498e-001 2.2e-010 19.56
26  7.9e-006 7.6e-011 9.4e-010 1.00e+000  -7.176441717e-001 -7.176441706e-001 7.5e-011 20.03
27  2.0e-006 2.0e-011 6.5e-010 1.00e+000  -7.176441430e-001 -7.176441425e-001 1.9e-011 20.47
28  6.8e-007 8.3e-012 2.4e-009 1.00e+000  -7.176441347e-001 -7.176441364e-001 6.4e-012 20.91
29  2.7e-007 3.5e-012 1.8e-008 1.00e+000  -7.176441476e-001 -7.176441346e-001 2.5e-012 21.56
30  2.7e-007 3.5e-012 1.8e-008 1.00e+000  -7.176441476e-001 -7.176441346e-001 2.5e-012 22.31
Interior-point optimizer terminated. Time: 22.31.


Optimizer terminated. Time: 22.91  


Interior-point solution summary
  Problem status  : PRIMAL_AND_DUAL_FEASIBLE
  Solution status : NEAR_OPTIMAL
  Primal.  obj: -7.1764414764e-001  Viol.  con: 6e-006   var: 0e+000   cones: 0e+000
  Dual.    obj: -7.1764413460e-001  Viol.  con: 0e+000   var: 3e-012   cones: 0e+000
Optimizer summary
  Optimizer                 -                        time: 22.91  
    Interior-point          - iterations : 30        time: 22.31  

Erling D. Andersen

unread,
Jun 12, 2014, 7:34:01 AM6/12/14
to yal...@googlegroups.com
If presolve has gotten much slower. Then feel free to submit a compressed task file to


and I will take a look at it.

I did not somthing in the presolve some time ago. There might have been an unfortunate side effect.

Johan Löfberg

unread,
Jun 12, 2014, 7:47:24 AM6/12/14
to yal...@googlegroups.com
Sent the data (matlab and taskfile).

Erling D. Andersen

unread,
Jun 13, 2014, 4:38:49 AM6/13/14
to yal...@googlegroups.com
The slow is caused by fix for another problem. I hope to have an even better fix now but it has to be tested. So maybe next week I will have something for you.

Erling D. Andersen

unread,
Jun 23, 2014, 1:24:54 AM6/23/14
to yal...@googlegroups.com
The latest version 7.0.0.121 should solve the performance issue. Feel free to try it out.
Reply all
Reply to author
Forward
0 new messages