Pulp default solver and Gurobi finding different objective values
alexisbarreaux opened this issue · comments
Details for the issue
What did you do?
I rewrote my model from gurobipy to pulp and then ran it with both default solver and GUROBI
What did you expect to see?
I expected to find the same objective value I had before : 364.812
What did you see instead?
Gurobi now finds 364.781 eventhough the status is optimal ( status 2), whereas the default solver (CBC if I'm correct ?) still finds the 364.812.
Useful extra information
What operating system are you using?
- Windows: ( version: ___ )
- Linux: ( _distro:Ubuntu 22.04.2 LTS / Linux 5.19.0-43-generic)
- Mac OS: ( version: ___ )
- Other: ___
I'm using python version:
- 2.7
- 3.4
- 3.5
- 3.6
- Other: 3.10.6
I installed PuLP via:
- pypi (python -m pip install pulp)
- github (python -m pip install -U git+https://github.com/coin-or/pulp)
- Other: ___ (conda?)
Did you also
- Tried out the latest github version: https://github.com/coin-or/pulp
- Searched for an existing similar issue: https://github.com/coin-or/pulp/issues?utf8=%E2%9C%93&q=is%3Aissue%20
Other information
The .lp files are identical (checked with git) for both solvers.
Also note that I have actually a bunch of models with the same underlying constraint satisfaction problem. All the other models seem to perform as they did before the switch to pulp (tests pass and manual check I performed also seemed ok) except for this one;
The only change between the two versions really is to switch from self.model.solve(solver=pl.GUROBI(OutputFlag=0, LogToConsole=0)) to self.model.solve(). Removing the gurobi args doesn't modify the result for gurobi.
Finally, I'm quite new to pulp, and even though I checked for a couple of hours on internet and also looked at the opened issues, I might have missed one. If so, please feel free to redirect me and sorry for the disturbance.
It might be related to the closed issue #592 and problems with floating values comparison. I do find it strange to have up to a E-1 difference in my case and between solvers though.
I've checked again and removing the flags I found the following outputs :
Optimal solution found (tolerance 1.00e-04)
Best objective 3.647805393336e+02, best bound 3.648118733752e+02, gap 0.0086%
Gurobi status= 2
I found the MIP parameter that defines the authorized gap and it seems the tolerance is relative and not absolute, which explains the fact that this solution is good enough for Gurobi with given tolerance : MIPGap. Reducing from 1e-4 to 1e-5 solved my issue. I don't know if there is a need to see if the gap tolerance is the same between the solvers or not ?
As of myself, this issue can be closed, but i'll let someone on the project close it to ensure there isn't anything to do or check.