Gurobi: Difference between revisions

Note that all Gurobi license checkouts are handled by a single license server located in Ontario; it is therefore important for you to make sure that your use of Gurobi limits as much as possible license checkout attempts.  Rather than checking out a license for each invocation of Gurobi in a job--which may occur dozens or even hundreds of times--you should ensure that your program, whatever the language or computing environment used, only makes a single license checkout and then reuses this license token throughout the lifetime of the job. This will improve your job's performance since contacting a remote license server is very costly in time and will also improve the responsiveness of our license server for everyone who is using Gurobi.  <span style="color:red">Failure to use Gurobi carefully in this regard may ultimately result in random intermittent license checkout failures for all users.  If this happens, you will be contacted and asked to kill all your jobs until your program is fixed and tested to ensure the problem is gone.</span>    Some documentation on this subject for C++ programs may be found [https://www.gurobi.com/documentation/9.5/refman/cpp_env2.html here], explaining how to create a single Gurobi environment which can then be used for all your models. Python users can consult this [https://www.gurobi.com/documentation/9.5/refman/py_env_start.html page], which discusses how to implement this same idea of using a single environment and thus a single license token with multiple models.  Other programs when run in parallel that call Gurobi such as R can also easily trigger the problem especially when many simultaneous jobs are submitted and/or run in parallel.

  <!--T:42-->

  [gra800:~] gurobi_cl --help

   

  [gra-login2:~] salloc --time=1:00:0 --cpus-per-task=8 --mem=1G --account=def-xyz

Reference: https://www.gurobi.com/documentation/8.1/refman/recording_api_calls.html

<!--T:70-->