Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"list index out of range" error when using inverse of a variable #153

Closed
andrewlee94 opened this issue Jun 2, 2017 · 4 comments
Closed

Comments

@andrewlee94
Copy link
Contributor

We have been running into this error in some of our models when writing the using the inverse of a variable in our models. If we write the inverse as 1/model.var, we get the error and traceback shown at the end. However, if we replace the inverse with model.var**-1 the problem is fixed. One common thread I have noticed is that the offending variable has always (so far) appeared in a Block.

I have a simple example model which demonstrates the bug, which can be found at:
https://github.com/IDAES/models/tree/unit_models_v2/idaes_models/unit/standard/pyomo_bug
Running the bug_demo.py file as a script resulted in the following traceback for me.

Traceback (most recent call last):
File "bug_demo.py", line 62, in
main()
File "bug_demo.py", line 53, in main
fs_obj.solve(tee=stee,options={'tol':1e-10})
File "/home/alee/IDAES Repository/models-master/idaes_models/core/process_base.py", line 923, in solve
self.pyomo_results = self.pyomo_solver.solve(m, *args, **kwargs)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/opt/base/solvers.py", line 581, in solve
self._presolve(*args, **kwds)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/solvers/plugins/solvers/ASL.py", line 188, in _presolve
SystemCallSolver._presolve(self, *args, **kwds)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/opt/solver/shellcmd.py", line 195, in _presolve
OptSolver._presolve(self, *args, **kwds)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/opt/base/solvers.py", line 660, in presolve
**kwds)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/opt/base/solvers.py", line 728, in convert_problem
**kwds)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/opt/base/convert.py", line 109, in convert_problem
problem_files, symbol_map = converter.apply(*tmp, **tmpkw)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/solvers/plugins/converter/model.py", line 163, in apply
io_options=io_options)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/core/base/block.py", line 1623, in write
io_options)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/repn/plugins/ampl/ampl
.py", line 356, in call
include_all_variable_bounds=include_all_variable_bounds)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/repn/plugins/ampl/ampl
.py", line 856, in _print_model_NL
ampl_repn = generate_ampl_repn(constraint_data.body)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/repn/ampl_repn.py", line 743, in generate_ampl_repn
repn = _generate_ampl_repn(exp)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/repn/ampl_repn.py", line 311, in _generate_ampl_repn
child_repn = _generate_ampl_repn(child_exp)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/repn/ampl_repn.py", line 652, in _generate_ampl_repn
child_repn = _generate_ampl_repn(exp._args[0])
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/repn/ampl_repn.py", line 380, in _generate_ampl_repn
e_repn = _generate_ampl_repn(e)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/repn/ampl_repn.py", line 311, in _generate_ampl_repn
child_repn = _generate_ampl_repn(child_exp)
File "/home/alee/anaconda2/lib/python2.7/site-packages/pyomo/repn/ampl_repn.py", line 413, in _generate_ampl_repn
ampl_repn = current_repn = arg_repns[0]
IndexError: list index out of range

@andrewlee94
Copy link
Contributor Author

I just did a little more quick testing, and the bug seems to arise due to the 1/self.T_ref term in line 100 of bug_prop.py. This fits with another common thread I think I have seen with this bug, which is that the offending variable has always been either fixed, or in this case a mutable Param.

On a side note, the model doesn't solve even when the bug is fixed, as I dropped work on the model to isolate the bug.

@ghackebeil
Copy link
Member

The link to your example model seems to be broken. If you update that, I'll take a look.

Also, it looks like the line numbers in your stack trace do not match what is on the master branch. So this possibly has been fixed in more recent versions. Might be worth testing.

@andrewlee94
Copy link
Contributor Author

The issue with the link is probably because the GitHub repo is protected - I just tried it myself and the link only works for me if I am logged in. This is part of the IDAES project, so John Siirola, Carl Laird or Bethany Nicholson should be able to get you access the files.

I have not tried updating Pyomo myself yet, as there are a couple of compatibility issues we are working out, but a couple of my colleagues are using more recent versions of Pyomo (not the most recent release though) and have had the same issue.

@blnicho
Copy link
Member

blnicho commented Jun 5, 2017

Here is a toy model that recreates the error on master. As Andrew mentioned, the issue appears to be with mutable parameters.

from pyomo.environ import *

m = ConcreteModel()

m.x = Var(bounds=(1,5))
m.p = Param(initialize=100, mutable=True)

m.con = Constraint(expr=exp(5*(1/m.x - 1/m.p))<=10)

m.obj = Objective(expr=m.x**2)

solver = SolverFactory('ipopt')
solver.solve(m, tee=True)`

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants