Callback saving current solution to file

[Bernhard Willert]

Hi,

I'm trying to solve an integer problem which needs several days and I
want to be able to warmstart it, if it crashes. Based on the great
webinar, I got the idea to write a callback, which saves a found
solution to a mst-file, so that I can use this solution as an initial
setup.

If I try to execute model.write("solution.mst") in my callback, I get
the message "No solution available to write to MIP start file". Is
there any other way to write the solution to a file?
o
Is GRB.Callback.MIPSOL always invoked, when a new feasible solution is
deiscovered, or only when a new "best solution" is found?
Has anyone a better idea to make my problem crash-resistent? The way
above won't restore any cutting planes, but should be far better than
a complete restart anyway.

Thanks in advance,
Bernhard

[Chris Maes]

> If I try to execute model.write("solution.mst") in my callback, I get
> the message "No solution available to write to MIP start file". Is
> there any other way to write the solution to a file?

model.write("solution.mst") only works once Gurobi has
found an optimal solution. It won't write out incumbent solutions.

> Is GRB.Callback.MIPSOL always invoked, when a new feasible solution is
> deiscovered, or only when a new "best solution" is found?

As described in the Callback code section of the documentation
http://www.gurobi.com/doc/46/refman/node596.html#sec:CallbackCodes

the MIPSOL callback is only called when a new incumbent, or
a new "best solution" is found.

> Has anyone a better idea to make my problem crash-resistent?

Gurobi shouldn't crash when performing long solves. But
sometimes I lose my network connection, and accidentally
lose results from a solve on a remote machine. The .mst format is
very simple. See the description here:
http://www.gurobi.com/doc/46/refman/node604.html

So it is easy to write your own function in python
to save MIP start file.

Here is something I threw together by modifying the
python example callback.py
http://www.gurobi.com/doc/46/examples/node112.html

The function simple_mst_writer creates a .mst file
with the incumbent solution.

Hope that helps,
Chris

#!/usr/bin/python

import sys
from gurobipy import *

# Define callback function

def mycallback(model, where):
if where == GRB.callback.MIPSOL:
obj = model.cbGet(GRB.callback.MIPSOL_OBJ)
nodecnt = int(model.cbGet(GRB.callback.MIPSOL_NODCNT))
print 'Found incumbent soln at node', nodecnt, 'objective', obj
simple_mst_writer(model, 'solution.mst', nodecnt, obj)

# A simple MIP start file writer

def simple_mst_writer(model, mstfilename, nodecnt, obj):
mstfile = open(mstfilename, 'w')

varlist = model.getVars()
soln = model.cbGetSolution(varlist)

mstfile.write('# MIP start from soln at node %d objective %e\n' %
(nodecnt, obj))
for var, soln in zip(varlist, soln):
mstfile.write('%s %.16e\n' % (var.VarName, soln))
mstfile.close()

if len(sys.argv) < 2:
print 'Usage: callback.py filename'
quit()

# Read and solve model

model = read(sys.argv[1])

model.optimize(mycallback)

# Throw away solution

model.reset()

print '\n\nOptimizing from previous incumbent solution\n'

# load the MIP start file

model.read('solution.mst')

# Reoptimize

model.optimize()

[Chris Maes]

> model.write("solution.mst") only works once Gurobi has
> found an optimal solution. It won't write out incumbent solutions.

Actually that is not quite true. If you terminate the solve early
with a sub-optimal solution, model.write() will write the
solution to a start. The issue is that you can't call model.write()
from within a callback. This is why you need to write your
own MIP start file using python code.

> Gurobi shouldn't crash when performing long solves.

And I should add, if Gurobi does really crash, please report it.

Cheers,
Chris

[Bernhard Willert]

Thank you for the clarifications. I tried to write such a file writer
myself, but I used var.getAttr(GRB.Attr.X)), which didn't work, I
guess for the same reason as model.write(...).
I must have missed cbGetSolution in the example. Your code helps a
lot.

Loss of network connectivity shouldn't be the problem, Gurobi was
working in a detached screen session, which worked fine for several
days and should be immune to network problems. Sadly, I didn't save
any error message.
Well, I've restarted the computation. Let's see, what happens this
time.

By the way, I can't run most of the examples without modificaitons,
e.g. I have to write GRB.callback as GRB.Callback (capitalized). Is
this, because I'm still running Gurobi version 4.5.2?

Best regards,
Bernhard

[Chris Maes]

> By the way, I can't run most of the examples without modificaitons,
> e.g. I have to write GRB.callback as GRB.Callback (capitalized). Is
> this, because I'm still running Gurobi version 4.5.2?

Yep. In version 4.5 it is GRB.Callback. Version 4.6 is backwards
compatible so you can still use GRB.Callback, or the new
GRB.callback.

Chris