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

NL Writer Errors when presolve removes all variables #3131

Closed
michaelbynum opened this issue Feb 11, 2024 · 4 comments · Fixed by #3135
Closed

NL Writer Errors when presolve removes all variables #3131

michaelbynum opened this issue Feb 11, 2024 · 4 comments · Fixed by #3135

Comments

@michaelbynum
Copy link
Contributor

Summary

It would be extremely convenient if we could just return the solution somehow.

>>> import pyomo.environ as pe
>>> from pyomo.repn.plugins.nl_writer import NLWriter
>>> import io
>>> m = pe.ConcreteModel()
>>> m.x = pe.Var()
>>> m.y = pe.Var()
>>> m.obj = pe.Objective(expr=m.y)
>>> m.c1 = pe.Constraint(expr=m.y == m.x + 2)
>>> m.c2 = pe.Constraint(expr=m.y == -m.x + 1)
>>> writer = NLWriter()
>>> out = io.StringIO()
>>> writer.write(m, out)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/.../pyomo/repn/plugins/nl_writer.py", line 397, in write
    return impl.write(model)
           ^^^^^^^^^^^^^^^^^
  File "/.../pyomo/repn/plugins/nl_writer.py", line 865, in write
    raise ValueError(
ValueError: No variables appear in the Pyomo model constraints or objective. This is not supported by the NL file interface
@jsiirola
Copy link
Member

I left that in the new writer because it existed in the original NL writer. I agree that with the new presolve it is more likely that legitimate models will be sent to a solver and solved in the presolve. How do you think we should communicate this between the writer and the solver? My recollection when I was working on the NL writer was that ASL solvers would die a pretty terrible death if they were handed an NL file with no variables, so we would need to move this check from the NL writer to the solver interface(s). I suppose the information is in the NLInfo object, but we would need to make sure that all the NL solver interfaces handled it correctly.

@michaelbynum
Copy link
Contributor Author

Excellent question. I actively avoided attempting to figure that out in the original issue, haha. Maybe the NL writer could have an option to skip the error and return the NLWriterInfo anyway. Then the caller can see if info.variables is empty and decide what to do?

@jsiirola
Copy link
Member

I think that sounds quite reasonable. What do you think about preserving the old behavior in the legacy "call" interface (so the old solvers don't have to be updated). That is __call__ will raise the exception (and delete the NL file), whereas the write() interface will just write and return ... and leave that particular error check up to the solver interface?

@michaelbynum
Copy link
Contributor Author

Sounds good to me!

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

Successfully merging a pull request may close this issue.

2 participants