我使用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);
}
现在的问题是,如果我运行" myModel.mod"和" myData.dat"在IBM Optimization studio和Java中,我得到了非常不同的客观结果。
在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();"将一切转化为双打。我从示例代码中取出并删除它,现在一切正常。
答案 0 :(得分:0)
您的模型在某种程度上会有所不同。我怀疑可以处理整数变量的方式 - 值125是一个整数,而117.2显然不是整数,日志显示它是作为直接LP解决的。
查看两个模型解决方案中变量的值,并找出值的不同之处。希望两个解决方案中的许多变量值都相似,这有助于缩小搜索范围。
尝试将模型导出为LP文件或类似文件,并比较生成的模型。也许在CPLEX命令行解算器中解决两个导出的模型,并比较日志和结果。
尝试从另一个模型中的一个解决方案中修复一些值并重新解决。
另外,请给我们更多来自OPL模型的日志输出。