Tuning Barrier Optimizer Performance

Naturally, the default parameter settings for the ILOG CPLEX Barrier Optimizer work best on most problems. However, you can tune several algorithmic parameters to improve performance or to overcome numerical difficulties. These parameters are described in the sections:

In addition, several parameters set termination criteria. With them, you control when ILOG CPLEX stops optimization.

You can also control convergence tolerance-another factor that influences performance. Convergence tolerance determines how nearly optimal a solution ILOG CPLEX must find: tight convergence tolerance means ILOG CPLEX must keep working until it finds a solution very close to the optimal one; loose tolerance means ILOG CPLEX can return a solution within a greater range of the optimal one and thus stop calculating sooner.

Performance of the ILOG CPLEX Barrier Optimizer is most highly dependent on the size of the Cholesky factor computed at each iteration. When you adjust barrier parameters, always check their impact on the size of the Cholesky factor. At default output settings, this size is reported at the beginning of each barrier optimization in the log file, as we explain in Cholesky Factor in the Log File.

Another important performance issue is the presence of dense columns. By a dense column, we mean that a given variable appears in a relatively large number of rows. You can check column density as we suggest in Step 3. We also say more about column density in Detecting and Eliminating Dense Columns.

In adjusting parameters, you may need to experiment to find beneficial settings because the precise effect of parametric changes will depend on the nature of your LP problem as well as your platform (hardware, operating system, compiler, etc.). Once you have found satisfactory parametric settings, keep them in a parameter specification file for re-use, as explained in Saving a Parameter Specification File.

Out-of-Core Barrier: Letting the Optimizer Use Disk for Storage

Under default settings, the CPLEX Barrier Optimizer will do all of its work using central memory (variously referred to also as RAM, core, or physical memory). For models too large to solve in the central memory on your computer, or in cases where it is simply not desired to use this much memory, it is possible to instruct the barrier optimizer to use disk for part of the working storage it needs, specifically the Cholesky factorization. Since disk is slower than central memory, there may be some lost performance by making this choice on models that could be solved entirely in central memory, but the out-of-core feature in the CPLEX Barrier Optimizer is designed to make this as efficient as possible. It generally will be far more effective than relying on the operating system's virtual memory (swap space).

To activate out-of-core Barrier:

Even when out-of-core Barrier is activated, the factorization will stay in central memory unless its size exceeds the value of the Working Memory parameter. The default for this parameter is 128, meaning 128 megabytes.

To select a different threshold for use of disk working storage, say 32 megabytes:

When Barrier is being run out-of-core, the location of disk storage is controlled by the Working Directory parameter. For example, if you wish to use the directory /tmp/mywork for this purpose, where this directory already exists at the start of the CPLEX Barrier run:

Preprocessing: the Presolver and Aggregator

For best performance of the ILOG CPLEX Barrier Optimizer, preprocessing should almost always be on. That is, we recommend that you use the default setting where the presolver and aggregator are active. While they may use more memory, they also reduce the problem, and problem reduction is crucial to barrier optimizer performance. In fact, reduction is so important that even when you turn off preprocessing, ILOG CPLEX still applies minimal presolving before barrier optimization.

For problems that contain linearly dependent rows, it is a good idea to turn on the preprocessing dependency parameter. (By default, it is off.) This dependency checker may add some preprocessing time, but it can detect and remove linearly dependent rows to improve overall performance.

To turn on the preprocessing dependency parameter:

Detecting and Eliminating Dense Columns

Dense columns can significantly degrade barrier optimizer performance. (A dense column is one in which a given variable appears in many rows.) For that reason, we recommend that after you enter or read a problem for barrier optimization, you check it for dense columns by inspecting its column histogram after preprocessing, as in Step 3.

In fact, when a few dense columns are present in a problem, it is often effective to reformulate the problem to remove those dense columns from the model.

Otherwise, you can control whether ILOG CPLEX perceives columns as dense by setting the column nonzeros parameter. At its default setting, ILOG CPLEX calculates an appropriate value for this parameter automatically. However, if your problem contains one (or a few) dense columns that remain undetected at the default setting, you can adjust this parameter yourself to help ILOG CPLEX detect it (or them). For example, in a large problem in which one column contains forty entries while the other columns contain less than five entries, you will benefit by setting the column nonzeros parameter to 30. This setting allows ILOG CPLEX to recognize that column as dense and thus invoke techniques to handle it.

To set the column nonzeros parameter:

Once ILOG CPLEX detects a dense column, it takes steps to eliminate it.

Choosing an Ordering Algorithm

ILOG CPLEX offers several different algorithms in the CPLEX Barrier Optimizer for ordering the rows of a matrix:

The log file, as we explain in Ordering-Algorithm Time in the Log File, records the time spent by the ordering algorithm in a barrier optimization, so you can experiment with different ordering algorithms and compare their performance on your problem.

Automatic ordering, the default option, will usually be the best choice. This option attempts to choose the most effective of the available ordering methods, and it usually results in the best order. It may require more time than the other settings. The ordering time is usually small relative to the total solution time, and a better order can lead to a smaller total solution time. In other words, a change in this parameter is unlikely to improve performance very much.

The AMD algorithm provides good quality order within moderate ordering time. AMF usually provides better order than AMD (usually 5-10% smaller factors) but it requires somewhat more time (10-20% more). ND often produces significantly better order than AMD or AMF. Ten-fold reductions in runtimes of the ILOG CPLEX Barrier Optimizer have been observed with it on some problems. However, ND sometimes produces worse order, and it requires much more time.

To change from one ordering algorithm to another:

Using a Starting-Point Heuristic

ILOG CPLEX supports several different heuristics to compute the starting point for the ILOG CPLEX Barrier Optimizer. Table 4.12 summarizes the parameter values to indicate which starting-point heuristic to use.

Table 4.12 Parameter Values for Starting-Point Heuristics

Value 
Heuristic 
1 
dual is 0 (default) 
2 
estimate dual 
3 
average primal estimate, dual 0 
4 
average primal estimate, estimate dual 

For most problems the default works well. Indeed, changing the starting-point heuristic may even worsen performance overall. However, if you are using the dual preprocessing option (for example, set preprocessing dual 1), then one of the other heuristics for computing a starting point may perform better than the default.

To change the starting point heuristic:


Previous Page: Understanding Solution Quality from the Barrier LP Optimizer  Return to Top Next Page: Overcoming Numerical Difficulties