Skip to main content

Warm start for QCQP

Answered
Xiaoqian Liu
  • Gurobi-versary
  • First Comment
  • First Question

Hi all,

I am using gurobi in R to solve a QCQP problem where the quadratic constraint is dependent on a tuning parameter lambda (e.g. ||Ax||_2 \leq \lambda) in my statistical model. My goal is to get a solution path of the model, namely a solution path with a grid of values for lambda. Therefore, I would like to warm start the computation of the solution at the current lambda value using the solution at the previous one. However, I did not find a good way to do so. 

Besides, I also want to control the maximal #iterations and tolerance for possible earlier stop by the following command

params <- list(OutputFlag=0, BarIterLimit = maxiters, BarQCPConvTol= tol)

However, it seems not helpful. No matter how I change maxiters and tol, the required computation time does not change a lot. 

Anyone can help with either of my questions? Thanks so much!

0

Comments

4 comments

Date Votes
  • Official comment
    Simranjit Kaur
    • Gurobi Staff
    This post is more than three years old. Some information may not be up to date. For current information, please check the Gurobi Documentation or Knowledge Base. If you need more help, please create a new post in the community forum, or try Gurobot, our chatbot interface offering instant, expert-level support.
  • Jaromił Najman
    • Gurobi Staff

    Hi,

    Therefore, I would like to warm start the computation of the solution at the current lambda value using the solution at the previous one. However, I did not find a good way to do so. 

    It is not possible to warm start the Barrier algorithm in Gurobi. This is because there is currently no efficient way of exploiting warm start information for Barrier initialization.

    Besides, I also want to control the maximal #iterations and tolerance for possible earlier stop by the following command

    params <- list(OutputFlag=0, BarIterLimit = maxiters, BarQCPConvTol= tol)

    However, it seems not helpful. No matter how I change maxiters and tol, the required computation time does not change a lot. 

    Could you share a log output where you solve your model without setting the BarIterLimit parameter and a log output where you set the parameter to some small value?

    Best regards, 
    Jaromił

    0
  • Xiaoqian Liu
    • Gurobi-versary
    • First Comment
    • First Question

    Hi Jaromił,

    Thanks for the response. Here are the outputs I got with different values for BarIterLimit. The BarQCQPConvTol parameter is set to be 1e-10 for all cases.

    1. Without setting the BarIterLimit parameter

    $status
    [1] "OPTIMAL"

    $runtime
    [1] 0.0019629

    $itercount
    [1] 0

    $baritercount
    [1] 27

    $nodecount
    [1] 0

    $objval
    [1] -181.5931

    $x
     [1] 10.53240684  9.65878473 -0.73693624 -0.40558278 -0.19458163 -0.60013689 -0.41702083 -1.63682124 -5.60395157
    [10]  0.36020273  1.41093370  1.72865614 -0.09471539 -1.13235567 -0.09626055  0.05269683 -1.26505940 -0.43213482
    [19] -1.34657324  0.34263004 10.53420409  9.70542950  0.68421471  5.83810389

    $slack
    [1] 0

    $qcslack
    [1] 4.422418e-11 6.195933e-12 1.462719e-13 4.618528e-13 1.010182e-12 3.085978e-13 3.628556e-12 1.642908e-12

     

    2. BarIterLimit = 100

    $status
    [1] "OPTIMAL"

    $runtime
    [1] 0.002022028

    $itercount
    [1] 0

    $baritercount
    [1] 27

    $nodecount
    [1] 0

    $objval
    [1] -181.5931

    $x
     [1] 10.53240684  9.65878473 -0.73693624 -0.40558278 -0.19458163 -0.60013689 -0.41702083 -1.63682124 -5.60395157
    [10]  0.36020273  1.41093370  1.72865614 -0.09471539 -1.13235567 -0.09626055  0.05269683 -1.26505940 -0.43213482
    [19] -1.34657324  0.34263004 10.53420409  9.70542950  0.68421471  5.83810389

    $slack
    [1] 0

    $qcslack
    [1] 4.422418e-11 6.195933e-12 1.462719e-13 4.618528e-13 1.010182e-12 3.085978e-13 3.628556e-12 1.642908e-12

     

    3. BarIterLimit = 10

    $status
    [1] "ITERATION_LIMIT"

    $runtime
    [1] 0.00112915

    $itercount
    [1] 0

    $baritercount
    [1] 10

    $nodecount
    [1] 0

     

    It seems that it only needs 27 iterations to get the optimal solution, but when I set BarIterLimit to be 10, the results look invalid. My goal here is to early stop the algorithm to get an approximate solution and to save some computation time. Thanks very much for your help.

    Best,

    Xiaoqian

    0
  • Jaromił Najman
    • Gurobi Staff

    HI Xiaoqian,

    It seems that it only needs 27 iterations to get the optimal solution, but when I set BarIterLimit to be 10, the results look invalid. 

    It is correct that the Barrier algorithm requires 27 iterations to solve your model. This is the reason why setting BarIterLimit=100 does not have any effect. Setting BarIterLimit=10 terminates the Barrier algorithm early. This is the reason why you don't get any valid solution. It is necessary that the Barrier algorithm runs until it converges to a solution point satisfying given tolerances.

    Since the runtime of the algorithm is already only  0.002022028 seconds, I don't think that you can squeeze much more out of it without worsening solution quality in the end.

    Best regards, 
    Jaromił

    0

Post is closed for comments.

Didn't find what you were looking for?

New post