调度应用程序中的约束图转换答案

【问题标题】：Constrained graph transformation in scheduling applications调度应用程序中的约束图转换
【发布时间】：2010-12-18 16:25:16
【问题描述】：

我正在开发一个交互式作业调度应用程序。给定一组具有相应容量/可用性配置文件的资源，一组要在这些资源上执行的作业，以及一组确定作业顺序和作业的最早/最晚开始/结束时间的约束，我想让用户手动移动周围的工作。本质上，我希望用户能够“抓住”工作网络的一个节点并及时向前/向后拖动而不违反任何约束。

图片显示了一个简单的示例配置。最后的三角形作业表示所有作业的最晚完成时间，作业之间的连接线对作业施加顺序，灰色/绿色条表示资源可用性和负载。

您可以拖动任何作业来压缩计划。请注意，由于容量配置文件不同，作业的长度会发生变化。

我已经实现了一个有点工作的临时算法。但是，仍然存在失败并违反某些约束的情况。然而，由于工作车间调度是一个研究得很好的领域，有很多算法和启发式方法可以找到一般 NP-hard 问题的最佳（或相当好的）解决方案 - 我认为解决方案应该存在于我更容易的子集。我研究了约束编程主题，甚至研究了基于物理的解决方案（通过静态关节连接的刚体），但到目前为止找不到任何合适的东西。对我有任何指示/提示/提示/搜索关键字吗？

【问题讨论】：

我没有完全理解这个问题，抱歉。为什么工作的长度会改变？当您说抓取并移动节点时，您是什么意思？作业是节点吗？谢谢。
如上所示的网络可以通过交互式拖放操作进行修改。单击一个作业（图中标记为“作业”的节点）并将其移动到其他位置。由于作业持续时间取决于可用容量（灰色/绿色条），因此作业长度会在移动时发生变化。
我也不懂。您是否希望其他工作移动以满足特定的工作移动 - 例如，如果您将 job032 向左拖动，job029 和 job031 会以某种方式重新安排自己，因此 job031 仍然在 job032 开始之前完成？如果是这样，您需要告诉我们允许我们对其他工作做什么——及时移动、更改资源等？资源共享是否简单（即在同一资源上运行的两个单元作业需要 2 个单位时间才能完成）？
是的，job029 和 job031 需要在您的示例中重新安排。允许更改资源。我不知道“简单分享”是什么意思。我们确实有复杂的情况，其中一项工作的持续时间取决于它的前任，或者多个工作可能在一个资源上并行运行，或者一个工作拖另一个工作，或者必须在另一个工作之后在有限的时间段内执行等等。无论如何，我主要关心的是满足链接（线）隐含的优先约束。
单个作业节点的图表会有所帮助。我假设它可以有 N 个工作传入（必须事先完成），以及 N 个工作传出（这取决于这个工作）。您的示例似乎不是“图论”，并且似乎并不关心资源 2 在作业 031 期间将处于空闲状态。如果这是实现既定目标的最有效方法，正确的解决方案只会让资源 2 空闲. “资源”不应该以这种方式表示；相反，您应该呈现动态节点，这些节点的行为与您描述的一样。诸如开始时间之类的“硬约束”“锁定”了一个动态特征。

标签： algorithm language-agnostic graph scheduling constraint-programming

【解决方案1】：

如果您有问题，我强烈建议您查看Mozart Oz 只处理整数。 Oz 对有限域有很好的支持约束规范、推理和优化。在你的情况下通常您会执行以下操作：

以声明方式指定约束。在这种情况下，你会指定所有变量及其域（比如 V1：1#100，表示 V1 变量的取值范围为 1--100)。一些变量可能直接有值，比如 V1: 99。此外，您可以指定变量的所有约束。
向系统询问解决方案：满足约束或最优解。然后你会显示这个 UI 上的解决方案。
假设用户更改变量的值，可能是开始一个任务的时间。现在您可以转到步骤 1 将问题发布到盎司求解器。这一次，解决问题很可能不需要和之前一样多，因为所有变量都已经实例化了。

可能是用户选择的值不一致。在那里面在这种情况下，求解器返回 null。然后，您可以将 UI 带到更早的位置解决方案。

如果 Oz 适合您的需要并且您喜欢该语言，那么您可能想要将约束求解器编写为侦听套接字的服务器。这边走，您可以将约束求解器与其余代码分开，包括用户界面。

希望这会有所帮助。

【讨论】：

感谢您的指点。我对它进行了快速扫描，我有点怀疑：1）学习一门新语言需要我重新陈述/重新表述问题2）Mozart Oz 的东西看起来像是一个寻找最佳工作时间表的启发式优化框架。我只是在寻找一个在手动编辑网络时满足所有约束 3）实时交互性能？
1) 我猜这是一个合理的担忧。 2）你可以只做“约束满足”。只有在需要时才能进行优化。请查看“发送更多钱”示例。 3）对于约束满足（不是优化），交互性能应该不是问题。

【解决方案2】：

出于以下几个原因，我会投票支持约束规划：

1) CP 会迅速告诉您是否没有满足您的限制的时间表

2) 您似乎想为您的用户提供一个可行的解决方案，但允许他们操纵工作以改进解决方案。这点CP也不错。

3) MILP 方法通常复杂且难以制定，您必须人为地创建目标函数。

4) CP 并不难学，尤其是对于有经验的程序员来说——它确实更多地来自计算机科学社区，而不是运筹学研究人员（比如我）。

祝你好运。

【讨论】：

【解决方案3】：

您可能会更改 Waltz 约束传播算法以处理不断变化的约束，从而快速确定给定解决方案是否有效。我没有提到手，但这可能会为您指明正确的方向： http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TYF-41C30BN-5&_user=809099&_rdoc=1&_fmt=&_orig=search&_sort=d&_docanchor=&view=c&_searchStrId=1102030809&_rerunOrigin=google&_acct=C000043939&_version=1&_urlVersion=0&_userid=809099&md5=696143716f0d363581a1805b34ae32d9

【讨论】：

【解决方案4】：

您是否考虑过使用整数线性规划引擎（如 lp_solve）？它非常适合调度应用程序。

【讨论】：