-
Notifications
You must be signed in to change notification settings - Fork 134
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
Add kwarg fail_on_infeasable in model.solve #1139
base: dev
Are you sure you want to change the base?
Conversation
Reason: other nonoptimal statuses besides infeasable are possible, e.g. unbounded
So that results are saved, even if error is raised
I like the idea of having this new keyword in the Additionally, I dont get why solver status and termination condition are accessed like this: |
Thanks for your feedback. The feature is targeted at novice users. We expect that they assume a result to be optimal by default. Thus,
I like the API that works without the |
I changed the access of solver status and termination condition as suggested and wrote test to check if infeasable and unbounded problems are caught. I noticed that if the the 'tee=True' argument of pyomo is set. There is an additional warning from Pyomo in the form of
Seems a bit redundant, but I am not sure if we should supress this warning? |
The redundant warning was there before. Now we fail after the Pyomo warning, if not set otherwise. I won't worry too much, as this is a clear improvement. (We could decide not to warn if both, tee and returning without an optimal solution, are set, but that's a separate topic from this PR.) |
Added a new keyword to
model.solve()
:allow_nonoptimal
, which isFalse
on default.If
allow_nonoptimal
is False an error message is raised if the model does return a nonoptimal soltion, such asinfeasable
orunbounded
.Implements #1056.