Gurobi 11.0 presolve behaviour

Hi Gurobi Team!

Upon reading the news about the new Gurobi version, I was eager to try it out! The performance improvements in solving MIQCP and nonconvex MIQCP Problems seemed really useful to me.

But after installing it, I stumbled into a weird a problem. In Version 10 my MIQCP model needed around 215 seconds to be solved by Gurobi, but after upgrading to version 11.0 it took around 330 seconds to solve the same model! I also noticed a difference in the console output: Presolve in version 11.0 added 102.000 SOS constraints, that were not added before.

Here is a picture of the console output after upgrading:

I informed myself online and learned that they are created while reformulating the quadratic constraints, but are normally in turn automatically reformulated again. This step can be controlled via the Parameters PreSOS1Encoding/PreSOS2Encoding and PreSOS1BigM/PreSOS2BigM. After trying out a few combinations I got it working again by setting PreSOS1BigM and PreSOS2BigM to 1e+06 like it did in Version 10. Now all SOS constraints are gone after the Presolve step and Gurobi solved the model in around 150 seconds, so a really nice performance improvement over Version 10 ! :-)

Here is the new log after my changes:

Shouln't Gurobi be able to do this step by itself and set the Big M value accordingly to minimize the number of SOS constraints? Particularly because it worked flawlessly in Version 10. I never stumbled into this problem in the last 6 months while using Gurobi 10.0.

Is this a bug in the new version?

One side note: I also tinkered with adding quadratic objective terms that made my model nonconvex. In Version 10 this version of my model was not solvable in a reasonable time. In version 11 after implementing the afore mentioned parameter changes Gurobi is now able to solve this model relatively fast, in most cases under 10 minutes. The longest runtime i saw was around 45 Minutes. In Version 10 the solver wasn't able to close the MIPGap in several hours and was still stuck at a difference of about 10 %.

You talked about a 500 % performance improvement, for me it's more like not feasible to now solvable :-) 

I look forward to your reply

Greetings

Tim