Pyomo
Pyomo hangs when running MAiNGO solver
Summary
Pyomo 6.7.2 added support for the MAiNGO solver. When running a simple model, Pyomo hangs, with no output or result.
Steps to reproduce the issue
I'm running the following model. If the solver is set to 'bonmin', then Pyomo returns the correct optimal solution of x = 2, z = -1. When the solver if set to 'maingo', Pyomo produces no output. In Task Manager, I can see that the MAiNGO.exe process is running and using the CPU, but it does not end.
import pyomo.environ as pyo
Model = pyo.ConcreteModel()
Model.x = pyo.Var(domain = pyo.Reals, bounds = (0, 8), initialize = 1)
z = -1 * pyo.exp(-((Model.x - 2)**2))
Model.Obj = pyo.Objective(expr = z, sense = pyo.minimize)
Solver = pyo.SolverFactory('maingo')
Results = Solver.solve(Model, load_solutions = True, tee = True)
print(f'\nx = {Model.x():7.4f} z = {Model.Obj():7.4f} {Results.solver.termination_condition}\n')
MAiNGO correctly solves the same model when written using its interface, as follows:
from maingopy import *
from math import pi
class Model(MAiNGOmodel):
def __init__(self):
MAiNGOmodel.__init__(self) # Should be there for technical reasons
def get_variables(self):
variables = [OptimizationVariable(Bounds(0,8), VT_CONTINUOUS, "x") ]
return variables
def get_initial_point(self):
initialPoint = [1]
return initialPoint
def evaluate(self, vars):
x = vars[0]
result = EvaluationContainer()
result.objective = -1 * exp(-((x - 2)**2))
result.ineq = [x - 8] # x <= 8
result.ineq = [-x] # x >= 0
result.output = [OutputVariable("Result of x: ", x)]
return result
myModel = Model()
myMAiNGO = MAiNGO(myModel)
fileName = ""
myMAiNGO.read_settings(fileName) # If fileName is empty, MAiNGO will attempt to open MAiNGOSettings.txt
maingoStatus = myMAiNGO.solve()
Information on your system
Pyomo version: 6.7.2 Python version: 3.11.8 Operating system: Windows 11 How Pyomo was installed (PyPI, conda, source): PyPl Solver (if applicable): MAiNGO
@SolverMax - Question: does the same thing happen if you do not have tee = True?
@mrmundt We had a look at the issue.
To us it seems that the SolverFactory is not working properly.
@SolverMax Could you please try the following code and see if it still hangs without output?
import pyomo.environ as pyo
from pyomo.contrib.appsi.solvers import MAiNGO
Model = pyo.ConcreteModel()
Model.x = pyo.Var(domain=pyo.Reals, bounds=(0, 8), initialize=1)
z = -1 * pyo.exp(-((Model.x - 2) ** 2))
Model.Obj = pyo.Objective(expr=z, sense=pyo.minimize)
Solver = MAiNGO()
Solver.maingo_options["loggingDestination"] = 3
Results = Solver.solve(Model)
print(
f"\nx = {Model.x():7.4f} z = {Model.Obj():7.4f} {Results.termination_condition}\n"
)
The revised model runs and produces the expected output: x = 2.0000 z = -1.0000 TerminationCondition.optimal
@mrmundt It seems to us, that MAiNGO is not registered to the default SolverFactory, but only to the appsi SolverFactory.
So this code using the appsi SolverFactory should work just fine.
import pyomo.environ as pyo
from pyomo.contrib.appsi.base import SolverFactory
Model = pyo.ConcreteModel()
Model.x = pyo.Var(domain=pyo.Reals, bounds=(0, 8), initialize=1)
z = -1 * pyo.exp(-((Model.x - 2) ** 2))
Model.Obj = pyo.Objective(expr=z, sense=pyo.minimize)
Solver = SolverFactory("maingo")
Solver.maingo_options["loggingDestination"] = 3
Results = Solver.solve(Model)
print(
f"\nx = {Model.x():7.4f} z = {Model.Obj():7.4f} {Results.termination_condition}\n"
)
@mrmundt Is this intended behavior, or should MAiNGO also be registered to the default SolverFactory?
I just stumbled back across this. This is expected behavior. The MAiNGO interface is built through APPSI, and as such is registered through the APPSI solver factory as 'maingo'. It is also registered through the default ("legacy") solver factory as 'appsi_maingo'.
The behavior you are seeing is the result of a very old default option where the legacy SolverFactory would assume any name you requested that it doesn't know about must be an AMPL solver - and will try to pass an "NL-format" representation of your model to it with something like solver_name model.nl -AMPL. The newer interfaces (APPSI and the "new standard interface" under development in contrib/solver) do not have that behavior and will just issue an "unknown solver" error.
