在非線性求解器中，什么會影響求解器時間與NLP函數評估？

Question

在理解非線性優化中的性能如何受到求解器引擎連接的特定方式的影響時，我遇到了一些困難。

我們有一個優化模型，該模型的第一個版本是用GAMS編寫的。 IPOPT（一種常見的FOOS非線性求解器引擎）在IPOPT（無功能評估）的每個優化中返回1.4 CPU秒，而在功能評估中則返回0.2 CPU秒。

當我們將模型轉換為C ++（以更好地考慮模型的非優化組件）並通過其C ++ API（使用ADOL-C和ColPack for AD）連接IPOPT時，在IPOPT和9.4中的執行時間分別為0.7秒功能評估的秒數（IPOPT的改進很可能是由於以下事實：按源編譯IPOPT，我們能夠使用GAMS版本的IPOPT中沒有的更好的線性求解器）。

因此，使用C ++以及公認的錯誤優化代碼，使我們的結果比GAMS慢50倍左右，而求解器時間則得到了部分補償。

現在，我們正在評估將模型轉換為其他語言的可行性，例如使用Pyomo的Python或使用JuMP的Julia。

但是我們首先要了解求解器在每個步驟進行的功能評估如何取決於所實現的特定語言。

使用C ++，很明顯，可以在每次迭代時直接執行（評估）構成優化模型的函數，因此實現它們的方式確實很重要（尤其是，至少在我們的實現中，每次都重新計算了gradient和hessian） 。

Pyomo和JuMP怎么樣？ 是在Python和Julia中評估每個迭代，還是Pyomo和JuMP會首先在（我猜）C中渲染模型，一次計算（不評估）梯度和粗麻布，然后是此“ C版本”每次都會被評估？ 顯然這將帶來很大的不同，尤其是對於python。

Answer 1

Pyomo通過將模型轉換為NL文件格式來與Ipopt交互。 假定“ ipopt”可執行文件在您的PATH（使用ASL編譯的Ipopt）中。 優化過程中發生的所有功能評估都在Ampl Solver庫中的C中進行。

Answer 2

在我們自己的基准中 ，JuMP與GAMS相比表現良好; 隨你便。 派生計算完全使用Julia（這是快速的），沒有經過編譯的C代碼。