gurobipy.GurobiError: Empty general constraint with infinite constant
AnsweredI am trying to optimize the model below, but I get the following traceback:
Read LP format model from file tmp.lp
Reading time = 0.00 seconds
: 28 rows, 10 columns, 105 nonzeros
Optimize a model with 28 rows, 10 columns and 105 nonzeros
Model has 4 general constraints
Variable types: 10 continuous, 0 integer (0 binary)
Coefficient statistics:
Matrix range [8e-04, 1e+00]
Objective range [1e+00, 1e+00]
Bounds range [1e-01, 1e+00]
RHS range [1e+00, 1e+00]
Presolve removed 26 rows and 2 columns
Presolve time: 0.00s
Explored 0 nodes (0 simplex iterations) in 0.00 seconds
Thread count was 1 (of 8 available processors)
Solution count 0
Best objective -, best bound -, gap -
Traceback (most recent call last):
File "tmp.py", line 4, in <module>
model.optimize()
File "model.pxi", line 727, in gurobipy.Model.optimize
gurobipy.GurobiError: Empty general constraint with infinite constant
I searched for a solution online but I couldn't find any information on this error message. Can you tell me why this happens and how to fix this problem?
\ LP format - for model browsing. Use MPS format to capture full model detail.
Maximize
pixel - neighbor
Subject To
flow_diff_x_lb: pixel_v_x - neighbor_v_x <= 0
flow_diff_x_ub: - pixel_v_x + neighbor_v_x <= 0
flow_diff_y_lb: pixel_v_y - neighbor_v_y <= 0
flow_diff_y_ub: - pixel_v_y + neighbor_v_y <= 0
pixel_delta_lin_x_lb: - pixel + 0.9137254878878594 pixel_v_y
<= -0.9921568632125854
pixel_delta_lin_x_ub: - pixel + 0.9137254878878594 pixel_v_y
>= -0.9921568632125854
pixel_delta_lin_y_lb: - pixel + 0.9137254878878594 pixel_v_y
<= -0.9921568632125854
pixel_delta_lin_y_ub: - pixel + 0.9137254878878594 pixel_v_y
>= -0.9921568632125854
neighbor_delta_lin_x_lb: - neighbor - 0.0156862735748292 neighbor_v_y
<= -0.9921568632125854
neighbor_delta_lin_x_ub: - neighbor - 7.843136787414551e-04 neighbor_v_x
- 0.0156862735748292 neighbor_v_y >= -0.9921568632125854
neighbor_delta_lin_y_lb: - neighbor - 0.0156862735748292 neighbor_v_y
<= -0.9921568632125854
neighbor_delta_lin_y_ub: - neighbor - 0.0164705872535706 neighbor_v_y
>= -0.9921568632125854
difference_pixel_x_p_x_n_y_ub: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
- 7.8431367874145521e-04 neighbor_abs_v_x <= 0
difference_pixel_x_p_x_n_y_lb: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
+ 7.8431367874145521e-04 neighbor_abs_v_x >= 0
difference_pixel_x_n_x_p_y_ub: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
- 7.8431367874145521e-04 neighbor_abs_v_x <= 0
difference_pixel_x_n_x_p_y_lb: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
+ 7.8431367874145521e-04 neighbor_abs_v_x >= 0
difference_pixel_y_p_x_n_y_ub: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
- 7.8431367874145521e-04 neighbor_abs_v_y <= 0
difference_pixel_y_p_x_n_y_lb: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
+ 7.8431367874145521e-04 neighbor_abs_v_y >= 0
difference_pixel_y_n_x_p_y_ub: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
- 7.8431367874145521e-04 neighbor_abs_v_y <= 0
difference_pixel_y_n_x_p_y_lb: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
+ 7.8431367874145521e-04 neighbor_abs_v_y >= 0
difference_neighbor_x_p_x_n_y_ub: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
- 7.8431367874145521e-04 pixel_abs_v_x <= 0
difference_neighbor_x_p_x_n_y_lb: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
+ 7.8431367874145521e-04 pixel_abs_v_x >= 0
difference_neighbor_x_n_x_p_y_ub: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
- 7.8431367874145521e-04 pixel_abs_v_x <= 0
difference_neighbor_x_n_x_p_y_lb: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
+ 7.8431367874145521e-04 pixel_abs_v_x >= 0
difference_neighbor_y_p_x_n_y_ub: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
- 7.8431367874145521e-04 pixel_abs_v_y <= 0
difference_neighbor_y_p_x_n_y_lb: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
+ 7.8431367874145521e-04 pixel_abs_v_y >= 0
difference_neighbor_y_n_x_p_y_ub: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
- 7.8431367874145521e-04 pixel_abs_v_y <= 0
difference_neighbor_y_n_x_p_y_lb: pixel - neighbor
- 0.9137254878878594 pixel_v_y - 0.0156862735748292 neighbor_v_y
+ 7.8431367874145521e-04 pixel_abs_v_y >= 0
Bounds
pixel <= 1
neighbor <= 1
pixel_v_x <= 0.1000000000000001
-0.1 <= pixel_v_y <= 0
neighbor_v_x <= 0.1000000000000001
neighbor_v_y <= 0.1000000000000001
General Constraints
GC0: pixel_abs_v_x = ABS ( pixel_v_x )
GC1: pixel_abs_v_y = ABS ( pixel_v_y )
GC2: neighbor_abs_v_x = ABS ( neighbor_v_x )
GC3: neighbor_abs_v_y = ABS ( neighbor_v_y )
End
0
-
Official comment
-
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 why not try our AI Gurobot?. -
-
-
There is a known issue with general constraints in numerically challenging models. I am not sure what exactly causes the numerical issues in your model, but my guess would be that it is due to rounding errors in your coefficients. (They look like approximations of fractions. If so, you could try multiplying your constraints by a common denominator to get "nicer" numbers.) Our Numerics Guidelines could also be helpful/interesting.
The issue is fixed in Gurobi 9, which will be released later this month.
With NumericFocus=2, the model can also be solved with Gurobi 8.
0 -
-
Hi Silke,
Thank you for your quick response! Indeed, using NumericFocus=2 fixes the problem.
Best,
Anian
0 -
Post is closed for comments.
Comments
3 comments