Does APPSI solver support warmstart?

[ZedongPeng]

Summary

APPSI solver interfaces are designed to work very similarly to most Pyomo solver interfaces but are very efficient for resolving the same model with small changes. I played with the APPSI solver and found that the APPSI solver interface does not support warmstart yet. Did I miss something? If not, will warmstart be supported in the future?

[michaelbynum]

Yes, warm starts will be supported. This already happens automatically with the Appsi-Gurobi interface, but I have not had a chance to work on it for other interfaces. The current Appsi-Cplex interface uses a persistent LP writer. I plan to update the Appsi-Cplex interface to use the Python-Cplex interface just like the non-Appsi persistent interface to Cplex does. This will make warm starts much more efficient. It's not going to happen for a couple months though.

[ZedongPeng]

Hi @michaelbynum . When we are using a persistent solver in Pyomo, we can get the native solver object through self._solver_model. However, in appsi_cplex, it's named self._cplex_model. Will this be unified after updating the Appsi-Cplex interface to use the Python-Cplex interface? Btw, there are a lot of things missing in current appsi_cplex, like _pyomo_var_to_solver_var_map, _pyomo_con_to_solver_con_map, _solver_con_to_pyomo_con_map, _pyomo_sos_to_solver_sos_map. Will these also be added?

[ZedongPeng]

One more thing. I just found that in appsi_gurobi, _pyomo_var_to_solver_var_map is a dict() and uses variable id as the key. In gurobi_persistent, _pyomo_var_to_solver_var_map is a ComponentMap and uses variable as the key. Can this also be unified?

[michaelbynum]

@ZedongPeng What do you need access to these private attributes for? If these are needed, perhaps we can make a public API.

[ZedongPeng]

In MindtPy, there are two occasions that use _pyomo_var_to_solver_var_map. The first one is the single tree implementation of Outer Approximation method, which need to access the incumbent solution during the branch and bound process. https://github.com/Pyomo/pyomo/blob/bd202f880b19aa91d770a373ca3a11f4093f3e35/pyomo/contrib/mindtpy/single_tree.py#L66 The second one is the solution pool, which needs to access several solutions. https://github.com/Pyomo/pyomo/blob/bd202f880b19aa91d770a373ca3a11f4093f3e35/pyomo/contrib/mindtpy/iterate.py#L147

[bernalde]

@michaelbynum what kind of API do you think we should use here?

[michaelbynum]

The appsi interface to Gurobi already has and API defined for callbacks: https://github.com/Pyomo/pyomo/blob/aaed8923564d0198725c3e02fd56ccdcf4fd955a/pyomo/contrib/appsi/solvers/gurobi.py#L1136 and solution pools: https://github.com/Pyomo/pyomo/blob/aaed8923564d0198725c3e02fd56ccdcf4fd955a/pyomo/contrib/appsi/solvers/gurobi.py#L69 I need to get these documented better. The older persistent interface has something similar for callbacks: https://github.com/Pyomo/pyomo/blob/aaed8923564d0198725c3e02fd56ccdcf4fd955a/pyomo/solvers/plugins/solvers/gurobi_persistent.py#L461 However, it does not have anything for solution pools. I'd welcome any feedback on these APIs.

I would be very hesitant to provide access to the underlying Gurobi variables. If they get modified at all, everything gets out of sync. That being said, if we really want it, we could add methods like:

def get_gurobi_var(self, pyomo_var):
    return self._some_private_dict[pyomo_var]

This would at least prevent use of the private dictionary (which I think should definitely be private).

Thoughts?

[bernalde]

I think it would be great if we could use the "official" API to interface with APPSI solvers, particularly as they will be the same with other solvers and that's sort of the whole point. I also agree that we should keep the private dictionary private but keep the variables still accessible through that function. Would you recommend for we switch the existing functions in MindtPy to use those APIs?