Solving many scenarios

loop(k,
  r(i) = round(normal(1400,400));
  solve m minimizing z using mip;
  trace(k,j) = avg.l(j);
  trace(k,'obj') = z.l;
);

m.solvelink=5;
m.solprint=2;

solve m min z using mip scenario dict;

m.threads=4;

m.solveLink = 3;
loop(batch,
   ksub(k) = batchmap(batch,k);
   solve m min z using mip scenario dict;
   h(batch) = m.handle;
);

The optimized loop will keep GAMS in memory and calls the solver as a DLL instead of an executable. In addition printing is omitted. GAMS is still generating each model, and a solver is loading and solving the model from scratch.

The scenario solver will keep the model stored inside the solver and applies updates. In essence the GAMS loop is moved closer to the solver. To enable the scenario solver, we calculate all random ratings in advance:

    rk(k,i) = round(normal(1400,400));

As these are very small MIP models, adding solver threads to solve each model is not very useful. In our case it was even slightly worsening things. For small models most of the work is sequential (presolve, scaling, preprocessing etc) and there is also some overhead in doing parallel MIP (fork, wait, join).

The last approach is to setup asynchronous scenario solves. We split the 1,000 scenarios in 4 batches of 250 scenarios. We then solve each batch in parallel and use the scenario solver to solve a batch using 1 solver thread. This more coarse-grained parallelism is way more effective than using multiple threads inside the MIP solver. A disadvantage is that the tools for this are rather poorly designed and the setup for this is quite cumbersome: different loops are needed to launch solvers asynchronously and retrieving results after threads terminate. 

Conclusions:

• The end result: even for 1000 random scenarios, we can find two teams that have exactly the same average ELO rating.
• Solving many different independent scenarios may require some attention to achieve best performance.