38,789
edits
Gurobi/fr: Difference between revisions
Updating to match new version of source page
(Updating to match new version of source page) |
(Updating to match new version of source page) |
||
| Line 19: | Line 19: | ||
$ gurobi_cl 1> /dev/null && echo Success || echo Fail | $ gurobi_cl 1> /dev/null && echo Success || echo Fail | ||
<div class="mw-translate-fuzzy"> | |||
Si vous obtenez ''Success'', vous pouvez utiliser Gurobi. Si vous obtenez ''Fail'', contactez le [[Technical_support/fr | soutien technique]] pour de l'assistance. | Si vous obtenez ''Success'', vous pouvez utiliser Gurobi. Si vous obtenez ''Fail'', contactez le [[Technical_support/fr | soutien technique]] pour de l'assistance. | ||
</div> | |||
===Minimizing License Checkouts=== | ===Minimizing License Checkouts=== | ||
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. 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. | 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. | ||
== Allocations interactives == | == Allocations interactives == | ||