Exceptions when attempting to dispatch problems from pysp to NEOS.

[mlangiu]

I am trying to solve some test cases with the pysp module but encountered difficulties with the runef and runph commands: When attempting to solve the expected value problem of the farmer example, appending the option --solver-manager=neos to the commandas as indicated in the README.txt , i.e.:

 pyomo solve --solver=cplex --solver-manager=neos models/ReferenceModel.py scenariodata/AverageScenario.dat

has the desired effect: The problem is dispatched to the NEOS server and reports an optimal value of -118600 upon completion.

Solving the stochastic problem on the other hand, i.e. issuing:

 runph --model-directory=models --instance-directory=nodedata -s scenariodata --default-rho=1 --solver=cplex --solver-manager=neos

fails with the exception

runph: KEY ERROR:
"Component with id '140023680377768': Total_Cost_Objective"

From what is said on page 177 of the second edition of "Pyomo - Optimization Modeling in Python" (2017) I understand that the runef command:

 runef -m models -s scenariodata --solve --solver=cplex --solver-manager=neos

should have the same effect as the pyomo command above (at least in pyomo version 5.1 for which the book was written, I am using version 5.3), however I also get an exception, this time:

runef: VALUE ERROR:
ProblemWriter_nl passed unrecognized io_options:
warmstart = True

From the fact that the runef command does not appear in the README.txt I am guessing that its direct usage has been deprecated in favor of the pyomo command. If that is the case, is there a similar syntax for the runph command that allows usage of NEOS?

[ghackebeil]

I'll have to think about how to fix this for both runph and runef. The fundamental issue is that the "solver" object that gets created claims it is going to use the LP-file interface to Cplex, but the neos "solver_manager" tells the solver to use a different interface.

In the meantime, to get around the "warmstart" error for runef, add the option --disable-warmstart. Unfortunately, I can't give you a short term workaround for runph

[mlangiu]

Thanks for the quick reply!

Disabling warmstart was already helpful, as the runef command actually solves the extensive form of the stochastic problem instead of the problem for average-case random variables (as I understood at first), so at least for me this is sufficient for the moment.

[dberardo]

i think this bug was fixed for the runef case in the new pysp release, as this issue does not occur in my case, when using runef.

However, the problem still persists for the runph command, and the option --disable-warmstart does not help there. I have also tried to use different solvers such as cbc, cplex and gurobi. It seems like this problem only rises when dealing with MILP solvers, as i manage to get runph running on ipopt, but of course that returns a result which is not satisfactory, since integer variables are relaxed.

Has anyone come up with a solution for runph?

I am stuck, cause my problem takes ages to be solved through runef, also by increasing the mipgap.

Thank you

UPDATE: the script rising the exception is : https://github.com/Pyomo/pyomo/blob/master/pyomo/core/kernel/component_map.py on line 98, if this is of any help

[mrmundt]

Hello, @mlangiu. PySP has recently moved into its own repository in the Pyomo organization. If this is still a concern, please make an issue in the PySP repository for further support. For other help or use questions with Pyomo, we refer you to review our documentation for ways to get help.