带口水记分器的Optaplanner --为什么不使用空的解决方案？

Question

我一直在研究带有Drools实现的云平衡演示 of OptaPlanner。

这个演示有2条规则(实际上有4条，但其中3条规则具有相同的逻辑) --

rule "requiredCpuPowerTotal"
when
    $computer : CloudComputer($cpuPower : cpuPower)
    accumulate(
        CloudProcess(
            computer == $computer,
            $requiredCpuPower : requiredCpuPower);
        $requiredCpuPowerTotal : sum($requiredCpuPower);
        $requiredCpuPowerTotal > $cpuPower
    )
then
    scoreHolder.addHardConstraintMatch(kcontext, $cpuPower - $requiredCpuPowerTotal);
end

和

rule "computerCost"  // "Minimize the total maintenance cost."
when
    $computer : CloudComputer($cost : cost)
    exists CloudProcess(computer == $computer)
then
    scoreHolder.addSoftConstraintMatch(kcontext, - $cost);
end

按照这些规则，最优的解决方案是不将任何进程分配给计算机中的任何人。这将完美地满足第一条规则-- cpuPower的容量永远不会耗尽，更不用说过去了。不使用计算机，因此不需要维护费用。

但是系统找到了一种只有这2条规则的解决方案--亚优化将进程分配给计算机。

我错过了什么，在哪里？

OptaPlanner/Drools在哪里被告知分配尽可能多的进程？

新来的口水。原谅这个天真的问题，如果是的话。

//-更新

我认为要初始化的@PlanningEntity()实例并将其放在@PlanningSolution()上是关键。或者显式地在代码中，或者通过@yurloc建议的构造启发式配置，或者。{不知道这里还有什么，如果有的话}

Answer 1

单/#区域搜索概述

本地搜索需要从初始化的解决方案开始，因此通常需要先配置构造启发式阶段。

默认情况下，Local期望所有实体都被初始化，并且在对解决方案进行更改时不允许取消初始化它们。对最后一个问题的回答是，构建启发式阶段为每个进程分配了一台计算机，尽管它实际上会使分数恶化。本地搜索将提高下一阶段的得分。

由于这种默认行为，您不必编写惩罚未分配任何计算机的进程的规则。

为了完整，请注意，您可以将计划变量设置为可空，但这是一个高级主题。可空规划变量通常只适用于过度约束的规划。