We will now demonstrate a simple model modification. Imagine that you only want to consider solutions where you make at least 10 pennies (i.e., where the Pennies variable has a lower bound of 10.0). This is done by setting the lb attribute on the appropriate variable (the first variable in the list v in our example)...
gurobi> v = m.getVars() gurobi> v.lb = 10
The Gurobi optimizer keeps track of the state of the model, so it knows that the currently loaded solution is not necessarily optimal for the modified model. When you invoke the optimize() method again, it performs a new optimization on the modified model...
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 4 rows, 9 columns and 16 nonzeros Model fingerprint: 0xa40e053a Variable types: 4 continuous, 5 integer (0 binary) Coefficient statistics: Matrix range [6e-02, 7e+00] Objective range [1e-02, 1e+00] Bounds range [1e+01, 1e+03] RHS range [0e+00, 0e+00] MIP start from previous solve did not produce a new incumbent solution Presolve removed 2 rows and 5 columns Presolve time: 0.00s Presolved: 2 rows, 4 columns, 5 nonzeros Variable types: 0 continuous, 4 integer (0 binary) Found heuristic solution: objective 25.9500000 Root relaxation: objective 7.190000e+01, 2 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 0 71.9000000 71.90000 0.00% - 0s Explored 1 nodes (2 simplex iterations) in 0.00 seconds (0.00 work units) Thread count was 4 (of 4 available processors) Solution count 2: 71.9 25.95 Optimal solution found (tolerance 1.00e-04) Best objective 7.190000000000e+01, best bound 7.190000000000e+01, gap 0.0000%
The result shows that, if you force the solution to include at least 10 pennies, the maximum possible objective value for the model decreases from 113.45 to 71.9. A simple check confirms that the new lower bound is respected:
gurobi> print(v.x) 10.0