使用 MINLP 进行 SCIP 不可行性检测答案

【问题标题】：SCIP infeasibility detection with a MINLP使用 MINLP 进行 SCIP 不可行性检测
【发布时间】：2014-07-11 16:49:12
【问题描述】：

我正在使用 SCIPAMPL 解决混合整数非线性规划问题 (MINLP)。在大多数情况下，它运行良好，但我发现求解器错误地检测到不可行的实例。

set K default {};

var x integer >= 0;
var y integer >= 0;
var z;
var v1{K} binary;

param yk{K} integer default 0;
param M := 300;                              
param eps := 0.5;                        

minimize upperobjf:
    16*x^2 + 9*y^2; 

subject to
    ll1: 4*x + y <= 50;
  ul1: -4*x + y <= 0; 
  vf1{k in K}: z + eps <= (x + yk[k] - 20)^4 + M*(1 - v1[k]);     
  vf2: z >= (x + y - 20)^4;
  aux1{k in K}: -(4*x + yk[k] - 50) <= M*v1[k] - eps;    
  # fix1: x = 4;
  # fix2: y = 12;

let K := {1,2,3,4,5,6,7,8,9,10,11};
for {k in K} let yk[k] := k - 1;
solve;
display x,y,z,v1;

求解器在预求解阶段检测到不可行性。但是，如果取消注释将 x 和 y 固定为 4 和 12 的两个约束，求解器将工作并输出正确的 v 和 z 值。

我很好奇为什么会发生这种情况，以及我是否可以用不同的方式来表述这个问题来避免它。我得到的一个建议是，对于非凸问题，不可行性检测通常不是很好。

编辑：我应该提到这不仅仅是 SCIP 问题。 SCIP 只是解决了这个特定集合 K 的问题。例如，如果我使用另一个全局 MINLP 求解器 bonmin，我可以解决这个特定 K 的问题，但是如果你将 K 扩展到 15，那么当问题仍然可行。对于那个 K，我还没有找到一个真正有效的求解器。我还尝试过基于 FILTER 的 minlp 求解器。我还没有尝试 BARON，因为它只需要 GAMS 输入。

【问题讨论】：

正如我在帖子中提到的，您可以重新运行将 x 和 y 固定为 4 和 12 的模型，它会输出最优解。仅此一点就告诉我，这是对原始问题的可行解决方案。我可以独立验证这一点。如果 aux1 中不等式的左侧为正，则可以将 v1[k] 设置为 1，如果左侧为负，则将其设置为 0。将 z 设置为一个值以在 vf2 中强制相等将产生一个可行的解决方案。
哦，对不起，我现在看到了。是的，不可行性检测可能会出错，但我认为它会在 sadw 方面出错。我认为大 M 够紧吗？
足够紧到底是什么意思？你的意思是够大吗？如果是这样，那么是的。我可以把它变小吗？我怀疑答案也是肯定的，但我不明白这有什么帮助。
使用大 M 值的良好做法是它们具有可能的最小值，以便生成的模型可行。较大的值可能会导致数值问题。较小的值会减小线性规划松弛的可行区域，从而提高分支定界期间的求解器性能。您的实际问题可能是由于舍入错误。 This response David Nehme 解释了为什么修复变量可以让求解器找到可行的解决方案。
我明白这一点，但不知何故我怀疑这里的情况。当然，在不知道求解器内部发生了什么的情况下，很难断言这根本不是问题所在。但是，我确实尝试了较低的 M 值，发现问题仍然存在。

标签： integer-programming scip

【解决方案1】：

关于建模问题，例如 cmets 中的大 M 约束对您的原始问题有很好的评论。数值问题确实会造成麻烦，尤其是在存在非线性约束的情况下。

根据您想深入了解该问题的程度，我为您提供了 3 个选项：

您可以通过调整参数numerics/feastol、numerics/epsilon 和numerics/lpfeastol 来降低数值精度。您可以将以下行保存在文件“scip.set”中，并将其保存到您调用scipampl 的工作目录中：

# 小于这个的绝对值被认为是零 # [类型：真实，范围：[1e-20,0.001]，默认值：1e-09] 数字/epsilon = 1e-07

# 总和的绝对值小于这个值被认为是零 # [类型：真实，范围：[1e-17,0.001]，默认值：1e-06] 数字/sumepsilon = 1e-05

# 约束的可行性容忍度 # [类型：真实，范围：[1e-17,0.001]，默认值：1e-06] 数字/feastol = 1e-05

# LP 求解器的原始可行性容差 # [类型：真实，范围：[1e-17,0.001]，默认值：1e-06] 数字/lpfeastol = 1e-05

您现在可以通过修改文件scip.set 来测试scipampl 内的不同数值精度
通过修复x 和y 变量来保存您获得的解决方案。如果您将此解决方案传递给模型而不进行修复，您会收到一条消息，说明导致不可行的原因。通常，您会收到一条消息，指出某些变量界限或约束略微超出了公差范围。
如果您想准确了解通过哪个预求解器解决方案变得不可行，或者如果前一种方法没有显示任何违规，SCIP 提供了读取调试解决方案的功能；通过取消注释src/scip/debug.h 中的行来指定解决方案文件“debug.sol”

/* #define SCIP_DEBUG_SOLUTION "debug.sol" */

并使用重新编译 SCIP 和 SCIPAmpl

make DBG=true

SCIP 针对每个预求解归约检查调试解决方案，并输出导致问题的预求解器。

我希望这对你有用。

【讨论】：

感谢您的建议。有机会我会尝试一下，然后告诉你进展如何。

【解决方案2】：

深入研究这个实例，SCIP 似乎在 presolve 中做错了什么。

在 cons_nonlinear.c:7816（函数 consPresolNonlinear）中，删除该行

if( nrounds == 0 )

以便在任何情况下都执行 SCIPexprgraphPropagateVarBounds。

这似乎解决了问题。

【讨论】：