Originally posted by: SystemAdmin

Dear all,
I found the Interactive Optimizer will behavior different (constructing a different B&B tree) from what concert technology C++ behaviors even they are both set to default settings. And also the results for presolve are also different
1. concert technology C++ (I terminated it before it reached the criteria)

Warning:  Output names have been modified to conform to LP format.
Tried aggregator 3 times.
MIP Presolve eliminated 96136 rows and 32190 columns.
MIP Presolve modified 44846 coefficients.
Aggregator did 2691 substitutions.
Reduced MIP has 23578 rows, 15033 columns, and 90550 nonzeros.
Reduced MIP has 6670 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time =    0.58 sec.
Clique table members: 7953.
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.
Parallel mode: none, using 1 thread.
Root relaxation solution time =    1.81 sec.
 
        Nodes                                         Cuts/ 
   Node  Left     Objective  IInf  Best Integer     Best Node    ItCnt     Gap
 
      0     0    -3867.6549   212                  -3867.6549     9237
      0     0    -3912.8832   352                   Cuts: 259    12373
      0     0    -3915.9553   284                    Cuts: 17    13263
      0     0    -3917.2120   291                    Cuts: 12    13429
      0     0    -3919.0078   133                    Cuts: 15    13755
      0     0    -3922.4619   313                    Cuts: 12    14675
      0     0    -3922.6113   311                     Cuts: 6    14747
      0     0    -3922.6116   312                  -3922.6116    14839
Heuristic still looking.
*     0+    0                        -5884.8694    -3922.6116    14839   33.34%
*     0+    0                        -4546.3852    -3922.6116    14839   13.72%
*     0+    0                        -4288.0517    -3922.6116    14839    8.52%
      0     2    -3922.6331   311    -4288.0517    -3922.6466    14839    8.52%
Elapsed time =  33.74 sec. (tree size =  0.00 MB, solutions = 3)
    100    59    -4246.0945    32    -4288.0517    -3930.8057    35830    8.33%
*   120+   62                        -4271.0615    -3930.8057    36105    7.97%
    200   124    -4021.2249    54    -4271.0615    -4005.8284    47731    6.21%
*   220+  109                        -4233.6809    -4005.8284    49581    5.38%
*   220+   93                        -4221.0642    -4005.8284    49581    5.10%
*   230+   75                        -4162.8910    -4005.8284    49852    3.77%
    300   126    -4150.2773    82    -4162.8910    -4014.6907    57814    3.56%
*   330+  145                        -4159.5630    -4016.8231    59263    3.43%
    400   207    -4080.7233    16    -4159.5630    -4018.7018    66575    3.39%
    500   254    -4043.0379    14    -4159.5630    -4018.7422    85097    3.39%
    600   263    -4139.6006    72    -4159.5630    -4018.7422   108176    3.39%
    700   275    -4046.2623    20    -4159.5630    -4031.3686   126165    3.08%
    800   324    -4071.5380    36    -4159.5630    -4033.0009   149774    3.04%
    900   365    -4056.5519    40    -4159.5630    -4034.5511   168725    3.01%
   1000   422    -4089.4357    20    -4159.5630    -4036.2446   192337    2.96%
Elapsed time = 371.36 sec. (tree size =  2.74 MB, solutions = 8)
   1100   505    -4076.7388    18    -4159.5630    -4036.5690   211473    2.96%
   1200   588    -4101.9005    36    -4159.5630    -4036.9977   232528    2.95%
   1300   664    -4072.9585    15    -4159.5630    -4038.2808   248759    2.92%
   1400   741    -4081.1237    37    -4159.5630    -4038.6999   273090    2.91%
   1500   829    -4082.5354    44    -4159.5630    -4039.0745   298466    2.90%
   1600   917    -4068.9927    31    -4159.5630    -4039.5020   320916    2.89%
   1700  1006    -4118.5597    20    -4159.5630    -4039.7304   346754    2.88%
   1800  1089    -4053.9877    15    -4159.5630    -4039.9640   374221    2.88%
   1900  1173    -4069.3506    37    -4159.5630    -4040.0418   396278    2.87%
   2000  1256    -4056.8343    15    -4159.5630    -4040.6463   423902    2.86%
Elapsed time = 668.20 sec. (tree size =  8.26 MB, solutions = 8)
   2100  1348    -4072.7735    44    -4159.5630    -4040.7619   453302    2.86%
^CPress any key to continue . . .

2. Interactive Optimizer (I terminated it before it reached the criteria)

