User Tools

Site Tools


solver:distributed_parallel_algorithms_with_gams_gurobi

Distributed Parallel Algorithms with GAMS/Gurobi

Starting with Gurobi 6.0.2 (GAMS 24.4.2), GAMS/Gurobi can utilize the distributed parallel algorithms offered by Gurobi:

  • A distributed MIP solver, which allows you to divide the work of solving a single MIP model among multiple machines. A manager machine passes problem data to a set of worker machines in order to coordinate the overall solution process.
  • A distributed concurrent solver, which allows you to use multiple machines to solve an LP or MIP model. Unlike the distributed MIP solver, the concurrent solver doesn't divide the work associated with solving the problem among the machines. Instead, each machine uses a different strategy to solve the whole problem, with the hope that one strategy will be particularly effective and will finish much earlier than the others. For some problems, this concurrent approach can be more effective than attempting to divide up the work.
  • Distributed parameter tuning, which automatically searches for parameter settings that improve performance on your optimization model. Tuning solves your model with a variety of parameter settings, measuring the performance obtained by each set, and then uses the results to identify the settings that produce the best overall performance. The distributed version of tuning performs these trials on multiple machines, which makes the overall tuning process run much faster.

These distributed algorithms are designed to be nearly transparent to the user. The user simply modifies a few parameters, and the work of distributing the computation among multiple machines is handled behind the scenes by the Gurobi library.

Configuring a Distributed Worker Pool

Before your program can perform a distributed optimization task, you'll need to identify a set of machines to use as your distributed workers. Ideally these machines should give very similar performance. Identical performance is best, especially for distributed tuning, but small variations in performance won't hurt your overall results too much. Once you've identified your distributed worker machines, you'll need to start Gurobi Remote Services on these machines.

Gurobi Remote Services

Gurobi Remote Services allow a machine to perform Gurobi computations on behalf of other machines. It is a Windows Service on Windows sytems, and a daemon on Linux and Mac systems. You will need some extra software to run the Gurobi Remote Services. Contact support.gams.com to get access to this software.

Starting Gurobi Remote Services on the Worker

Windows: On a Windows system, you will need to start Gurobi Remote Services by running grb_rs.exe. Running this program requires administrative privileges. The next step after starting Gurobi Remote Services depends on your anti-virus software and firewall settings. Most anti-virus software will ask you to confirm that you are allowing programs grb_rs.exe and grb_rsw.exe to receive network traffic. Once you confirm this, Gurobi Remote Servides will start serving requests. If you don't receive such a prompt, you will need to add grb_rs.exe and grb_rsw.exe to the firewall exceptions list. Select Allow a program through Windows firewall under the Security area of the Control Panel (labeled Allow an app through Windows firewall in Windows 8).

Some machines have more restrictive firewalls that may require additional action. Gurobi Remote Services uses ports 61000-65000 by default. If you are unable to reach the Compute Server after taking the steps described, ask your network administrator for more information on how to open the required ports.

Once Gurobi Remote Services has been started, you should see the grb_rs service listed in the Services tab of the Task Manager. To start or stop the service, click on the Services button at the bottom-right of the Services tab, and then right-click on the Gurobi Remote Services item on this screen.

You can also start or stop Gurobi Remote Services from a Console window with administrator privileges. Running grb_rs -h lists command-line options. Issuing a grb_rs -s command stops Gurobi Remote Services.

Mac: On Mac systems, Gurobi Remote Services is a daemon that allows a server to perform Gurobi computations on behalf of other client machines. To start the Gurobi Remote Services daemon, run the program grb_rs (with no arguments) on your server. You only need to do this once – Gurobi Remote Services will keep running until you stop it (or until the machine is shut down). Note that Gurobi Remote Services runs as a user process, so you do not need root privileges to start it.

If you would like Gurobi Remote Services to restart automatically when the machine is rebooted, there are a number of options for doing so (including launchd and /etc/rc.local). You could start adding the following lines to /etc/rc.local:

/path/to/gurobi/software/grb_rs

To stop Gurobi Remote Services if it is already running, you can issue the grb_rs -s command. You can also use the ps command to find the relevant process ID, and the kill command to terminate that process.

Output from Gurobi Remote Services goes to the system log (/var/log/system.log). You will need to modify /etc/syslog.conf to see these messages, since by default OS X only allows error message in the system log. Once you have modified syslog.conf, you should see a message similar to the following when you start the server:

Mar  9 12:37:21 mymachine grb[7917]: Gurobi Remote Services started: Sat Mar  9 12:37:21 2015

By default, Gurobi Remote Services only produces logging output when it starts. Start Gurobi Remote Services with the -v switch to obtain more detailed logging information. For example, this option will generate a log message each time a client job starts.

If you run into trouble accessing Gurobi Remote Services, check to see if the server is running firewall software that might be blocking access to some ports. Gurobi Remote Services uses port numbers 61000-65000 by default, so you'll need to open access to these ports on the server. Please consult the documentation for your firewall software to determine how to do this.

