Java Cplex結果與IBM Optimization Studio不同

Question

我使用OPL在IBM Optimization Studio中實現了LP問題，以創建模型。 驗證模型后，我想將其放入Java中以編寫參數腳本以進行仿真。 我找到了使用以下代碼在Java中使用OLP模型的最快方法：

IloOplFactory.setDebugMode(false);
IloOplFactory oplF = new IloOplFactory();
IloOplErrorHandler errHandler = oplF.createOplErrorHandler(System.out);
IloOplModelSource modelSource = oplF.createOplModelSource("myModel.mod");
IloCplex cplex = null;
cplex = oplF.createCplex();
IloOplSettings settings = oplF.createOplSettings(errHandler);
IloOplModelDefinition def = oplF.createOplModelDefinition(modelSource, settings);
IloOplModel opl = oplF.createOplModel(def, cplex);

String inDataFile = "myData.dat";
IloOplDataSource dataSource = oplF.createOplDataSource(inDataFile);
opl.addDataSource(dataSource);

opl.generate();
opl.convertAllIntVars(); // converts integer bounds into LP compatible format
if (cplex.solve()) {
        double obj = opl.getCplex().getObjValue();
        System.out.println("OBJECTIVE: " + obj);
}

現在的問題是，如果我在IBM Optimization Studio和Java中都運行“ myModel.mod”和“ myData.dat”，則會得到非常不同的客觀結果。

在IBM Optimization Studio中：

solution (optimal) with objective 125

在Java中：

Parallel mode: deterministic, using up to 4 threads for concurrent optimization.
Tried aggregator 1 time.
LP Presolve eliminated 0 rows and 1 columns.
Reduced LP has 5280 rows, 5325 columns, and 25525 nonzeros.
Presolve time = 0.01 sec. (3.77 ticks)

Iteration log . . .
Iteration:     1   Dual objective     =             0.000000
Iteration:   345   Dual objective     =            90.297455
Iteration:   568   Dual objective     =           117.206047
Perturbation started.
Iteration:   707   Dual objective     =           117.206047
Removing perturbation.
Reinitializing dual norms . . .

Dual simplex solved model.

OBJECTIVE: 117.20608137232513

我查看了數據集和模型，甚至不可能達到小於125的目標（我使用了極值來確保我的目標變量之一是125，因此任何低於該值的情況都不可能實現）。

有誰知道為什么這些結果不同？ 與IBM相比，Java設置中是否有某些功能？ 是否可以將我的IBM Optimization Studio設置導入Java進行測試？

謝謝！

編輯：這是IBM Optimization Studio日志，我忘了包括這些。 它確實顯示了有關整數被截取的更多信息，但這是我對這兩個程序的初次體驗，因此有人可以幫助我確定問題出在哪里或這意味着什么？

Found incumbent of value 125.000000 after 0.00 sec. (0.53 ticks)
Tried aggregator 1 time.
MIP Presolve eliminated 5027 rows and 4764 columns.
MIP Presolve modified 1191 coefficients.
Reduced MIP has 253 rows, 562 columns, and 1958 nonzeros.
Reduced MIP has 562 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.02 sec. (8.46 ticks)
Probing fixed 8 vars, tightened 0 bounds.
Probing time = 0.00 sec. (2.86 ticks)
Tried aggregator 1 time.
MIP Presolve eliminated 158 rows and 306 columns.
MIP Presolve modified 293 coefficients.
Reduced MIP has 95 rows, 256 columns, and 632 nonzeros.
Reduced MIP has 256 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.02 sec. (1.73 ticks)
Probing fixed 6 vars, tightened 0 bounds.
Probing time = 0.00 sec. (0.12 ticks)
Tried aggregator 1 time.
MIP Presolve eliminated 29 rows and 30 columns.
MIP Presolve modified 2 coefficients.
Reduced MIP has 66 rows, 226 columns, and 522 nonzeros.
Reduced MIP has 226 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.00 sec. (0.42 ticks)
Probing time = 0.00 sec. (0.07 ticks)
Clique table members: 34.
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.
Parallel mode: deterministic, using up to 4 threads.
Root relaxation solution time = 0.00 sec. (0.36 ticks)

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

*     0+    0                          125.0000      123.0000             1.60%
      0     0      123.8469     4      125.0000      123.8469       62    0.92%
      0     0        cutoff            125.0000                     81    0.00%
Elapsed time = 0.09 sec. (17.09 ticks, tree = 0.00 MB, solutions = 1)

Zero-half cuts applied:  1
Gomory fractional cuts applied:  1

Root node processing (before b&c):
  Real time             =    0.09 sec. (17.22 ticks)
Parallel b&c, 4 threads:
  Real time             =    0.00 sec. (0.00 ticks)
  Sync time (average)   =    0.00 sec.
  Wait time (average)   =    0.00 sec.
                      ------------
Total (root+branch&cut) =    0.09 sec. (17.22 ticks)

編輯2：我發現矩陣0..1中的整數值未四舍五入為0或1，而是被計為0.932 ...如何強制Java cplex舍入整數？

解決：這是“ opl.convertAllIntVars（）;” 一切都翻了一番。 我從示例代碼中刪除了它，並將其刪除，現在一切正常。

Answer 1

您的模型會有所不同。 我懷疑可能會處理整數變量的方式-值125相當是一個整數，而值117.2顯然不是整數，並且對數表明它正在作為正整數LP解決。

在兩個模型的解決方案中查看變量的值，然后找出值的不同之處。 希望兩個解決方案中的許多變量值都相似，這將有助於縮小搜索范圍。

嘗試將模型導出為LP文件或兩者中的相似文件，然后比較生成的模型。 也許可以在CPLEX命令行求解器中求解兩個導出的模型，然后比較日志和結果。

嘗試從另一個模型中的一個解決方案修正一些值，然后重新求解。

另外，給我們更多來自OPL模型的日志輸出。