Additional variables being added to Objective Function

Answered

Oleg Grech

• May 07, 2022 19:05

Hi.

After modelling my constraints, I have arrived at my objective function which is as follows (this is only one part of the objective function for the sake of simplicity):

grb_model.setObjective((p_CA1SH.sum()), GRB.MINIMIZE)

When looking at the .lp file, the model is trying to minimise a lot of variables but I only need it to minimise those highlighted in red (see image):

I have multiple slack variables in this model as well.

Does anyone know why it is adding additional variables to the Objective Function? This is taking too long to find a feasible solution (or does not find a feasible solution). When removing the Objective Function a feasible solution is found in seconds.

Thanks in advance.

Oleg

1

• 

  Jaromił Najman

  Gurobi Staff

  • May 09, 2022 08:23
  • Edited

  Hi Oleg,

  All variables except for the p_CA1SH variable have \(0\) coefficients. Thus, they are not part of the objective function. What you see is just the default LP file format which prints all variables to the objective function even thou their coefficient is \(0\).

  If you observe that finding feasible solutions without an objective function is easier, you could solve your model without your objective function first and then use the solution points as MIP starts. Additionally, you could try the No Relaxation Heuristic parameter which activates an additional feasible point heuristic before the root node relaxation is solved.

  Best regards, 
  Jaromił

  0
• 

  Oleg Grech

  • May 09, 2022 12:39

  

  

  

  Hi.

  Thanks for your reply.

  If going with the MIP start approach, you first have to produce a MIP start (.mst) or a solution (.sol) file.

  My questions are:

  1. Can a model be optimised more than once?
  2. If so, can the first optimisation not have an objective function while the second optimisation has an objective function?
  3. How would you store a MIP start (.mst) or a solution (.sol) file and how can this be loaded for MIP starts?
  4. How would you implement the said file for the second optimisation as the example provided is unclear?

  Thanks, Oleg

  0
• 

  Jaromił Najman

  Gurobi Staff

  • May 09, 2022 13:10
  • Edited

  Can a model be optimised more than once?

  Yes.

  If so, can the first optimisation not have an objective function while the second optimisation has an objective function?

  You can do the following

  # set objective to 0
  grb_model.setObjective(0, GRB.MINIMIZE)
  grb_model.optimize()
  # if at least one solution has been found, write it out
  if grb_model.SolCount > 0:
    grb_model.write("solution.sol")
  
  # set model objective to desired function
  grb_model.setObjective((p_CA1SH.sum()), GRB.MINIMIZE)
  # read in previously written solution point, it is actually not required
  # because Gurobi stores previous solution information unless you interrupt
  # the program execution or reset the model
  grb_model.read("solution.sol")
  # optimize with MIP start
  grb_model.optimize() 

  How would you store a MIP start (.mst) or a solution (.sol) file and how can this be loaded for MIP starts?

  You can use the Model.read method, see above.

  How would you implement the said file for the second optimisation as the example provided is unclear?

  See above.

  0
• 

  Oleg Grech

  • May 10, 2022 12:45

  

  

  

  Hi.

  Is there a way to set a time limit per Incumbent (as per image)? Or can you only set a time limit using Params.TimeLimit?

  

  Thanks
  Oleg

  0
• 

  Jaromił Najman

  Gurobi Staff

  • May 10, 2022 12:57
  • Edited

  Hi Oleg,

  What exactly do you mean time per incumbent?

  You could implement a MIPSOL callback, which is called whenever a new incumbent is found and check the runtime in this callback. Or as you already said, just set the TimeLimit parameter.

  Best regards, 
  Jaromił

  0
• 

  Oleg Grech

  • May 10, 2022 13:04

  

  

  

  Hi.

  Thanks for your prompt reply. By time per incumbent, referring back to the image above, incumbent 1264.00000 took 87s before going to incumbent 1177.000000. My question was whether I could limit each incumbent to a certain time limit? Hope this clears things up.

  Thanks
  Oleg

  0
• 

  Jaromił Najman

  Gurobi Staff

  • May 10, 2022 13:12
  • Edited

  By time per incumbent, referring back to the image above, incumbent 1264.00000 took 87s before going to incumbent 1177.000000. My question was whether I could limit each incumbent to a certain time limit?

  It is not possible, because one cannot know when a next incumbent is found. It may take only a few seconds or hours. It strongly depends on the model complexity.

  If you are trying to find good incumbents quickly, you should try the NoRelHeurTime parameter and the MIPFocus=1 parameter and set a maximum TimeLimit.

  Best regards, 
  Jaromił

  0

Please sign in to leave a comment.