# LP Cutting Planes in CPLEX

Written by: Paul Rubin

Primary Source: OR in an OB World

Cut generation, as used in what follows, refers to generating constraints for a mathematical program “on the fly” (based on intermediate solutions), rather than adding all relevant constraints at the outset of the problem. It is typically used when  there is an astronomical number of possible constraints, most of which will turn out not to be very useful.

Someone recently asked me which is faster in CPLEX when solving a linear program with cut generation:

• solving the LP, adding cuts, solving the LP again …; or
• using a callback to add the cuts on the fly.

My initial guess (which I think proved correct) was that the first method is likely to be faster, or at least not notably slower, then the second method, but I suppose it might be possible for the second method to win if problems are large. (I’m not at all confident about that last point.)

What makes the “solve – cut – repeat” loop competitive is that CPLEX can, and with default settings does, “warm start” the solution of a linear program based on the most recent previous solution of the model. The model can be changed between calls to the solver, so long as CPLEX recognizes that it is the same problem. Generally, warm starting after adding (or removing) constraints expedites the solution process (relative to starting from scratch) if the number of changes is fairly modest.

The second method involves attaching a lazy constraint callback to the model. Each time a potential new optimum for the LP is found, the solution will be passed to the callback, which can either reject the solution by adding one or more constraints (cuts), at least one of which renders the candidate solution infeasible, or accept the solution by refraining from adding any new cuts. The original LP now becomes the root node “relaxation” of the problem. CPLEX will never attempt to branch, since there are no integer variables in the LP (and thus none that will take on fractional values), so once the root node is optimized, we’re done.

A bit of trickery is required for the second method, since the lazy constraint callback is available only for integer and mixed integer programs. We can spoof CPLEX by adding a single integer or binary variable to the model, but not including it in any constraints or in the objective function. This works in the various programming APIs, where there is a method to add an object (in this case our dummy variable) directly to the model. In the interactive optimizer, it may be necessary to add a vacuous constraint as well. For example, if we add a dummy binary variable z, we can use the constraint z≤1 to force z into the model (and convince CPLEX the model is an integer program) without affecting the optimal solution.

I tested this with a couple of small convex optimization problems, using a rather old school cutting plane method. The problems take the form

opts.t.c′xAxg(x)x≤≤∈bhRn+

whereg:Rn+→Rm is convex and differentiable and “opt” denotes either maximization or minimization. The initial linear program omits the constraint(s)g(x)≤h. When a candidate solutionx^ is obtained, we plug it into eachgi(). Ifgi(x^)>hi by more than some rounding tolerance, we add the constraint

∇gi(x^)x≤hi−gi(x^)+∇gi(x^)x^.

If multiple constraints are violated, we can add just one cut or (as I did in my tests) simultaneously add a cut for each violated constraint.

I wrote a test program in Java (for which the source code is available), using two test problems:

maxs.t.3×1+x2x1+x2x21+x2x≤≤≥310

and

maxs.t.3×1+x2+4x3x1x2x3x21−x2−2×2+x43x≤≤≤≤≤≥555300.

My code recorded execution times for the CPLEX 12.5.1 solver using both methods, excluding time spent setting up the models, time spent reporting the results, and time spent generating the cuts. (Time spent adding the cuts to the models was included.)

The problems are both very small, so their execution times (which varied significantly during repeated runs of the same models) may not be indicative of what happens on more difficult problems. On the first problem, the first method usually beat the second method by a small margin (typically about 6 milliseconds v. 7 milliseconds), but I did see an occasional win for the second method (by about 1 ms.). On the second problem, the first method consistently beat the second method, usually by one or two milliseconds, occasionally by a bit more. The number of cuts generated (five in the first problem, eleven in the second) did not vary between methods, nor did the optimal solution reported.

The following two tabs change content below. #### Paul Rubin

Professor Emeritus at Michigan State University
I'm an apostate mathematician, retired from a business school after 33 years of teaching mostly (but not exclusively) quantitative methods courses. My academic interests lie in operations research. I also study Tae Kwon Do a bit on the side. 