Tried aggregator 3 times.
MIP Presolve eliminated 102597 rows and 36745 columns.
MIP Presolve modified 43046 coefficients.
Aggregator did 2071 substitutions.
Reduced MIP has 17737 rows, 11023 columns, and 66025 nonzeros.
Reduced MIP has 4740 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time =    0.47 sec.
Clique table members: 6068.
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.
Parallel mode: none, using 1 thread.
Root relaxation solution time =    1.06 sec.
 
        Nodes                                         Cuts/ 
   Node  Left     Objective  IInf  Best Integer     Best Node    ItCnt     Gap
 
      0     0    -3911.4882    76                  -3911.4882     6009
      0     0    -3949.2019   577                    Cuts: 88    11456
      0     0    -3965.0464   709                    Cuts: 46    13355
      0     0    -3967.7768   824                    Cuts: 35    14378
      0     0    -3968.5820   770                Impl Bds: 10    14800
      0     0    -3968.5925   768                     Cuts: 3    14806
*     0+    0                        -4419.7996    -3968.5925    14806   10.21%
*     0+    0                        -4411.5278    -3968.5925    14806   10.04%
*     0+    0                        -4410.9244    -3968.5925    14806   10.03%
*     0+    0                        -4384.7171    -3968.5925    14806    9.49%
*     0+    0                        -4380.0706    -3968.5925    14806    9.39%
*     0+    0                        -4379.3847    -3968.5925    14806    9.38%
      0     2    -3968.6146   764    -4379.3847    -3969.9123    14806    9.35%
Elapsed time =  37.03 sec. (tree size =  0.00 MB, solutions = 6)
    100    86    -4103.6862    21    -4379.3847    -3983.5382    41915    9.04%
    200   134    -4059.4021    20    -4379.3847    -4033.5927    79418    7.90%
*   290+  151                        -4183.3280    -4036.8005   108261    3.50%
    300   157    -4056.2118    52    -4183.3280    -4037.2554   109238    3.49%
*   390+  218                        -4172.9643    -4038.1448   129219    3.23%
    400   228    -4086.0952    37    -4172.9643    -4038.1448   131384    3.23%
    500   304    -3979.8586    56    -4172.9643    -4039.3379   159447    3.20%
 
GUB cover cuts applied:  1
Implied bound cuts applied:  62
Flow cuts applied:  46
Mixed integer rounding cuts applied:  23
Gomory fractional cuts applied:  5
 
Solution pool: 8 solutions saved.
 
MIP - Aborted, integer feasible:  Objective = -4.1729643142e+003
Current MIP best bound = -4.0393379482e+003 (gap = 133.626, 3.20%)
Solution time =  316.70 sec.  Iterations = 162340  Nodes = 502 (304)

Thanks for any help
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

How did you supply the problem to the interactive optimizer? Did you have the C++ code write it out, and if so, in what format (LP, MPS or SAV)?

/Paul
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Hi, Paul
For Interactive Optimizer,
I did this way
CPLEX> read mymodel.lp
CPLEX> set defaults
CPLEX> mipopt

For Concert Technology C++
I did this way
IloCplex cplex(modelmodel_index);
char *name_buffer = new char200;//this might not impact
sprintf(name_buffer, "%u_%s", model_index, name);//this might not impact
cplex.exportModel(name_buffer);//this might not impact, I just want to see the .lp file generated for debugging
cplex.extract(modelmodel_index);//this might not impact
cplex.setDefaults();
cplex.solve();

Thank you very much
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Please use the *.sav file format to store the model. Using the *.lp format can change subtle things in your model when you read it back in, like the ordering of columns and rows, and the truncation of floating point values in the coefficients.

These subtle changes can (and typically will) change the search tree.

Tobias
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

For my model, I found to read .lp files would perform better than .sav files in terms of solution time within the same relative gap. Will .lp format be necessarily better than .sav for CPLEX to solve? I also noticed that you mentioned different truncation of floating point values, will this result in solutions violating the constraints for my original model, if so ,which format will? Thank you very much
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

The binary sav format gives you a bit-by-bit identical snapshot of your model.

The human-readable lp and mps formats will implicitly change your model when you write them and read them back in. The changes are:

1. In the lp format, the order of columns can change because it is a row based format and only preserves row order. In the mps format, the order of rows can change because it is a column based format and only preserves column order. The changes in the order of rows and columns does not change the set of solutions to your model, but it does change the search tree that CPLEX constructs and thereby can have a major (random!) impact on performance.

2. Floating point values are potentially truncated, because of the limited precision that is used for printing numbers to those text format files. This means that your model will actually change! If the model is very sensitive in terms of numerics, such changes can have a significant impact on the set of solutions and also on the run-time performance of CPLEX.

So, if human readability is not an issue, you should always use the sav format.

The fact that the .lp files perform batter than the .sav files can only have one of the two reasons above: either it is just a random performance change due to reordering of rows and columns, or you are really facing floating point value truncation and you are actually solving two different models.
Tobias
#CPLEXOptimizers
#DecisionOptimization