Inconsistent Solution Paths in Repeated Runs Using APPSI Interface Solvers in Pyomo

[Zhanwei-Liu]

I'm experiencing a problem where I run the same model multiple times, but I get different solving paths for same solver each time. Even though the objective function values are the same, the decision values are different. I am not sure if this is a bug with Pyomo, so I have submitted the details of my question on Stack Overflow (more details). However, I have not yet received any answers.

[mrmundt]

@Zhanwei-Liu - In the future, please use the provided template. For this issue, provide the following details:

Information on your system

Pyomo version: Python version: Operating system: How Pyomo was installed (PyPI, conda, source): Solver (if applicable):

---

That being said, I am not an APPSI expert by any means, but the main difference between appsi_gurobi and gurobi is that gurobi, if I recall correctly, is a direct interface, whereas appsi_gurobi is a persistent interface. This is possibly part of the reason for seeing a difference. @michaelbynum - insight?

[Zhanwei-Liu]

Thank @mrmundt for your guidance, I'll make sure to use the provided template in my future submissions.

Although I'm not entirely sure why the difference occurs, I do know that the bug happens during the sover.solve process. It seems that appsi_gurobi reprocesses the generated model. The primary motivation for my choice of the appsi solver interface is that it exclusively offers the HiGHS solver, which is not available through other interfaces.

[michaelbynum]

@Zhanwei-Liu , to be clear, are you solving the same problem multiple times in a single Python process, or are you running multiple Python processes?

[michaelbynum]

A couple things to check:

• Ensure you are using one of Gurobi's deterministic methods (see https://www.gurobi.com/documentation/current/refman/method.html#parameter:Method and https://www.gurobi.com/documentation/current/refman/threads.html#parameter:Threads)
• Make sure you are not using any unordered data types such as set. The direct interface (`SolverFactory("gurobi", solver_io="python")) sorts the components (e.g., constraints) while the appsi interface does not. The appsi interface should still be deterministic if the underlying data structures used are deterministic.

[Zhanwei-Liu]

@Zhanwei-Liu , to be clear, are you solving the same problem multiple times in a single Python process, or are you running multiple Python processes?

I'm just running the same code multiple times on one computer, in the same Python process. That is, I am not solving the problem in multiple Python processes, repeatedly executing the same code in a single process.

[Zhanwei-Liu]

A couple things to check:

• Ensure you are using one of Gurobi's deterministic methods (see https://www.gurobi.com/documentation/current/refman/method.html#parameter:Method and https://www.gurobi.com/documentation/current/refman/threads.html#parameter:Threads)
• Make sure you are not using any unordered data types such as set. The direct interface (`SolverFactory("gurobi", solver_io="python")) sorts the components (e.g., constraints) while the appsi interface does not. The appsi interface should still be deterministic if the underlying data structures used are deterministic.

• I am confident that I have used a deterministic method, as I provided the same parameter configuration to Gurobi whether using the gurobipy or appsi interface. The peculiar issue I encountered is not about the difference in results between these two interfaces, but the fact that I received different solutions (in terms of decision variables) when repeatedly solving with the appsi interface. This inconsistency also occurs with other solvers when using the appsi interface.

• I have used set in my model and set the parameter ordered to TRUE (as below). I am uncertain if this could introduce randomness in model processing through the appsi interface.

def define_sets(model, para):
    """
    Define sets for the model.

    Args:
        model (pyomo.core.base.PyomoModel.ConcreteModel): Model to be solved.
        para (dict): Dictionary of parameters for the model.

    Returns:
        None
    """
    sets_to_initialize = ["year", "zone", "tech", "hour", "month"]
    tech_types = ["storage", "nondispatchable", "dispatchable", "hydro"]

    for set_name in sets_to_initialize:
        model.add_component(set_name, Set(initialize=para[set_name], ordered=True, doc=f'Set of {set_name}'))
    model.hour_p = Set(initialize=[0] + para['hour'], ordered=True, doc='Set of operation timesteps')

    for tech_type in tech_types:
        if tech_type in para['technology_type'].values():
            model.add_component(f"{tech_type}_tech", Set(initialize=[i for i, j in para['technology_type'].items() if j == tech_type], ordered=True, doc=f'Set of {tech_type} technology'))
        else:
            model.add_component(f"{tech_type}_tech", Set(initialize=[], ordered=True, doc=f'Set of {tech_type} technology'))

    if para['isinflow']:
        model.station = Set(initialize=para['stcd'], ordered=True, doc='Set of hydropower plants')

[Zhanwei-Liu]

Hi, @michaelbynum, do you have any additional comments on this question? Alternatively, could you provide guidance on the direction I should take to debug this particular part? Thank you very much!

[blnicho]

@Zhanwei-Liu could you please provide the following information on your system

Pyomo version: Python version: Operating system: How Pyomo was installed (PyPI, conda, source):

[Zhanwei-Liu]

Hi, @blnicho. My system information is as follows: Pyomo version: 6.5.0 Python version: 3.9.16 Operating system: macOS 13.3.1 How Pyomo was installed (PyPI, conda, source): conda If it is helpful, I have included my Conda environment file for reference. environment.txt

Thanks.