Linux: On Linux systems, Gurobi Remote Services is a daemon that allows a server to perform Gurobi computations on behalf of other client machines. To start the Gurobi Remote Services daemon, run the program grb_rs (with no arguments) on your server. You only need to do this once – Gurobi Remote Services will keep running until you stop it (or until the machine is shut down). Note that Gurobi Remote Services runs as a user process, so you do not need root privileges to start it.

If you would like Gurobi Remote Services to restart automatically when the machine is rebooted, there are a number of options for doing so (including /etc/rc.local and upstart). You should talk to your system administrator.

To stop Gurobi Remote Services if it is already running, you can issue the grb_rs -s command. You can also use the ps command to find the relevant process ID, and the kill command to terminate that process.

Output from Gurobi Remote Services goes to the system log (/var/log/syslog). You should see a message similar to the following when you start the server:

Mar  9 12:37:21 mymachine grb[7917]: Gurobi Remote Services started: Sat Mar  9 12:37:21 2015

By default, Gurobi Remote Services only produces logging output when it starts. Start Gurobi Remote Services with the -v switch to obtain more detailed logging information. For example, this option will generate a log message each time a client job starts.

If you run into trouble accessing Gurobi Remote Services, check to see if the server is running firewall software that might be blocking access to some ports. Gurobi Remote Services uses port numbers 61000-65000 by default, so you'll need to open access to these ports on the server. Please consult the documentation for your firewall software to determine how to do this.

Next steps

Once you've set up Gurobi Remote Services, you should test the state of the server. Type this command on your server:

gurobi_cl --server=localhost --status

If the output looks similar to this:

------------------------------------------------------------------
Checking status of Gurobi Remote Services on 'localhost'...
------------------------------------------------------------------

Gurobi Remote Services (version 6.0.2) functioning normally
Available services: Distributed Worker
Job limit: 1, currently running: 0

then Remote Services is ready for use. The client GAMS/Gurobi will need to know how to reach your workers. You'll use the WorkerPool parameter to tell GAMS/Gurobi how to access the pool of workers. In order to use the distributed MIP solver you specify option DistributedMIPJobs, for distributed concurrent solver you use option ConcurrentJobs, and for distributed tuning you use option TuneJobs. Details can be found in the GAMS/Gurobi solver manual.

Here is a log of a successful distributed MIP run with three workers:

Gurobi           24.4.2 r51223 Released Mar 14, 2015 VS8 x86 32bit/MS Windows

Gurobi full + distributed license.
Gurobi library version 6.0.2
Reading parameter(s) from "C:\tmp\gurobi.opt"
>>  workerpool  192.168.178.86,192.168.178.32,192.168.178.37
>>  distributedmipjobs 3
Finished reading from "C:\tmp\gurobi.opt"
Starting Gurobi...
Optimize a model with 126 rows, 127 columns and 465 nonzeros
Coefficient statistics:
  Matrix range    [1e+00, 2e+01]
  Objective range [1e+00, 1e+00]
  Bounds range    [1e+00, 2e+01]
  RHS range       [1e+00, 2e+01]
Started distributed worker on 192.168.178.86
Started distributed worker on 192.168.178.32
Started distributed worker on 192.168.178.37

Distributed MIP job count: 3
Job count limited by machine availability

    Nodes    |    Utilization     |     Objective Bounds      |     Work
 Expl Unexpl |  Active Sync Comm  | Incumbent    BestBd   Gap | It/Node Time

*    0     -                      -0.0000000          -      -     -   21s
     0     0      -    -    -              -          -      -     -   21s
*    0     -                      16.0000000          -      -     -   21s
*    0     -                      17.0000000          -      -     -   21s
*    0     -                      18.0000000          -      -     -   21s
*    0     -                      19.0000000          -      -     -   21s
*    0     -                      21.0000000          -      -     -   21s

Explored 140 nodes (2495 simplex iterations) in 21.39 seconds
Distributed MIP job count: 3

Time limit reached
Best objective 2.100000000000e+01, best bound 2.600000000000e+01, gap 23.8095%
MIP status(9): Optimization terminated due to time limit.

Solving fixed MIP.
Optimize a model with 126 rows, 127 columns and 465 nonzeros
Coefficient statistics:
  Matrix range    [1e+00, 2e+01]
  Objective range [1e+00, 1e+00]
  Bounds range    [1e+00, 2e+01]
  RHS range       [1e+00, 2e+01]
Presolve removed 126 rows and 127 columns
Presolve time: 0.00s
Presolve: All rows and columns removed
Iteration    Objective       Primal Inf.    Dual Inf.      Time
       0    2.1000000e+01   0.000000e+00   0.000000e+00      0s

Solved in 0 iterations and 0.01 seconds
Optimal objective  2.100000000e+01
Fixed MIP status(2): Model was solved to optimality (subject to tolerances).

MIP   Solution:         21.000000    (2495 iterations, 140 nodes)
Final Solve:            21.000000    (0 iterations)

Best possible:          26.000000
Absolute gap:            5.000000
Relative gap:            0.192308
Short URL
solver/distributed_parallel_algorithms_with_gams_gurobi.txt · Last modified: 2015/03/17 15:20 by admin