0

我在理解非线性优化中的性能如何受求解器引擎接口的特定方式影响时遇到了一些困难。

我们有一个优化模型，它的第一个版本是用 GAMS 编写的。IPOPT（一种常见的 FOOS 非线性求解器引擎）在 IPOPT（无函数评估）中为每个优化返回 1.4 CPU 秒的执行时间，在函数评估中返回 0.2 CPU 秒的执行时间。

当我们将模型转换为 C++（为了更好地考虑模型的非优化组件）并通过其 C++ API 连接 IPOPT（使用 ADOL-C 和 ColPack 进行 AD）时，我们在 IPOPT 中获得了 0.7 秒的执行时间和 9.4 秒函数评估中的秒数（IPOPT 的改进可能是由于通过源代码编译 IPOPT，我们能够使用 GAMS 版本的 IPOPT 中不可用的更好的线性求解器）。

因此，使用 C++（诚然使用了优化不佳的代码）给我们的结果比 GAMS 慢了约 50 倍，部分由更好的求解器时间补偿。

我们现在正在评估将模型转换为其他语言的可行性，无论是 Python 与 Pyomo，还是 Julia 与 JuMP。

但我们首先想了解求解器在每一步所做的函数评估如何依赖于所实现的特定语言。

使用 C++，很明显创建优化模型的函数在每次迭代时都直接执行（评估），因此它们的实现方式很重要（特别是，梯度和 hessian 每次都重新计算，至少在我们的实现中） .

Pyomo 和 JuMP 怎么样？是在 Python 和 Julia 中评估的每次迭代，还是 Pyomo 和 JuMP 会首先在（我猜）C 中渲染模型，计算（而不是评估）梯度和粗麻布，然后是这个“C 版本”每次都会被评估？这显然会产生很大的不同，尤其是对于 python ..

4

2 回答 2

2

Pyomo 通过将模型转换为 NL 文件格式来连接 Ipopt。它假定“ipopt”可执行文件在您的 PATH 中（使用 ASL 编译的 Ipopt）。在优化期间发生的所有函数评估都发生在 Ampl Solver Library 中的 C 语言中。

于 2016-11-25T19:50:06.077 回答
1

在我们自己的基准测试中， JuMP 与 GAMS 相比毫不逊色；尽你所能。导数计算完全在 Julia 中（速度很快），没有编译的 C 代码。

于 2016-11-26T04:26:06.073 回答