Terminate when upper bound of the incubent solution is lower than certain value

[yifu.jo...@gmail.com]

Hello,

I am trying to solve a series of MIP problem, each one depends on the former ones result as a parameter in the constraints. As the number of the problem is too many, I am trying to save the time by terminate each problem quickly before the exact solution is achieved.

My strategy is to terminate when the upper bound of the incubent solution is lower than certain value, but I don't see there is a parameter setting can achieve this, can anyone help me? MIPGap setting seems to be a possible solution, but as the constraints are changing each time, I can't always get a feasible solution easily, and set it as the gurobi model start solution, (model.start). Are there any ideal method?

Thank you all.

[Kostja Siefen]

Hi,

You can implement a custom termination criterion like this with a callback (see http://www.gurobi.com/documentation/6.5/refman/callback_codes.html). Check the value of MIPNODE_OBJBND in a MIPNODE callback and call terminate() if it exceeds a certain threshold. You might also want to check that a feasible solution is available.

Kostja

[Robert Fourer]

This is a frequently requested feature; a related query appeared in the AMPL user forum just today.  The general idea is to set a target for the lower bound or a target for the upper bound in a MIP solve, such that Gurobi will stop and return the current incumbent as soon as the target is reached or exceeded.  These would seem easy enough to add to the available Gurobi option settings, but so far everyone who has wanted this behavior has been in the position of having to write their own custom callback.

Bob Fourer

4...@ampl.com

[Renan Garcia]

One way to achieve this without callbacks (for the incumbent bound only, not the relaxation bound) is to provide your goal for the Cutoff parameter (see http://www.gurobi.com/documentation/6.5/refman/cutoff.html#parameter:Cutoff) in combination with SolutionLimit=1 (see http://www.gurobi.com/documentation/6.5/refman/solutionlimit.html#parameter:SolutionLimit). However, this will likely perform worse than the callback option because it essentially disables solution improvement heuristics such as RINS.

-- 

--- 
You received this message because you are subscribed to the Google Groups "Gurobi Optimization" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gurobi+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[yifu.jo...@gmail.com]

Thanks a lot for your reply, I am using the params.Cutoff right now to set the calculation stop when the objective can't reach the Cutoff value. Is this right?

在 2016年3月9日星期三 UTC+8下午5:57:30，Kostja Siefen写道：

[Kostja Siefen]

The Cutoff parameter tells Gurobi to ignore solutions with worse or equal objective value. If the best bound moves past this threshold, you know that there can be no better feasible solution at all. In this case, Gurobi returns with status CUTOFF (see http://www.gurobi.com/documentation/6.5/refman/cutoff.html)

Kostja

[Minh Vu Duc]

A non-related question is that when the solver stops because of time limit condition without finding any feasible solution ; what is the status inwhich gurobi returns? There is some thing like GBR_UNKNOWN? I checked the available status codes but have not found the answer.

Thank,

Vào 03:37:33 UTC-5 Thứ Hai, ngày 21 tháng 3 năm 2016, Kostja Siefen đã viết:

[Renan Garcia]

Please refer to http://www.gurobi.com/documentation/6.5/refman/optimization_status_codes.html for the status codes. It should return TIME_LIMIT in this case.