linopy icon indicating copy to clipboard operation
linopy copied to clipboard

Improve run_gurobi to wait for available token

Open tgi-climact opened this issue 1 year ago • 6 comments

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.

tgi-climact avatar May 03 '24 14:05 tgi-climact

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.

codecov[bot] avatar May 03 '24 14:05 codecov[bot]

thanks @tgi-climact, perhaps 60 secs is a bit long?

FabianHofmann avatar May 03 '24 15:05 FabianHofmann

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?

tgi-climact avatar May 03 '24 15:05 tgi-climact

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.

FabianHofmann avatar May 03 '24 18:05 FabianHofmann

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.

dannyopts avatar Jul 21 '24 21:07 dannyopts