Here is an interim report.

Test environment is:

• IPMU cluster
• CPU on a calc node: Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz
• Number of threads per node: 28
• Gurobi version: 8.1.1

The current fiducial set of parameters are:

• MIPGap = 0.01
• Threads = 28
• Presolve = 2 (default: -1 (automatic))
• Method = 4 (default: -1 (automatic))
• DogenMoves = 0 (default: -1)
• Heuristics = 0.8 (default: 0.05)
• Seed = 0, 1, 2, 3, 4

The following problems are tested:

• mps1: using recent galaxy/AGN evolution survey (no priority)
• mps2: using recent galaxy/AGN evolution survey (higher priority for longer exposure time)
• mps3: using recent galaxy/AGN evolution survey (higher priority for shorter exposure time)
• mps4: using recent galaxy/AGN evolution survey (higher priority for larger fiber hour)
• mps5: using recent galaxy/AGN evolution survey (higher priority for smaller fiber hour)
• mps6: using recent galaxy/AGN evolution survey (higher priority for higher number density)
• mps7: using recent galaxy/AGN evolution survey (higher priority for lower number density)
• case00: using old galaxy/AGN evolution survey (higher priority for longer exposure time)
• case01: using previous galaxy/AGN evolution survey (no priority)
• case02: using previous galaxy/AGN evolution survey (higher priority for longer exposure time)

Note that the number of visit is 42 for all problem.

We test the following cases:

• fiducial case: using the fiducial set of parameters described above
• no_heuristics: no Heuristics is specified
• no_degenmoves: no DegenMoves is specified
• no_method: no Method is specified
• no_presolve: no Presolve is specified
• no_params: no parameters are specified (except for MIPGap, Threads)

Here is the comparison of the total execution time (sec.) against several cases:

Color shows the difference of mps file (problem) and lines with different Seed are shown.

Current conclusion: The fiducial set of parameters shows relatively short processing time (maybe we do not need to specify "Presolve").

Examine `Heuristics` (time spent in feasibility heuristics)

Determines the amount of time spent in MIP heuristics. You can think of the value as the desired fraction of total MIP runtime devoted to heuristics (so by default, we aim to spend 5% of runtime on heuristics). Larger values produce more and better feasible solutions, at a cost of slower progress in the best bound.

 Parameter range: 

• 0.05 (default)
• 0.1
• 0.2
• 0.5
• 0.8 (fiducial)

Here is the comparison of the total execution time in sec. 

Color is the same as previous figure.

Current conclusion: we should use Heuristics larger than 0.5. 

Examine `DegenMoves` (degenerate simplex moves)

Limits degenerate simplex moves. These moves are performed to improve the integrality of the current relaxation solution. By default, the algorithm chooses the number of moves to perform automatically.

Changing the value of this parameter can help performance in cases where an excessive amount of time is spent after the initial root relaxation has been solved but before the cut generation process or the root heuristics have started.

Parameter range:

• -1 (default)
• 0 (fiducial)
• 1
• 2
• 3

Here is the comparison of the total execution time in sec.

Color is the same as previous figure.

Current conclusion: we should use DegenMoves = 0. 

Examine `Method` (algorithm used to solve continuous models)

Algorithm used to solve continuous models or the root node of a MIP model. Options are: -1=automatic, 0=primal simplex, 1=dual simplex, 2=barrier, 3=concurrent, 4=deterministic concurrent, 5=deterministic concurrent simplex.

In the current release, the default Automatic (-1) setting will typically choose non-deterministic concurrent (Method=3) for an LP, barrier (Method=2) for a QP or QCP, and dual (Method=1) for the MIP root node. Only the simplex and barrier algorithms are available for continuous QP models. Only primal and dual simplex are available for solving the root of an MIQP model. Only barrier is available for continuous QCP models.

Concurrent optimizers run multiple solvers on multiple threads simultaneously, and choose the one that finishes first. Method=3 and Method=4 will run dual simplex, barrier, and sometimes primal simplex (depending on the number of available threads). Method=5 will run both primal and dual simplex. The deterministic options (Method=4 and Method=5) give the exact same result each time, while Method=3 is often faster but can produce different optimal bases when run multiple times.

