Skip to main content

General tips for using Lazy constraints

Answered

Comments

2 comments

  • Jaromił Najman
    Gurobi Staff Gurobi Staff

    Hi Buddi,

    In most cases setting the lazy attribute results in faster performance of the solver than using callbacks. I'm not yet wholly confident whether there are specific use cases that one can only solve with lazy callbacks. Maybe one of you can add some thoughts on this.

    This is not correct. While there are cases where setting the lazy attribute is faster, most often lazy constraints are best used through a callback. This is because the general idea of lazy constraints is that there are so many of them that one could not write them all down, cf. the TSP example, and adding all of them to the model as normal constraint would just make the model way too big. The Knowledge Base article How do I implement lazy constraints in Gurobi? discusses when it might be better to use a callback vs the lazy attribute.

    Usually, if you don't have extremely many lazy constraint compared to the rest of the model constraints, it often makes more sense to just add those lazy constraints as normal constraints to the model. This way, Gurobi can use those constraints in the presolving step and possibly deduce additional information before even going into the B&B algorithm.

    It seems like very high values for heuristics parameter is not good with lazy constraints. I had the best performance with values around 0.3, but maybe this is model-specific. 

    This is not true in general. It is true that lazy constraints are meant to cut off feasible solutions found along the optimization path, but it is not said that running more heuristics (and thus hopefully finding more good feasible points) results in a performance degradation. In particular, you are saying that you had best performance when setting Heuristics=0.3, which can be considered a rather high value given the fact that its default value is 0.05.

    NoRelHeuristic performance comes down when the model has lazy constraints. I saw this both with the callback option and the attribute setting. Again, I cannot say whether there are some model-specific reasons for this. 

    This again cannot be generalized. The sole goal of the no relaxation heuristic is to find feasible points. Obviously, if most of those feasible points are cut off via lazy constraints, it may look like the no relaxation heuristic does not make any progress. However, it actually does a lot of progress by cutting off multiple solutions that are not of interest via lazy constraints.

    Another question I'm grappling with right now is, given a set of constraints in my model, how do I choose the best subset of constraints to be defined as lazy?

    I don't think that there is a way to determine the best subset to be defined as lazy constraints. This is because this set is very dependent on the particular optimization path for a given model. For different data, the optimization path may change and the lazy constraints subset may not be good.

    If the set of lazy constraint is not significantly bigger than the number of your normal constraints, then I would recommend trying to add all of the constraints as normal constraints (unless there is a specific reason for defining them as lazy).

    Best regards, 
    Jaromił

    0
  • Charitha Heendeniya
    Gurobi-versary
    Collaborator
    Investigator

    Thank you for the explanation. 

    0

Please sign in to leave a comment.