在 OptaPlanner 中使用 PDPTW 进行并行求解
Parallel Solving with PDPTW in OptaPlanner
我正在尝试使用并行方法提高 OptaPlanner 的性能，但我不确定最佳策略。
我有 PDPTW：
- 车辆路线
- 时间-windowed（1 小时 windows）
- 取货和送货
当新客户想要添加送货时，我正在尝试找出一种快速方法（不到一秒）向他们展示一天中有哪些时间段可用（上午 8 点、上午 9 点、上午 10 点等） ).每个时间段都有不同的分数结果。有些效率很高，有些则不可预订，具体取决于 time/situation 行驶时间增加。
为了性能，我不想按顺序尝试每个小时的时间，因为它太慢了。
我怎样才能同时尝试客户在所有时间段的交付？在添加客户的潜在交付 window 之前先 运行 求解器是有意义的，然后共享已解决的原始状态，所有不同的添加交付的时间段都被独立解决。
有没有直观的方法来做到这一点？例如：
- 重用一些原来的求解计算（添加新交付前的状态）。也许这甚至可以提前缓存？
- 也许运行所有时隙在单独的服务器（或至少多个线程）上解决实例。
对于这样的事情，推荐的设置是什么？如果能在一秒钟内 return 一个 HTTP 响应就太好了。这适用于大约 100-200 次送货和 10-20 辆卡车。
谢谢！
A) 如果您优化 1 位客户到 1 辆车 中的 1 个索引的分配，而 pinning 所有其他已分配客户，那么您将放弃所有优化优势。这不是 NP 难的。
您仍然可以为此使用 OptaPlanner <constructionHeuristic/>（<localSearch/> 不会提高分数），无论是否使用 moveThreadCount 将其分布在多个核心上，即使主要好处只是增量分数计算，而不是人工智能算法。
B) 优化所有客户到车辆索引的分配。真正的商业利益——比如减少 25% 的驾驶时间——在添加新客户允许移动现有客户分配时出现。问题是那些现有客户已经收到他们在议程中屏蔽的时间 window。但如果那些时间 windows 足够宽，这就不是问题：这些只是硬约束。 更宽的时间 windows = 更多的驾驶时间优化机会（=更多 $$$，更少的二氧化碳排放量）。
一分钟内回复怎么样？
到那时，您不需要发布（=与客户共享信息）哪辆车将在什么时间以何种顺序到达。你只需要发布不管你是否接受时间window。有两种方法可以实现：
C) 基于 table 的决定（ 放松 ）：每辆车每天不超过 5 位顾客。
陷阱：如果它在 country/state 的 5 个角落有 5 个客户，那么它可能仍然不可行。考虑任何 2 个客户位置对之间的平均欧几里德距离以影响决策。
D) 通过 运行ning optaplanner 直到 termination feasible=true，从先前调度的热启动开始。如果在1000ms内没有找到这样的可行解，则拒绝时间window提议。
D 的陷阱）：如果同时有 2 个请求进来，而你 运行 它们是并行的，所以两者都没有考虑到另一个，它们可能单独可行但一起不可行。
我正在尝试使用并行方法提高 OptaPlanner 的性能，但我不确定最佳策略。
我有 PDPTW：
- 车辆路线
- 时间-windowed（1 小时 windows）
- 取货和送货
当新客户想要添加送货时，我正在尝试找出一种快速方法（不到一秒）向他们展示一天中有哪些时间段可用（上午 8 点、上午 9 点、上午 10 点等） ).每个时间段都有不同的分数结果。有些效率很高，有些则不可预订，具体取决于 time/situation 行驶时间增加。
为了性能，我不想按顺序尝试每个小时的时间，因为它太慢了。
我怎样才能同时尝试客户在所有时间段的交付？在添加客户的潜在交付 window 之前先 运行 求解器是有意义的，然后共享已解决的原始状态，所有不同的添加交付的时间段都被独立解决。
有没有直观的方法来做到这一点？例如：
- 重用一些原来的求解计算（添加新交付前的状态）。也许这甚至可以提前缓存？
- 也许运行所有时隙在单独的服务器（或至少多个线程）上解决实例。
对于这样的事情，推荐的设置是什么？如果能在一秒钟内 return 一个 HTTP 响应就太好了。这适用于大约 100-200 次送货和 10-20 辆卡车。
谢谢！
A) 如果您优化 1 位客户到 1 辆车 中的 1 个索引的分配，而 pinning 所有其他已分配客户，那么您将放弃所有优化优势。这不是 NP 难的。
您仍然可以为此使用 OptaPlanner <constructionHeuristic/>（<localSearch/> 不会提高分数），无论是否使用 moveThreadCount 将其分布在多个核心上，即使主要好处只是增量分数计算，而不是人工智能算法。
B) 优化所有客户到车辆索引的分配。真正的商业利益——比如减少 25% 的驾驶时间——在添加新客户允许移动现有客户分配时出现。问题是那些现有客户已经收到他们在议程中屏蔽的时间 window。但如果那些时间 windows 足够宽，这就不是问题：这些只是硬约束。 更宽的时间 windows = 更多的驾驶时间优化机会（=更多 $$$，更少的二氧化碳排放量）。
一分钟内回复怎么样？
到那时，您不需要发布（=与客户共享信息）哪辆车将在什么时间以何种顺序到达。你只需要发布不管你是否接受时间window。有两种方法可以实现：
C) 基于 table 的决定（ 放松 ）：每辆车每天不超过 5 位顾客。
陷阱：如果它在 country/state 的 5 个角落有 5 个客户，那么它可能仍然不可行。考虑任何 2 个客户位置对之间的平均欧几里德距离以影响决策。
D) 通过 运行ning optaplanner 直到 termination feasible=true，从先前调度的热启动开始。如果在1000ms内没有找到这样的可行解，则拒绝时间window提议。
D 的陷阱）：如果同时有 2 个请求进来，而你 运行 它们是并行的，所以两者都没有考虑到另一个，它们可能单独可行但一起不可行。