0
votes

I am working with some MIP models that only have binary variables as integer variables which represent optional elements in a network. Instead of solving the complete MIP I want to try out an algorithm where I do the following steps:

  1. Solve the problem with all binaries fixed to zero
  2. Solve the problem with all binaries fixed to one
  3. Use the difference in objective as budget to remove some of the binaries with too expensive objective contribution from the pool of options and solve again; repeat this step until either no binaries remain or no binary is removed during the iteration
  4. Solve the reduced MIP where some of the binaries are set to zero which reduces the number of practical binary variables

From my understanding this algorithm would benefit from using warmstarts as the last solution including the changes through variables fixings after the solve() calls would provide a feasible solution and bound for the model. I also use the deactivate()- and activate()-methods to change objectives and remove a constraint during step 2 and 3. For the constraint I also wrote code that sets the variables to a feasible solution after reactivating it.

When executing

results = optimizer.solve(self.pyM, warmstart=True, tee=True)

using Gurobi it seems that gurobi doesn't use the current variable values in the pyomo model but instead only uses the values from the last solve()-results without the changes afterwards (fixing variables to one/zero, adjusting values for the constraint). I assume this because if I don't reactivate the constraint and run a model where no binaries can be removed the log reports a working MIP Start while when activating it does give the same output:

Read MIP start from file /tmp/tmp3lq2wbki.gurobi.mst
[some parameters settings and model characteristics]
User MIP start did not produce a new incumbent solution
User MIP start violates constraint c_e_x96944_ by 0.450000000

regardless if I comment out the code that adjusts the values or not. I also expect that code snippet to work properly as I tested it separately and checked with help of the display()-method that the value of the constraint body lies between both bounds. In Step 2 only the read MIP Start line from above is in the log, but no statement what happend to it.

Is it possible to tell Pyomo to use the values from the Pyomo model instead or to update the .mst-file with the updated pyomo model values?

I found this Gurobi-persistent Class https://pyomo.readthedocs.io/en/stable/library_reference/solvers/gurobi_persistent.html

I tried

import pyomo.solvers.plugins.solvers.gurobi_persistent as gupyomo
[...]
test = gupyomo.GurobiPersistent(model = self.pyM)
for variable in adjustedVariables:
   test.update_var(variable) 
test.update()

but this neither produced output/errors nor changed the behaviour. Therefore I assume this is either not the correct way or I used it wrong.

Additional infos: gurobi 9.0.2 pyomo 5.7.1

If specific parts of the code might be helpful I can provide them but I wasn't sure if and what part could be relevant for the question

1
In your testing, have you tried checking the variable value after running test.updat_var(variable) in your for loop to see if the GurobiPersistent object registers your update? Also, I don't see an update method for the GurobiPersistent object so maybe that's affecting it, but I would think it would through an error if the object doesn't have that method. - cookesd

1 Answers

0
votes

So what seemed to work for me was instead using

optimizer.set_instance(self.pyM) at the start of my code and using optimizer.update_var(var[index]) whenever I change something like fixing the variable var[index]. , instead of above code.