-
Notifications
You must be signed in to change notification settings - Fork 518
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
Subprocess Timeout Update #3183
Conversation
@@ -19,6 +19,7 @@ | |||
|
|||
from pyomo.common import Executable | |||
from pyomo.common.collections import Bunch | |||
from pyomo.common.errors import ApplicationError |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI - I added this because, when I opened the file on my IDE, it immediately warned me that ApplicationError
was used in the file but hadn't been imported.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3183 +/- ##
=======================================
Coverage 88.38% 88.38%
=======================================
Files 846 846
Lines 94974 94978 +4
=======================================
+ Hits 83941 83947 +6
+ Misses 11033 11031 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
I am playing catch up here. I think it would be useful to move the "named constant" to a module-level constant (and not an instance attribute) that all the solvers can share. We might even integrate it into a global "Pyomo options" ConfigDict |
Why shouldn't it be instance specific? I don't think I have an opinion, I'm just trying to understand the reasoning. |
The original 1-second timeout is generally OK for all solvers and situations. The most likely reason to change it is because you are on a platform where things are significantly slower (in a slow VM on a busy machine, working against an NFS share, on a platform with a particularly onerous virus scanner, etc). In that case, the "slow down" is likely to be endemic to the platform - so you would want to extend the timeout globally for all solvers. |
Fixes #3064
Summary/Motivation:
We have a hard-coded timeout of 1 second for system call solvers. This PR updates that to 2, but also puts that timeout in a private-esque attribute so users can adjust it, if necessary.
Changes proposed in this PR:
self._version_timeout
attribute onSystemCallSolver
Legal Acknowledgement
By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution: