Warm start for QCQP
回答済み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!
-
正式なコメント
-
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. -
-
-
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 -
-
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-122. 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-123. BarIterLimit = 10
$status
[1] "ITERATION_LIMIT"$runtime
[1] 0.00112915$itercount
[1] 0$baritercount
[1] 10$nodecount
[1] 0It 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 -
-
-
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 -
投稿コメントは受け付けていません。
コメント
4件のコメント