Callback MIPSOL_OBJBST finds value higher than incumbent?

285 views
Skip to first unread message

Jasper

unread,
Jun 20, 2018, 2:18:37 PM6/20/18
to Gurobi Optimization
Hello,

I've created a gurobi model where lazy constraints are used.
To compare the behaviour over time, I've made a benchmark script that is as follows:
def callback_function(model, where):
    all_scheduled
= sps.callback(model, where)
   
if where == gp.GRB.Callback.MIPSOL:
        timer
.add_measurement([
           
"MIPSOL",
            md
.model.cbGet(gp.GRB.Callback.MIPSOL_OBJBST),
            md
.model.cbGet(gp.GRB.Callback.MIPSOL_OBJBND),
            md
.model.cbGet(gp.GRB.Callback.MIPSOL_SOLCNT),
            md
.model.cbGet(gp.GRB.Callback.MIPSOL_NODCNT),
            all_scheduled
       
])
   
elif where == gp.GRB.Callback.MIPNODE:
       
if timer.time_diff_last_event() >= 0.1:
            timer
.add_measurement([
               
"MIPNODE",
                md
.model.cbGet(gp.GRB.Callback.MIPNODE_OBJBST),
                md
.model.cbGet(gp.GRB.Callback.MIPNODE_OBJBND),
                md
.model.cbGet(gp.GRB.Callback.MIPNODE_SOLCNT),
                md
.model.cbGet(gp.GRB.Callback.MIPNODE_NODCNT),
                all_scheduled
           
])

The function sps.callback(model, where)is the procedure that checks if the solution is allowed, and returns true if no lazy constraint is added (implying that the proposed incumbent is accepted) and false otherwise. I've built a timer-class that saves all the data along with a timestamp. The collected data is shown in data.xlsx (attachment, an excel-dump from pandas). I've included a plot in the bottom of the post. The gurobi output is shown in log.txt.

The weird behaviour starts occurs at entry 199 (row 201 in data.xlsx). The best found incumbent up to that point is 516.0, while the callback gp.GRB.Callback.MIPSOL_OBJBST returns 566, and this solution is accepted in the sense that no lazy constraint is added by sps.callback. The found value of 566 does not show up in the gurobi log, which would be at or around line 121 in log.txt.
The solution 566 is not reported in the logs during the solving procedure, but is reported as one of the solutions (7) found:
Solution count 7: 400 410 516 ... 1600
(It's the 4th best solution found).

My question is mainly why gurobi proposes an incumbent solution that's worse than the best known incumbent solution. According to the documentation, GRB.Callback.MIPSOL_OBJBST should return the current best objective, which should be 516 in this case and not 566. Also, if this solution is found, why is it not shown in the gurobi log?

Thanks in advance!

Jasper





plot of data.xlsx
x-axis: time,
y-axis: objective value.
Blue line: presumed incumbent (last entry from data.xlsx of MIPSOL OBJBST with all_scheduled==True)
Orange line: The best bound OBJBND
Green cross marker: the value corresponding to accepted and rejected MIPSOL solutions from data.xlsx
data.xlsx
log.txt
Auto Generated Inline Image 1

Michael Winkler

unread,
Jun 21, 2018, 9:59:22 PM6/21/18
to Gurobi Optimization
Hi Jasper,

I guess this happens due to data synchronization in Gurobi, so that you get some solutions in a different order as they are found.

Best,
Michael
Reply all
Reply to author
Forward
0 new messages