Originally posted by: Michael_D

CPLEX can be used as LP solver within the ABACUS branch-cut-price framework. There is an ABACUS function for setting the CPLEX LP method. I have set it to BarrierAndCrossover and this has worked fine for all projects so far. Now, for some, but not all, instances of a new problem, CPLEX hangs. Setting the LP method to Primal oder Dual works.

There's been this post: https://www.ibm.com/developerworks/community/forums/html/topic?id=0b6c9a35-b388-441b-a28e-013ad277fe62&ps=25, reporting a similar problem. However, I am using CPLEX 12.6, and still the problem occurs. The instances are tiny, some hundred variables and some hundred constraints.

A sample output is:

...

Optimization progress:

      #sub      #open   lower bound     upper bound           gap      cpu time

Tried aggregator 1 time.

LP Presolve eliminated 19 rows and 16 columns.

All rows and columns eliminated.

Presolve time = 0.00 sec. (0.01 ticks)

Barrier time = 0.00 sec. (0.01 ticks)

 

Total time on 4 threads = 0.00 sec. (0.01 ticks)

 

Primal crossover.

  Primal:  Fixed no variables.

  Dual:  Fixing 2 variables.

        1 DMoves:  Infeasibility 0.00000000e+000  Objective 9.00000000e+008

        0 DMoves:  Infeasibility 0.00000000e+000  Objective 9.00000000e+008

  Dual:  Pushed 2, exchanged 0.

Using devex.

Total crossover time = 0.01 sec. (0.01 ticks)

 

Total time on 4 threads = 0.01 sec. (0.01 ticks)

1056

Tried aggregator 1 time.

LP Presolve eliminated 0 rows and 541 columns.

Reduced LP has 19 rows, 531 columns, and 4925 nonzeros.

Presolve time = 0.00 sec. (1.01 ticks)

Parallel mode: using up to 4 threads for barrier.

Number of nonzeros in lower triangle of A*A' = 122

Using Approximate Minimum Degree ordering

Total time for automatic ordering = 0.00 sec. (0.11 ticks)

Summary statistics for Cholesky factor:

  Threads                   = 4

  Rows in Factor            = 19

  Integer space required    = 19

  Total non-zeros in factor = 190

  Total FP ops to factor    = 2470

 Itn      Primal Obj        Dual Obj  Prim Inf Upper Inf  Dual Inf Inf Ratio

   0 -1.#IND000e+000 -1.#IND000e+000 4.14e+004 9.48e+003 1.#Re+000 1.00e+000

   1 -1.#IND000e+000 -1.#IND000e+000 1.#Re+000 1.#Re+000 1.#Re+000 -1.#Je+000

   2 -1.#IND000e+000 -1.#IND000e+000 1.#Re+000 1.#Re+000 1.#Re+000 -1.#Je+000

   3 -1.#IND000e+000 -1.#IND000e+000 1.#Re+000 1.#Re+000 1.#Re+000 -1.#Je+000

   4 -1.#IND000e+000 -1.#IND000e+000 1.#Re+000 1.#Re+000 1.#Re+000 -1.#Je+000

   5 -1.#IND000e+000 -1.#IND000e+000 1.#Re+000 1.#Re+000 1.#Re+000 -1.#Je+000

   6 -1.#IND000e+000 -1.#IND000e+000 1.#Re+000 1.#Re+000 1.#Re+000 -1.#Je+000

   7 -1.#IND000e+000 -1.#IND000e+000 1.#Re+000 1.#Re+000 1.#Re+000 -1.#Je+000

   8 -1.#IND000e+000 -1.#IND000e+000 1.#Re+000 1.#Re+000 1.#Re+000 -1.#Je+000

   9 -1.#IND000e+000 -1.#IND000e+000 1.#Re+000 1.#Re+000 1.#Re+000 -1.#Je+000

  10 -1.#IND000e+000 -1.#IND000e+000 1.#Re+000 1.#Re+000 1.#Re+000 -1.#Je+000

  11 -1.#IND000e+000 -1.#IND000e+000 1.#Re+000 1.#Re+000 1.#Re+000 -1.#Je+000

  12 -1.#IND000e+000 -1.#IND000e+000 1.#Re+000 1.#Re+000 1.#Re+000 -1.#Je+000

... goes on like this

#CPLEXOptimizers
#DecisionOptimization

Hard to tell what is going on here. Could you provide the offending model as LP (or even better SAV) file? Either attach it here or send it directly to me daniel(dot)junglas(at)de(dot)ibm(dot)com.

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: Michael_D

When trying to output the model from within ABACUS, it turned out that actually the problem is a data issue: The offending instances create a 'not-a-number' coefficient in the pricing routine. Using CPXwriteprob for creating an lp or sav file, Cplex outputs error 1650 CPXERR_INVALID_NUMBER, and no model is output.

Using 'BarrierAndCrossover' as ABACUS-LP-solving method calls CPXbaropt, and this method has a problem with instances with such NaN-coefficients. Using 'Primal' or 'Dual' as ABACUS-LP-solving method calls CPXprimopt or CPXdualopt respectively, and these somehow manage to deal with NaN-coefficients.

Thus, of course, the correct procedure would have been for the user, that is, me, to do proper data checking beforehand. Sorry for not doing that. Anyway, perhaps you might want to take a look at why CPXprimopt or CPXdualopt tolerate such erroneous data while CPXbaropt doesn't.

#CPLEXOptimizers
#DecisionOptimization

That barrier chokes on NaN while simplex does not may be pure luck. It may also be that simplex completes but actually delivers incorrect answers (whatever "correct" answers may be for a problem containing NaNs).

You probably want to set CPX_PARAM_DATACHECK to 1, at least for development. Among other things, this makes CPLEX check for NaNs in the input data, so that you can catch similar problems much earlier.

#CPLEXOptimizers
#DecisionOptimization