Getting the number of iterations/ fixing the number of iterations

[convex_optimization]

Hello, I am  using Yalmip to solve an optimization problem.

I need the following:

a-) to determine the number of iterations in getting an optimal solution.

b-) to fix the number of iterations in an optimization.


I do not know how I can do these using Yalmip functions.

I will extremely be happy for some help.

Regards,

[Johan Löfberg]

1. You will have to use the option savesolveroutput, and then hope that the solver returns this information. All solver output is caught in the output structure from optimize

2. If the solver supports it, you'll have to find it in the options list for the solver and tune it as always using sdpsettings

[convex_optimization]

Dear Johan,
I did as you suggested through the following code but next it is not clear how to get the number of iterations in solving an optimization problem.


>> Solver='cplex';
>> ops=sdpsettings('solver',Solver, 'savesolveroutput',2, 'verbose',0, 'debug',1);
>> ops.cplex

ans =

             advance: 1
             barrier: [1x1 struct]
           clocktype: 2
            conflict: [1x1 struct]
             cpumask: 'auto'
        dettimelimit: 1.0000e+75
             distmip: [1x1 struct]
            emphasis: [1x1 struct]
             feasopt: [1x1 struct]
            lpmethod: 0
                 mip: [1x1 struct]
             network: [1x1 struct]
    optimalitytarget: 0
              output: [1x1 struct]
            parallel: 0
       preprocessing: [1x1 struct]
            qpmethod: 0
          randomseed: 201509044
                read: [1x1 struct]
             sifting: [1x1 struct]
             simplex: [1x1 struct]
        solutiontype: 0
      solutiontarget: 0
             threads: 0
           timelimit: 1.0000e+75
                tune: [1x1 struct]
             workdir: '.'
             workmem: 2048
             display: 'off'
         exportmodel: ''

[Johan Löfberg]

>> sdpvar x

>> ops = sdpsettings('solver','cplex','savesolveroutput',1);

>> sol = optimize(x>=0,x,ops);

>> sol.solveroutput.output

ans = 

          cplexstatus: 1

    cplexstatusstring: 'optimal'

           iterations: 0

            algorithm: 2

                 time: 0.0160

              message: 'Function converged to a solution x.'

[convex_optimization]

Dear Johan,
in my problem at hand I  am using optimizer:

       ops=sdpsettings('solver',Solver, 'savesolveroutput',1, 'verbose',0, 'debug',1);
       mpc_c = optimizer(con,obj,ops,{x_0,u_km1_var,y_lb_var,y_ub_var,y_k_var,v_val_new_var},{eta_n cv_Np });

      [sol, error_code_Np] = mpc_c{{x_k, u_km1, y_lb(k), y_ub(k), y_k, v_val_new(:,k:k+Np)}};

In this case, still it is not obvious how to get the number of iterations.
     

[convex_optimization]

sol.solveroutput.output  does not work for the optimizer case.

[Johan Löfberg]

[val,err,~,~,~,sol]=

[convex_optimization]

it did not work:

Error in optimizer.subsref (line 3)
if isequal(subs.type,'()')

Output argument "varargout{6}" (and maybe others) not assigned during call
to "C:\yalmip\extras\@optimizer\subsref.m>subsref".

Error in fmpc_LN_new (line 130)
  [sol, error_code_Np, ~, ~, ~, info] = mpc_c{{x_k, u_km1, y_lb(k),

[Johan Löfberg]

Old version of YALMIP?

[convex_optimization]

It works with the new version of Yalmip.
But I have  the strange result that the number of iterations are zero in all receding horizon mpc optimizations:

cplexstatus: 1
    cplexstatusstring: 'optimal'
           iterations: 0

            algorithm: 4
                 time: 0

              message: 'Function converged to a solution x.'

What doe this mean?

[Johan Löfberg]

I guess cplex returns the number of leaf nodes solved for an integer problem, and as you don't have any integer variables, it solved in the root node and hence no b&b iterations

[convex_optimization]

What can I do to show the number of iterations in case solver is cplex?
 You are right. When  I changed  the solver to quadprog it shows the number of iterations as shown below but I do not like quadprog since it is not an accurate solver.

  message: 'Minimum found that satisfies the constraints....'
          algorithm: 'interior-point-convex'
      firstorderopt: 1.9262e-07
    constrviolation: 0
         iterations: 18
       cgiterations: []

[Johan Löfberg]

Why are you interested in that number anyway? It is a completely redundant number for any practical purpose

[convex_optimization]

I am writing a paper about Laguerre functions-based MPC and comparing its computational speed with classical MPC.
I see that in Laguerre-based MPC sometimes the computational speed is worse than classical MPC although the number
of decision variables in Laguerre-based MPC is considerably less.
My guess is that in such cases the number of iterations should be higher. Hence, I need to
record the number of iterations.
By the way,  I do not know how to thank you for your feedback on this platform.  This feedback will definitely
be acknowledged in the paper.

[Johan Löfberg]

The number of iterations feels completely irrelevant. What if algo A is twice as large but uses 1/10 iterations, but every iteration is twice as slow as the problem is 5 times as dense. What if changing presolve method 23 from on to off makes the problem 100 times faster

The only relevant measure is the time it takes to solve the problem. The number of iterations can be influenced by almost anything (selected solution algorithm, #variables, # constraints, presolvability, structure, sparsity, dumb luck)

The only time you would want to compare the number of active-set iterations is when you are doing research on active-set methods and by some way have total control over cplex, and want to see the effect from some kind of algorithmic improvement

If you absolutely want to know the number of iterations, you will have to manually look at the displayed output

[convex_optimization]

I totally agree with your explanations.
In my case, I will use the same solver and classical MPC is a special case of Laguerre function-based MPC.
I just wanted to record the number of iterations and of course this number is not the only reason for being slow as you said.
Thank you again.

[Johan Löfberg]

My guess: With a basis for the input, the problem becomes less sparse, destroying sparsity and structure leading to slower linear algebra and possibly worse iteration complexity.

[Ting Liang]

Hi, Johan,

excuse me.

As for the iterations number, it worked for me by using the method you mentioned before. Thanks.

But there is another problem, as I would like to get the objectives corresponding to each iteration, to see how the objectives evolving with iterations(from the initial value to the optimal value).

I tried this method, but result was apparently incorrect, as the objective should be minimized.

objective = objective + Cap_cost + Pr_f_win* (x(1,t)+ x(2,t))* T_win * dt....

sol = optimize(constraints,objective,ops);

Objective = [Objective, value(objective)];

and finally, i got the results like these, which were increasing, so could you please help with this problem? Thanks a lot.

6780588.08219302 6860588.08219302 6860588.08219302 6860588.08219302 6860588.08219302 6860588.08219302 6935059.13300596 7010144.51150635 7100588.08219302 7100588.08219302 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022 11092102.7604022

Best regards

Ting, Liang

[Johan Löfberg]

I have no idea what your question is

[Ting Liang]

sorry, I will try to describe it further, actually, I would like to get a picture shown as the attachment.

so, how can the objectives at each iteration be extracted?

Thanks.

[Johan Löfberg]

The iterations inside a solver like gurobi? That is what is displayed when you turn on display, but to catch the data I have no idea. You will have to look in the solver reference material to see if there is any way, and then perhaps use https://yalmip.github.io/Extracting

[Ting Liang]

okay, I will try to find more information, thanks a lot.