Rather than continuing optimization on a difficult model like glass4, it is sometimes useful to try different parameter settings. When the lower bound moves slowly, as it does on this model, one potentially useful parameter is MIPFocus, which adjusts the high-level MIP solution strategy. Let us now set this parameter to value 1, which changes the focus of the MIP search to finding good feasible solutions. There are two ways to change the parameter value. You can either use method m.setParam():
gurobi> m.setParam('MIPFocus', 1)
Set parameter MIPFocus to value 1
or you can use the m.Params class.
gurobi> m.Params.MIPFocus = 1 Set parameter MIPFocus to value 1
Once the parameter has been changed, we call m.reset() to reset the optimization on our model and then m.optimize() to start a new optimization run:
gurobi> m.reset()
Discarded solution information
gurobi> m.optimize()
Gurobi Optimizer version 10.0.1 build v10.0.1rc0 (linux64)
CPU model: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz, instruction set [SSE2] Thread count: 4 physical cores, 4 logical processors, using up to 4 threads Optimize a model with 396 rows, 322 columns and 1815 nonzeros Model fingerprint: 0x541d0ad3 Variable types: 20 continuous, 302 integer (0 binary) Coefficient statistics: Matrix range [1e+00, 8e+06] Objective range [1e+00, 1e+06] Bounds range [1e+00, 8e+02] RHS range [1e+00, 8e+06] Presolve removed 4 rows and 5 columns Presolve time: 0.00s Presolved: 392 rows, 317 columns, 1815 nonzeros Variable types: 19 continuous, 298 integer (298 binary) Found heuristic solution: objective 3.133356e+09 Root relaxation: objective 8.000024e+08, 72 iterations, 0.00 seconds (0.00 work units) Nodes | Current Node | Objective Bounds | Work Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time 0 0 8.0000e+08 0 72 3.1334e+09 8.0000e+08 74.5% - 0s H 0 0 2.400019e+09 8.0000e+08 66.7% - 0s H 0 0 2.220019e+09 8.0000e+08 64.0% - 0s 0 0 8.0000e+08 0 72 2.2200e+09 8.0000e+08 64.0% - 0s H 0 0 2.166685e+09 8.0000e+08 63.1% - 0s 0 0 8.0000e+08 0 72 2.1667e+09 8.0000e+08 63.1% - 0s 0 0 8.0000e+08 0 77 2.1667e+09 8.0000e+08 63.1% - 0s H 0 0 2.133351e+09 8.0000e+08 62.5% - 0s 0 0 8.0000e+08 0 80 2.1334e+09 8.0000e+08 62.5% - 0s 0 0 8.0000e+08 0 80 2.1334e+09 8.0000e+08 62.5% - 0s 0 0 8.0000e+08 0 83 2.1334e+09 8.0000e+08 62.5% - 0s 0 0 8.0000e+08 0 78 2.1334e+09 8.0000e+08 62.5% - 0s 0 0 8.0000e+08 0 83 2.1334e+09 8.0000e+08 62.5% - 0s 0 0 8.0000e+08 0 83 2.1334e+09 8.0000e+08 62.5% - 0s 0 0 8.0000e+08 0 88 2.1334e+09 8.0000e+08 62.5% - 0s 0 0 8.0000e+08 0 66 2.1334e+09 8.0000e+08 62.5% - 0s H 0 0 2.050017e+09 8.0000e+08 61.0% - 0s 0 2 8.0000e+08 0 65 2.0500e+09 8.0000e+08 61.0% - 0s H 1 4 2.050017e+09 8.0000e+08 61.0% 74.0 0s H 6 8 2.000016e+09 8.0000e+08 60.0% 41.8 0s H 130 128 1.700015e+09 8.0000e+08 52.9% 12.7 0s H 199 203 1.644459e+09 8.0000e+08 51.4% 10.8 0s H 213 213 1.644459e+09 8.0000e+08 51.4% 10.8 1s H 244 269 1.633347e+09 8.0001e+08 51.0% 11.0 1s 1428 1027 1.5333e+09 40 44 1.6333e+09 8.0001e+08 51.0% 15.5 5s 3138 1602 1.3750e+09 58 22 1.6333e+09 8.0001e+08 51.0% 20.5 10s * 4233 2185 66 1.600017e+09 8.0001e+08 50.0% 21.5 12s * 4238 2082 67 1.550017e+09 8.0001e+08 48.4% 21.5 12s H 4308 2026 1.500016e+09 8.0001e+08 46.7% 21.6 14s 4457 2226 1.1000e+09 36 65 1.5000e+09 8.0001e+08 46.7% 22.6 15s H 4809 2136 1.450016e+09 8.0001e+08 44.8% 23.4 16s H 4908 2043 1.400013e+09 8.0001e+08 42.9% 23.9 17s H 5098 2027 1.350013e+09 8.0001e+08 40.7% 24.8 18s H 5282 1752 1.200013e+09 8.0001e+08 33.3% 25.7 18s Interrupt request received Cutting planes: Gomory: 37 Cover: 9 Implied bound: 41 MIR: 51 Flow cover: 266 RLT: 107 Relax-and-lift: 99 Explored 5332 nodes (140122 simplex iterations) in 19.00 seconds (18.72 work units) Thread count was 4 (of 4 available processors) Solution count 10: 1.20001e+09 1.35001e+09 1.40001e+09 ... 1.64446e+09 Solve interrupted Best objective 1.200012600000e+09, best bound 8.000066838804e+08, gap 33.3335%
Results are consistent with our expectations. We find a better solution sooner by shifting the focus towards finding feasible solutions (objective value 1.2e9 versus 1.5e9).
The setParam() method is designed to be quite flexible and forgiving. It accepts wildcards as arguments, and it ignores character case. Thus, the following commands are all equivalent:
gurobi> m.setParam('NODELIMIT', 100)
gurobi> m.setParam('NodeLimit', 100)
gurobi> m.setParam('Node*', 100)
gurobi> m.setParam('N???Limit', 100)
You can use wildcards to get a list of matching parameters:
gurobi> m.setParam('*Cuts', 2)
Matching parameters: ['Cuts', 'CliqueCuts', 'CoverCuts', 'FlowCoverCuts',
'FlowPathCuts', 'GUBCoverCuts', 'ImpliedCuts', 'MIPSepCuts', 'MIRCuts', 'ModKCuts',
'NetworkCuts', 'SubMIPCuts', 'ZeroHalfCuts']
Note that Model.Params is a bit less forgiving than setParam(). In particular, wildcards are not allowed with this approach. You don't have to worry about capitalization of parameter names in either approach, though, so m.Params.Heuristics and m.Params.heuristics are equivalent.
The full set of available parameters can be browsed using the paramHelp() command. You can obtain further information on a specific parameter (e.g., ;MIPGap) by typing paramHelp('MIPGap').
Previous: Interactive Shell Tutorial: Simple Experimentation with a More Difficult Model
Next: Interactive Shell Tutorial: Working with Multiple Models
Comments
0 comments
Please sign in to leave a comment.