linopy
linopy copied to clipboard
Improve run_gurobi to wait for available token
When using a Gurobi floating token server license or a web single-use license, a program that calls Gurobi Optimizer must obtain a token from a Gurobi token server before it can solve an optimization model. When no token is available, an exception gurobipy.GurobiError is raised (source : https://support.gurobi.com/hc/en-us/articles/360029879251-How-do-I-check-the-availability-of-floating-license-tokens).
To avoid Gurobi Optimizer throwing an error, I suggest to optionally wait for an available token. This is the purpose of this PR. The waiting time (in seconds) can be configured in the solver options.
Side note : This enables scenarios in PyPSA-Eur.
Codecov Report
Attention: Patch coverage is 20.00000% with 12 lines in your changes are missing coverage. Please review.
Project coverage is 86.40%. Comparing base (
a6f2c3e) to head (59e1aa1).
| Files | Patch % | Lines |
|---|---|---|
| linopy/solvers.py | 20.00% | 10 Missing and 2 partials :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## master #281 +/- ##
==========================================
- Coverage 89.71% 86.40% -3.31%
==========================================
Files 16 16
Lines 4024 4024
Branches 941 943 +2
==========================================
- Hits 3610 3477 -133
- Misses 281 421 +140
+ Partials 133 126 -7
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
thanks @tgi-climact, perhaps 60 secs is a bit long?
thanks @tgi-climact, perhaps 60 secs is a bit long?
Depending on the optimisation in progress, it could be very long or very short. I would like to avoid spam on the Gurobi servers. What would be your suggestion?
Depending on the optimisation in progress, it could be very long or very short. I would like to avoid spam on the Gurobi servers. What would be your suggestion?
okay I see, then the 60 secs make sense I guess.
A couple of thoughts:
There are many other things that can go wrong when creating an environment, not just token aquisition, for example: GurobiError: Server aborted the SSL handshake For this reason, I would atleast log the error, and not assume that it is the token causing failure.
Similarly, I would increase the logging level from debug, since if you are stuck in this loop, it would be helpful to see it in logs than just hang - most production systems only log info level and debug logs are only logged at when you are investigating a bug.
Also I would personally prefer it not to infinitely retry. I think it makes more sense to try some number of times and then give up (throw an error) unless very explicitly told otherwise. I'm imagining a fleet of servers all in a busy loop trying to reach a non-existent gurobi token server and having to all be rebooted.