Getting Stuck in gap in MIP optimization model
AnsweredI have developed an MIP optimization model for designing a district heating network. The objective of the optimization is to minimize the cost associated with the piping infrastructure. In the code, the binary variables direction_AB[edge] and direction_BA[edge] are employed.
I am currently facing a challenge related to reducing the gap between the Incumbent and BestBd of the objective function. It gets stuck in specific value. I set these parameters:
model.Params.ScaleFlag = 1
model.Params.MIPGap = 0.10
model.setParam("Threads", 4)
model.setParam(GRB.Param.Method, 1)
model.setParam(GRB.Param.Heuristics, 0.1) # Determines the amount of time spent in MIP heuristics (%)
model.setParam(GRB.Param.MIPFocus, 2)
model.setParam(GRB.Param.IntFeasTol, 1e06)
model.Params.OptimalityTol = 1e06
model.Params.IntFeasTol = 1e06
model.params.OutputFlag = 1
model.setParam('Presolve', 1)
model.Params.PreSOS1BigM = 1e10
Now I’m wondering how I can decrease this gap? And also is that possible that the global objecting function be in the gap more that zero? (for example the gap 10%). Thanks

Hi Atefeh,
There are so many parameters at nondefault values. What is the reasoning behind setting all these parameters?
We would suggest first running your model with the default setting. You can then examine the Gurobi log to understand why the gap does not improve. Is it because of the slow progress in the incumbent or in the best bound? If it is the former, you can experiment with parameters such as MIPFocus=1, NoRelHeurTime, Heuristics, and Cuts=01. If it is the latter, you can experiment with parameters such as Presolve=2, MIPFocus=23, and Cuts=23.
Experimenting with different values of the Method parameter generally makes sense if the time it takes to solve the root relaxation is considerably high.
Experimenting with the PreSOS1BigM parameter makes sense if you have used any of Gurobi APIs to model simple general constraints such as min, max, and abs.
Experimenting with the ScaleFlag parameter typically makes sense if the log shows signs of numerical difficulties or if the final solution quality is not acceptable.
Tightening the default tolerance values such as FeasibilityTol, OptimalityTol, and IntFeasTol is not recommended unless there is a good reason. For example, if the smallest coefficient values in your model are in the order of 1e7, it makes sense to set the FeasibilityTol, OptimalityTol to 1e8 (an order of magnitude smaller).Best regards,
Maliheh
0
Please sign in to leave a comment.
Comments
1 comment