The default setting is rarely significantly slower than the best possible setting, so you generally won't see a big gain from changing this parameter. There are classes of models where one particular algorithm is consistently fastest, though, so you may want to experiment with different options when confronted with a particularly difficult model.

Note that if memory is tight on an LP model, you should consider using the dual simplex method (Method=1). The concurrent optimizer, which is typically chosen when using the default setting, consumes a lot more memory than dual simplex alone.

Parameter Range:

• -1 (default)
• 0 
• 1
• 2
• 3
• 4 (fiducial)
• 5

Here is the comparison of the total execution time in sec.

Color is the same as previous figure.

Current conclusion: we should use Method = 4.

Examine `Presolve` (controls the presolve level)

Controls the presolve level. A value of -1 corresponds to an automatic setting. Other options are off (0), conservative (1), or aggressive (2). More aggressive application of presolve takes more time, but can sometimes lead to a significantly tighter model.

 Parameter Range:

• -1 (default)
• 0 
• 1
• 2 (fiducial)

Here is the comparison of the total execution time in sec.

Color is the same as previous figure.

Current conclusion: we should use Presolve=2 or -1 (default).
 

Examine `MIPFocus` (MIP solver focus)

The MIPFocus parameter allows you to modify your high-level solution strategy, depending on your goals. By default, the Gurobi MIP solver strikes a balance between finding new feasible solutions and proving that the current solution is optimal. If you are more interested in finding feasible solutions quickly, you can select{{MIPFocus=1}}. If you believe the solver is having no trouble finding good quality solutions, and wish to focus more attention on proving optimality, select MIPFocus=2. If the best objective bound is moving very slowly (or not at all), you may want to try MIPFocus=3 to focus on the bound.

Parameter range:

• 0 (default/fiducial)
• 1
• 2
• 3

Here is the comparison of the total execution time in sec.

Color is the same as previous figure.

Current conclusion: we should use the default value.

Examine `Cuts` (global cut control)

Global cut aggressiveness setting. Use value 0 to shut off cuts, 1 for moderate cut generation, 2 for aggressive cut generation, and 3 for very aggressive cut generation. This parameter is overridden by the parameters that control individual cut types (e.g., CliqueCuts).

Parameter range:

• -1 (default/fiducial)
• 0
• 1
• 2
• 3

Here is the comparison of the total execution time in sec.

Color is the same as previous figure.

Current conclusion: we should use the default value.
 

Examine `Threads` (thread count)

Controls the number of threads to apply to parallel algorithms (concurrent LP, parallel barrier, parallel MIP, etc.). The default value of 0 is an automatic setting. It will generally use all of the cores in the machine, but it may choose to use fewer.

While you will generally get the best performance by using all available cores in your machine, there are a few exceptions. One is of course when you are sharing a machine with other jobs. In this case, you should select a thread count that doesn't oversubscribe the machine.

We have also found that certain classes of MIP models benefit from reducing the thread count, often all the way down to one thread. Starting multiple threads introduces contention for machine resources. For classes of models where the first solution found by the MIP solver is almost always optimal, and that solution isn't found at the root, it is often better to allow a single thread to explore the search tree uncontended.

Another situation where reducing the thread count can be helpful is when memory is tight. Each thread can consume a significant amount of memory.

Parameter range:

• 1 
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 16
• 24
• 28 (default/fiducial)

Here is the comparison of the total execution time in sec.

Color is the same as previous figure.

Current conclusion: we should use Thread>4.

Now I found that there was `ConcurrentMIP` which solves MIP concurrently. I'll take a look at this parameter.

The current default params in the survey simulator are:

• Presolve=0
• Method=4
• DegenMoves=0
• Heuristics=0.8
• MIPFocus=0
• NumericFocus=0
• ScaleFlag=2
• ObjScale=-0.5
• Quad=1
• MarkowitzTol=0.5

Note that these parameters were optimized for specific cases, though...