Query on GRBcblazy() -- what happens if added lazy cut is wrong and does not cutoff current candidate MIP solution

進行中

OneCable OneCable

2026年01月16日 06:44

• 
• 
• 

Hello,

From https://docs.gurobi.com/projects/optimizer/en/current/reference/c/callback.html#c.GRBcblazy

You would typically add a lazy constraint by querying the current node solution (by calling GRBcbget from a GRB_CB_MIPSOL or GRB_CB_MIPNODE callback, using what=GRB_CB_MIPSOL_SOL or what=GRB_CB_MIPNODE_REL), and then calling GRBcblazy() to add a constraint that cuts off the solution.

What happens if the user adds an erroneous cut which does NOT cut off the current candidate node solution? i.e., the candidate MIP solution satisfies the added lazy cut.

Is there a worry of an infinite loop or some such or else is the current solution considered as a valid feasible MIP solution and the incumbent is updated? Or is this undefined behaviour?

Thank you.

関連

• Callbacks
• Lazy Constraints

0

• 

  Vassilios Yfantis

  • Gurobi Staff

  2026年01月16日 09:42

  Hi,

  In this case a solution would be accepted and the lazy constraint would not be added to the cut pool. This should also not result in an infinite loop, since the same solution would not be found again in the tree.

  Best regards,

  Vassilios

  1
• 

  OneCable OneCable

  2026年01月17日 12:09 編集済み

  • 
  • 
  • 

  Hi Vassilios,

  I am encountering a situation where with default values the MIP starts on 4 threads on my machine. Then, the same candidate integer XBar solution is encountered within the Lazy cut callback. I run my separation routine to cut this solution and add it via GRBcblazy, it returns 0. Yet, the same XBar solution is again encountered within my lazy callback. Could this be because some heuristics are run in multiple threads and the same xbar could be encountered across threads?

  Troublingly, even after setting it to 1 thread, the same XBar solution is encountered a second time despite having added a lazy cut which is violated by that candidate solution.

  Do you have any suggestions in terms of whether the above behaviour is expected?

  Additionally, in a while, after finding a cut violated by the current MIP candidate solution, I add it via GRBcblazy. Despite this addition, Guroni reports that it has “Found heuristic solution: ” corresponding to the XBar value within the lazy cut callback.

  Thanks.

   

  0

サインインしてコメントを残してください。