Why does adding a linear constraint to my existing second-order cone model result in a message that the Q matrix is not semi-positive definite?
OngoingDear Support Team,
I hope this message finds you well. I am writing to seek assistance with an issue I've encountered while running an optimization problem using Gurobi for Python.
When I run a model that includes the following second-order cone constraints, the model is convex and can be solved directly.
model.addConstr(s_reserve[:,0:1]*s_reserve[:,0:1]<=risk_reserve[:,0:1]*(risk_reserve[:,0:1]+4/9*np.ones((TEST_HOUR,1))))
model.addConstr(s_reserve[:,1:2]*s_reserve[:,1:2]<=risk_reserve[:,1:2]*(risk_reserve[:,1:2]+4/9*np.ones((TEST_HOUR,1))))
model.addConstr(4/9*np.ones((TEST_HOUR,1)) <= r_reserve[:,0:1]*s_reserve[:,0:1])
model.addConstr(4/9*np.ones((TEST_HOUR,1)) <= r_reserve[:,1:2]*s_reserve[:,1:2])
But what puzzles me is that when I add some linear constraints it tells me that the Q matrix is not positive semidefinite, but I only add some linear constraints and I don't add any quadratic constraints. Why is that? When I run the following code (which only adds linear constraints relative to the previous code), it tells me that the Q matrix is not positive semi-definite:
gurobipy.GurobiError: Q matrix is not positive semi-definite (PSD). Set NonConvex parameter to 2 to solve model.
for t in range(TEST_HOUR):
model.addConstr((risk_reserve[t,0] + risk_reserve[t,1]) <= 0.05,name="attention_R")
model.addConstr((risk_V[t,:,0] + risk_V[t,:,1]).sum() <= 0.05,name="attention_V")
model.addConstr(s_reserve[:,0:1]*s_reserve[:,0:1]<=risk_reserve[:,0:1]*(risk_reserve[:,0:1]+4/9*np.ones((TEST_HOUR,1))))
model.addConstr(s_reserve[:,1:2]*s_reserve[:,1:2]<=risk_reserve[:,1:2]*(risk_reserve[:,1:2]+4/9*np.ones((TEST_HOUR,1))))
model.addConstr(4/9*np.ones((TEST_HOUR,1)) <= r_reserve[:,0:1]*s_reserve[:,0:1])
model.addConstr(4/9*np.ones((TEST_HOUR,1)) <= r_reserve[:,1:2]*s_reserve[:,1:2])
-
Hi Jie,
This sounds strange. Could you please share the two models so I could investigate? You can generate an MPS or an LP file of the models via the write method. Note that uploading files in the Community Forum is not possible but we discuss an alternative in Posting to the Community Forum.
Best regards,
Jaromił-1 -
Thank you very much for your reply, I have put the LP files for the feasible and infeasible models into the onetrive link below. The difference between the two is the linear constraints shown in lines 67595 through 69146.
0 -
Thank you for sharing the files. The issue with turning the model nonconvex through addition of linear constraint is a bug and will be resolved in the upcoming release version 11.
Independent of the bug, the model is numerically problematic. It would be best if you compute an IIS via
./gurobi_cl resultfile=iis.ilp NonConvex=2 infeasible_model.lp
and investigate the IIS computed by Gurobi to find the reason of the infeasibility. It might be that some of the coefficients are not accurate enough and add up to bigger violations through aggregation or similar. It is possible that scaling is the solution here. Please refer to our Guidelines for Numerical Issues for more information.
For additional information about IIS please refer to
- How does Gurobi compute the IIS for infeasible models?
- computeIIS method
- How do I determine why my model is infeasible?
Best regards,
Jaromił0 -
Thank you very much for your reply. I realize that the linear constraint I added may cause the model to not have a feasible solution, and the coefficients of this constraint are parameters that I am debugging. Based on your reply, does this mean that even if I relax some of the constraints so that the model has a feasible solution, for now I still need to add model.Params.NonConvex = 2 to the code to solve the problem, but this will be very time consuming. Does this mean I need to wait until this bug is fixed before I can use python and gurobi to solve the model properly?
0 -
does this mean that even if I relax some of the constraints so that the model has a feasible solution, for now I still need to add model.Params.NonConvex = 2 to the code to solve the problem, but this will be very time consuming.
The bug is very subtle and rare. It is caused by problematic numerics so I would guess that already a slight change in coefficients might lead to correct detection of convexity again. For now you can just keep the NonConvex=2 parameter just in case. The model might not need long to solve even if it is not recognized to be convex.
Does this mean I need to wait until this bug is fixed before I can use python and gurobi to solve the model properly?
No, you don't have to wait, see above.
Best regards,
Jaromił0 -
Thank you very much for your answer. However, after I changed some parameters in the model (see Onetrive link below), the problem of the Q matrix not being a semi-positive definite matrix persists. If I keep the setting of NonConvex=2, the solving time on my personal laptop (CPU model: Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz, instruction set [SSE2|AVX|AVX2], Thread count: 8 physical cores, 16 logical processors, using up to 16 threads) will be more than 600 seconds, which is beyond my acceptable solving time.
0
Please sign in to leave a comment.
Comments
6 comments