我使用SCIP 3.0.2和cplex 12.6作为LP解算器。我的模型需要生成列。我已经在CPLEX中实现了它,但由于CPLEX只能在根节点中执行CG,因此我使用SCIP来进行分支和价格。 在CPLEX中,结果是关闭heursitics,削减和预处理/探测是有益的。我在SCIP中设置了以下内容:
SCIP_CALL( SCIPsetBoolParam(scip, "lp/presolving", FALSE) );
SCIPsetSeparating(scip, SCIP_PARAMSETTING_OFF, true); //disable cuts
SCIPsetHeuristics(scip, SCIP_PARAMSETTING_OFF, true); //disable heuristics
SCIPsetPresolving(scip, SCIP_PARAMSETTING_OFF, true); //disable presolving
我的参数文件如下所示:
display/primalbound/active = 1
presolving/maxrounds = 0
separating/maxrounds = 0
separating/maxroundsroot = 0
separating/maxcuts = 0
separating/maxcutsroot = 0
lp/initalgorithm = d
lp/resolvealgorithm = d
lp/fastmip = 1
lp/threads = 1
limits/time = 7200
limits/memory = 2900
limits/absgap = 0
#display/verblevel = 5
#display/freq = 10
为了检查模型是否相同,我解决了SCIP中的CPLEX模型(没有CG),我获得了与SCIP生成的模型相同的LP绑定,但与使用CPLEX解决时的LP绑定不同。 / p>
似乎SCIP仍然在使用一些魔法'我还没有停用。所以我的问题是我需要停用什么才能获得仅依赖于我的模型的LP绑定。
我已经看过统计数据输出,确实有些事情可能有助于解决问题:
预先解决的问题: 问题名称:t_ARLP 变量:969(806二进制,0整数,0隐式整数,163连续) 约束:9311初始,9311最大
在迭代开始之前,我得到以下内容:
LP解算器:基础的行表示不可用 - SCIP参数lp / rowrepswitch无效 转换后的问题有897个变量(806 bin,0 int,0 impl,91 cont)和9311约束
9311类型的约束<线性>
presolving: 预先决定(0轮): 0个已删除的变量,0个已删除的约束,0个已添加的约束,0个加强的边界,0个添加的孔,0个已更改的边,0个已更改的系数 0个含义,0个派系 预解决问题有897个变量(806 bin,0 int,0 impl,91 cont)和9311约束
9311类型的约束<线性>
预先计算时间:0.00
我添加了72列:91个原始+72添加= 163总计。这似乎没问题。
我添加了建议的参数。域传播似乎以前没有被使用过,但是已经有了强大的分支。不幸的是,参数没有任何改变。
除了添加参数外,我还尝试使用SCIP 3.0.1。这改善了我从670.194到699.203的界限,但这仍然与用754.348绑定的cplex完全不同。我知道求解器有很多数值参数,但我猜这些参数的差异太大了?
答案 0 :(得分:1)
还有两个因素可能影响根节点的LP绑定:域传播和强分支。
域传播是一种节点预处理,并尝试根据当前的本地域和约束来减少可变域。强分支预先计算潜在子节点的LP边界,以选择要分支的好变量。如果检测到其中一个子节点不可行,则其域将减少。
您可以通过设置
来禁用域传播propagating/maxrounds = 0
propagating/maxroundsroot = 0
通过为不应用强分支的分支规则设置高优先级,可以禁用强分支。例如,设置
branching/pscost/priority = 100000000
以启用纯伪成本分支。
通常,您应该检查 DomReds 列中的非零值的统计信息。
答案 1 :(得分:0)
您可以将内部问题写入文件,然后将其与原始文件进行比较:
SCIP> write transproblem
你还应该仔细阅读SCIP的统计数据,找出什么样的魔法' SCIP表演:
SCIP> display statistics
答案 2 :(得分:0)
我差点忘了这个帖子,然后再次偶然发现它,并认为自己找到答案后添加答案可能会很好: 在剪切回调中(遗憾的是我没有提到我使用过的)我使用了这个方法:
SCIPisCutEfficacious
它丢弃了一些与获得真正LP限制相关的切割。不调用此方法会减慢解决方案流程,但至少会保留结果。