Will Gurobi 8.0.0 and 13.0.1 return different solutions for the same prioritizr conservation planning problem?

Answered

João Vasconcelos

April 21, 2026 14:02

• 
• 

Hi everyone,

I’m using the R package prioritizr to solve a conservation planning problem with Gurobi. I originally wanted to compare older and newer Gurobi versions, and I’m trying to understand whether changing only the Gurobi version could lead to different conservation scenarios.

My question is:

If I were to run the exact same prioritizr problem with the same data, same formulation, and same settings, but use Gurobi 8.0.0 versus Gurobi 13.0.1, should I expect the solver to return the same selected planning units / conservation scenario, or could the returned solution differ slightly? (I can't do this myself because my script doesn't run with 8.0.0)

More specifically, I’m wondering:

1. If both versions solve the problem to optimality, should the objective value always be the same?
2. Could the selected sites / decision variables differ because there are multiple optimal solutions?
3. Are there changes across Gurobi versions in things like presolve, heuristics, cuts, branching, or numerical tolerances that could cause different but equally optimal solutions to be returned?

I’d appreciate any guidance, especially if there is Gurobi documentation or a knowledge-base article that discusses reproducibility or differences in solutions across versions.

Thanks,

João

Related to

• Deterministic
• R

1

• 

  Byron Tasseff

  • Gurobi Staff

  April 21, 2026 19:41

  Hi João,

  I'm not very familiar with prioritizr, so I will mostly answer from the Gurobi perspective. To summarize, I would not expect Gurobi 8.0.0 and 13.0.1 to necessarily return the same solution.

  1. Objective value: I would be cautious about the meaning of "optimality" here. In Gurobi, a termination status of OPTIMAL indicates that the solution is optimal within tolerances. For MIPs, this is tied to the configured MIPGap. Gurobi's default MIPGap is 1e-4 (0.01%), but prioritizr appears to override it to 0.1 (10%) unless you set a different gap. So, with the default prioritizr settings, two runs across different versions could both return OPTIMAL without necessarily returning the same objective value. Each solution only needs to satisfy the configured gap criterion. If you want a stricter version-to-version comparison of objective values, I would recommend setting gap = 0 (or at least a much tighter value).
  2. Solution differences: Yes, solutions can differ. If the model has multiple optimal solutions, or if you solve with a nonzero MIP gap so that more than one near-optimal solution could satisfy the stopping criterion, different Gurobi versions can return different solutions. As noted in Is Gurobi deterministic?, reproducibility depends on using the same inputs on the same computer with the same Gurobi version. Once the version changes, the solver may follow a different solution path, which can lead to a different returned solution.
  3. Changes across versions: Yes. Once the Gurobi version changes, the determinism guarantee no longer applies. More generally, different versions can lead to different solution paths because of changes in internal algorithms, which can affect runtime and, when multiple optimal or near-optimal solutions exist, which solution is returned. The following articles provide useful background:
     • What is a solution path?
     • What is performance variability?
     • Why does Gurobi perform differently on different machines?

  If your goal is to explore alternative high-quality solutions systematically, you may be interested in the Solution Pool documentation. Also, prioritizr does appear to support returning a portfolio of solutions, and the current add_gap_portfolio() implementation relies on Gurobi's solution-pool functionality. For package-specific behavior, though, the prioritizr development team would be the best source of guidance.

  I hope this helps clarify what you might expect across versions. Please feel free to follow up if you have any additional questions.

  1
• 

  João Vasconcelos

  April 23, 2026 14:35

  • 
  • 

  Hello Byron

  Thank you very much for the response, it certainly clears the main doubt I had but nevertheless I'll look a bit deeper into this. In the meantime I ran for the first time my problem with gap = 0 instead of 0.1 (~24 hours of runtime) and the solutions were, although not exactly the same, much similar in terms of selected areas to the ones where version 8.0.0 was used, some 7 years ago. This will be helpful for my research because I was wondering where the difference could come from and even though I haven't ruled out the possibility of a human error in the code, it thins out its possibility. Thank you once again!

   

  1

Please sign in to leave a comment.