Using Gurobi to Verify the Optimality of a Reference Solution via MIPStart

回答済み

Jiarui Zhu

2026年02月03日 08:23

• 
• 
• 

 

Hi,

I am currently using Gurobi to validate the optimality of a known feasible solution for a MIP problem. I am looking for the most efficient way to configure Gurobi to terminate early if it finds an improvement.

Description: I have a Mixed-Integer Programming (MIP) problem and a reference feasible solution that I provide to the model using the MIPStart attribute before calling optimize().

Objective: My goal is to use Gurobi to verify if this reference solution is the global optimum. Specifically, I want the solver to:

• Terminate immediately as soon as it finds any new feasible solution with an objective value strictly better than the one provided via MIPStart.
• Continue to full optimality only if no such better solution exists, thereby proving that my reference solution is indeed optimal.

関連

• Termination
• MIPStart
• Log Files
• Deterministic

0

• 

  Riley Clement

  • Gurobi Staff

  2026年02月04日 23:45

  Hi Jiarui,

  You will need to use a callback to terminate the solver - see the following article for guidance: https://support.gurobi.com/hc/en-us/articles/360047717291-How-do-I-use-callbacks-to-terminate-the-solver 

  It might be worth loading your MIP start, and setting SolutionLimit=1, then optimizing to get the objective value of this MIP start.  Then reset SolutionLimit, and resume optimization with a “MIPSOL” callback that compares new solutions against the objective value found in the first solve.

  - Riley

   

  0
• 

  Jiarui Zhu

  2026年02月05日 12:49

  • 
  • 
  • 

   

  Hi Riley,

  I’m following up on my previous post regarding MIPStart usage, but a new issue has come up.

  I am performing maximum likelihood decoding experiments for linear block codes. My setup is roughly as follows:

  • The constraints of my ILP are fixed and known in advance.
  • I create the Gurobi model once, add all variables and constraints, and then repeatedly solve it.
  • For each solve, only the objective function coefficients change (randomly generated each time).
  • I also know the optimal solution, which I provide to Gurobi as a MIPStart (your previous advice helped me implement this correctly).

  Here’s the problem:

  • With constraint set A, each solve completes in acceptable time.
  • With constraint set B, which I expected to be harder, the solve time of a single instance sometimes exceeds acceptable limits.
  • To investigate, I enabled console logging for each solve. I observed that for some frames, Gurobi’s log stops updating in the middle of the solve, seemingly freezing the program.

  Interestingly, if I start the solve directly from the problematic frame (using a fixed random seed to reproduce it), the solver completes normally. However, after a while, another frame can again exhibit the same stalled log behavior.

  I have tried inserting:

   

  error = GRBreset(model, 1);

  before each solve, but the same phenomenon still occurs.

  My questions:

  1. Is it expected behavior for Gurobi logs to stop updating mid-solve during long solves?
  2. Why does running the solver directly from a problematic frame work fine, while sequential solves sometimes trigger the log stall?

  Thank you for any insights.

  0
• 

  Riley Clement

  • Gurobi Staff

  2026年02月06日 06:14

  Hi Jiarui,

  Is it expected behavior for Gurobi logs to stop updating mid-solve during long solves?

  It isn't entirely surprising.  A log line is only available to be written at certain points in the code.  If there is a break in the logging it indicates that there is at least one thread which is performing some computation that delays the log line being written. It doesn't necessarily mean Gurobi is stuck or misbehaving.

  Why does running the solver directly from a problematic frame work fine, while sequential solves sometimes trigger the log stall?

  It is not so clear but it might be worth reading the following articles so that the situation is better understood.

  • https://support.gurobi.com/hc/en-us/articles/360031636051-Is-Gurobi-deterministic
  • https://support.gurobi.com/hc/en-us/articles/26986814277137-Is-Gurobi-random
  • https://support.gurobi.com/hc/en-us/articles/26989139509393-What-is-a-solution-path

  When the behavior is deterministic, but different, it is indicative of a different solution path.  I would have expected a reset prior to every solve would have made the behavior consistent.  Are the model fingerprints the same each time?

  - Riley

  0

サインインしてコメントを残してください。