Originally posted by: SystemAdmin

[arunjotshi said:]

I am trying to solve an Integer Program using AMPL/CPLEX and am getting the following results:

Presolve eliminates 13485 constraints and 50262 variables.
Adjusted problem:
39199 variables:
        37526 binary variables
        1673 integer variables
6260 constraints, all linear; 331256 nonzeros
1 linear objective; 36137 nonzeros.

Setting $presolve_inteps < 5.63e-07 or >= 1.49e-06
could change presolve results.

CPLEX 10.1.0: MipThreads=4
timing=1
timelimit = 1800
branch=-1
mipemphasis =1
HeurFreq = 10
treememlim=6000
mipdisplay=2
mipgap=0.02
display=2
Retaining MIP start values for possible repair.
MIP Presolve eliminated 4866 rows and 35218 columns.
MIP Presolve modified 57716 coefficients.
Reduced MIP has 1001 rows, 3588 columns, and 15997 nonzeros.
Clique table members: 1304.
MIP emphasis: integer feasibility.
Root relaxation solution time =    0.22 sec.

        Nodes                                        Cuts/
  Node  Left    Objective  IInf  Best Integer    Best Node    ItCnt    Gap

      0    0  232497.7769  188                232497.7769      542
                218399.4938    99                  Cuts:  750      745
                216708.1678    46                  Cuts:  116      823
                216641.3666    44                    Cuts:  8      858
*    0+    0                  0  211391.7500  216641.3666      858    2.48%
Repair heuristic found nothing.
    100    52  211703.5425    22  211391.7500  216630.8605    2067    2.48%
*  101    52                  0  211698.2500  216630.8605    2098    2.33%
*  101+  52                  0  212035.2500  216630.8605    2098    2.17%
*  151    69                  0  213155.0000  216593.6264    2616    1.61%
*  151+  68                  0  213492.0000  216593.6264    2642    1.45%

Root node processing (before b&c):
  Real    time            =    8.90
Parallel b&c, 4 threads:
  Real    time            =    0.54
  Critical time (total)    =    0.01
  Spin    time (average)  =    0.05
                              -------
Total (root+branch&cut)    =    9.44 sec.

GUB cover cuts applied:  13
Clique cuts applied:  179
Cover cuts applied:  19
Implied bound cuts applied:  10
Flow cuts applied:  1
Mixed integer rounding cuts applied:  6
Gomory fractional cuts applied:  31
Using steepest-edge.

Iteration          Objective            In Variable          Out Variable
    1 sI            0.062500                x15724    goes to upper bound
    2 sI            0.062500                x13429    goes to upper bound
    3 sI            0.062500                x14679    goes to upper bound
    4 sI            0.062500                x13417    goes to upper bound
    5 sI            0.062500                x29616    goes to upper bound
. .
. . OTHER SUCH ITERATIONS
. .

  4650 sI            0.062500                x34976    goes to upper bound
  4651 sI            0.062500                x35554    goes to upper bound
  4652 sI            0.062500                x31499    goes to upper bound

Times (seconds):
Input =  0.57
Solve =  9.36
Output = 0.67
CPLEX 10.1.0: optimal integer solution within mipgap or absmipgap; objective 0.0
625
2699 MIP simplex iterations
159 branch-and-bound nodes
absmipgap = 3101.63, relmipgap = 0.0145281
Status recovering solution: infeasible problem
Tried aggregator 3 times.

AMPL LOG says  :
CPLEX solution status 3 with fixed integers:    infeasible problem


Please explain what is happening here.


Also, when I tried to run it again, the run went fine without any complaints.

Please suggest.

Thanks in advance,
Arun


#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[MaryFenelon said:]

It appears that AMPL solves the fixed version of the problem (all integer and binary variables are fixed to the values they have in the incumbent solution) before returning a solution and this fixed problem is infeasible.  This is probably due to numerical issues--the warning from AMPL about presolve tolerances is a clue that there are some.  You could try turning off the AMPL presolve and let CPLEX do all the presolving instead, but there's no guarantee that would help.

The different results from run to run are due to the use of parallel branch & cut.  The synchronization between the threads does not occur exactly in the same way each time since it is dependent on interactions with the operating system, and so the paths differ from run to run.  This non-reproducibility is why the "deterministic" parallel mode was introduced in CPLEX 11.  The synchronization between threads in deterministic parallel mode only occurs at certain set points independent of operating system conditions, and so runs can be repeated with identical paths. 


#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[arunjotshi said:]

Thanks Mary Fenelon.
Turns out that it indeed is due to the numerical issues. Turning off the AMPL presolve did help.
Seems AMPL Presolve was distorting the problem and giving inconsistent results.
Regards,
Arun.
#CPLEXOptimizers
#DecisionOptimization