Skip to main content

Mip Start

Ongoing

Comments

5 comments

  • Ronald van der Velden
    • Gurobi Staff Gurobi Staff

    Hi, this problem might occur if there are constraints around the boundary between the two years (e.g. if you have 3 shifts in a workforce puzzle on Dec 29-31 and 3 shifts on Jan 1-3, but maximum five consecutive are allowed). You could try a rolling horizon instead:

    • Build and solve the model for the first year
    • Then add the second year to the model, without touching the first year
    • Solve again
    • If Gurobi struggles generating a start solution for the second year (quite likely) then you could do this with smaller steps (e.g. add one month at a time)
    • You could also have the second year in the model from the start, but allow those variables to be continuous in the first solve
    0
  • Alessio Marcotulli
    • First Comment
    • First Question

    Hi, thanks for the response. However i dont get why in the log i dont have any “constraint violation” as output.
    Therefore i dont get why i still have this problem.
    I have also tried to understand which variables were different from a solution .mst got from the 2 year optimization.
    And the fact is that all the variables produced by the “combined file” and the file get from the 2 year opt are the same, the only difference is that 3000 variables out of 77000 have different values in the combined solution, so why Gurobi reject this as a initial solution?
    Alessio

    0
  • Ronald van der Velden
    • Gurobi Staff Gurobi Staff

    So why Gurobi reject this as a initial solution?

    This you can learn by fixing the solution (set the lowerbound and upperbound of each variable equal to the start solution) and asking Gurobi to optimize again. You would expect Gurobi to return infeasibility. Then you can use the tools described here to understand what causes the infeasibility.

    Kind regards,
    Ronald

    0
  • Riley Clement
    • Gurobi Staff Gurobi Staff

    If you're using gurobipy then you can use the following code snippet to fix the variables in your mst file.

    import gurobipy as gp

    def fix_start(model, start_file: str, subset=None):
        """Given a model and a start file (mst or sol), this function will
        fix the variables via lb and ub to the values in the file.

        Parameters
        ----------
        model : gurobipy.Model
        start_file : str
        subset : list, default None
            variables to fix, if None, then will set all
        """
        model_copy = model.copy()
        model_copy.read(start_file)
        all_copy_vars = model_copy.getVars()
        if subset is None:
            subset = all_copy_vars
        else:
            subset = [all_copy_vars[v.index] for v in subset]
        copy_vars = [v for v in subset if v.Start != gp.GRB.UNDEFINED]
        start = model_copy.getAttr("Start", copy_vars)
        vars = model.getVars()
        model.setAttr("LB", [vars[v.index] for v in copy_vars], start)
        model.setAttr("UB", [vars[v.index] for v in copy_vars], start)
        return model

    - Riley

    0
  • Alessio Marcotulli
    • First Comment
    • First Question

    Hi, i’ve done several changes to the code, in particular i fixed some problems that were related to the continuity constraints between the two years. And now the combined input works.

    So the solver takes and loads the solution uploaded by the .mst file combined, however i’ve noticed that during the optimization the value of the incumbent solution didn’t change. 
    It’ seems like Gurobi accept the given solution as the “optimal one”, and focuses only on the update of the best bound. 

    I’m wondering why this happens. Because in reality the solutions obtained with the single year runs and then combined, were performed both with MipGap = 10%. 
    Therefore im still thinking that the combined solution is at most suboptimal and i dont get why gurobi does not explore others possible solutions. 

    Alessio

    0

Please sign in to leave a comment.