在非线性求解器中,什么影响求解器时间与NLP函数评估?

时间:2016-11-25 10:36:17

标签: performance mathematical-optimization pyomo julia-jump ipopt

我很难理解非线性优化中的性能如何受到求解器引擎接口的特定方式的影响。

我们有一个优化模型,在其第一个版本中,是用GAMS编写的。 IPOPT(一种常见的FOOS非线性求解器引擎)在IPOPT(无功能评估)中每次优化1.4 CPU秒,在功能评估中返回0.2 CPU秒。

当我们将模型转换为C ++(为了更好地计算模型的非优化组件)并通过其C ++ API(使用ADOL-C和ColPack for AD)接口IPOPT时,我们的执行时间为0.7秒IPOPT和9.4秒的功能评估(IPOPT的改进可能是因为,通过源编译IPOPT,我们能够使用更好的线性解算器,在IPOPT的GAMS版本中不可用)。

因此,使用C ++,无可否认地使用了经过严格优化的代码,给我们的结果〜比GAMS慢50倍,部分由更好的求解时间补偿。

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

但我们首先要了解解决方案在每个步骤中所做的功能评估是如何取决于所实现的特定语言。

使用C ++,非常明显的是,在每次迭代时直接执行(评估)制作优化模型的函数,因此它们的实现方式确实很重要(特别是每次重新计算渐变和粗体) ,至少在我们的实施中)。

Pyomo和JuMP怎么样?是否会在Python和Julia中进行每次迭代评估,或者Pyomo和JuMP将首先在(我猜)C中渲染模型,计算(不评估)渐变和粗麻布一次,然后是#34; C版本"那会被评估吗? 它显然会产生很大的不同,特别是对于python ..

2 个答案:

答案 0 :(得分:1)

Pyomo通过将模型转换为NL文件格式与Ipopt接口。它假定“ipopt”可执行文件位于PATH中(Ipopt使用ASL编译)。优化期间发生的所有功能评估都在Ampl Solver Library中的C中进行。

答案 1 :(得分:0)

JuMP在our own benchmarks中与GAMS相比有利;尽你所能。衍生计算完全在Julia(很快),没有编译的C代码。