Gurobi: Difference between revisions

Jump to navigation Jump to search
m
no edit summary
mNo edit summary
mNo edit summary
Line 29: Line 29:


<!--T:217-->
<!--T:217-->
Note that all Gurobi license checkouts are handled by a single license server located in Ontario, so that it is important for you to assure 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 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 can easily result in 10,000s upto 1,000,000s of checkouts per day ultimately resulting 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.
Note that all Gurobi license checkouts are handled by a single license server located in Ontario, so that it is important for you to assure 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 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.


== Interactive Allocations == <!--T:5-->
== Interactive Allocations == <!--T:5-->
cc_staff
1,857

edits

Navigation menu