Maliheh Aramon

I looked up the Method parameter. Would setting it to 4 (deterministic concurrent) ensure or improve the chances that all runs get the same result (all of them solving the LP with simplex or all of...

Hi Arthur, The first inconsistency is that all runs except one ran out of memory. I suspect the concurrent LP optimization at the root node caused a memory spike, as the logs show slight difference...

For the model.update() to discard the lazy constraints, you would need to modify the model. You can consider adding a dummy variable, for example, and then call the update method. I also tested you...

Please see the last response to this post. To discard all lazy constraints, you can call model.reset() or make a modification to the model, for example, by adding a dummy variable. However, you can...

Hi Jose, Yes, you are right. If you modify the model, for example, by adding a new constraint or variable, or by changing coefficients, the lazy constraints generated in the callback are discarded ...

Sorry for the confusion. I was not sure why you needed to call the optimize() method again, and was just trying to make sure you meant calling it on the same model object again.

If the model object remains the same and is not disposed of, yes the lazy constraints persist if you recall model.optimize(cb). As an example, if you initially call model.optimize(cb) with TimeLimi...

Hi Jose, You can read more about two different approaches to implement lazy constraints in the article “How do I implement lazy Constraints in Gurobi?”. As soon as an already feasible solution is v...

Hi Marco, In Gurobi, the lazy constraints added via setting the Lazy attribute or generated during a callback function should be linear. Do you mean that you add non-linear lazy constraints? I assu...

Hi, Thank you for reporting this to us. It seems it is a bug. I can replicate it with version 13.0.0, but versions 12.0.3 and 11.0.3 gave -80579.5 as the optimal solution. I will transfer this post...