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

我在理解非線性優化中的性能如何受解算器引擎連接的具體方式影響方面存在一些困難。在非線性求解器中，什麼影響求解器時間與NLP函數評估？

我們有一個優化模型，它的第一個版本是用GAMS編寫的。 IPOPT（一種常見的FOOS非線性解算器引擎）正在爲IPOPT（無功能評估）的每次優化1.4 CPU秒和功能評估中0.2 CPU秒的優化返回執行時間。當我們通過C++ API（使用ADOL-C和ColPack for AD）將模型轉換爲C++（用於更好地解釋模型的非優化組件）並使用IPOPT接口時，我們得到的執行時間爲0.7秒在IPOPT和9.4秒的功能評估中（IPOPT的改進可能是由於這樣的事實，即通過源代碼編譯IPOPT，我們能夠使用IPOPT的GAMS版本中不具備的更好的線性求解器）。

因此，使用C++，誠然使用非常優化的代碼，給了我們的結果〜比GAMS慢50倍，更好的由解算器時部分地被補償。

我們現在正在評估可行性模型轉換成其他語言，無論是用Python Pyomo，或朱莉婭與跳躍。

但是如何求解器在每一步進行的功能評價從實施的特定語言取決於我們想先來了解。使用C++很明顯，在每次迭代中直接執行（評估）使得優化模型的函數，因此它們的實現方式很重要（特別是每次重新計算梯度和hessian，至少在我們的實施中）。

Pyomo和JuMP怎麼樣？它是每個迭代在Python和Julia中進行評估，或者Pyomo和JuMP會首先渲染模型（我猜）C，計算（不計算）漸變和hessian一次，然後是這個「C版本」會每次評估？這顯然會造成很大的差異，特別是對於Python。

來源

2016-11-25 Antonello

想到的第一個問題：這兩個實現是否相等？數據是否相等？該模型？隨機種子？你是否獲得相同的解決方案？我很確定其中一些問題的回答是否定的。如果兩個實現不完全相同，就很難評估，特別是在解決以啓發式行爲爲核心的難題時。這意味着，需要一個更大的基準來真正分析這一點。我不希望對函數eval產生巨大影響，也許是自動分化。但這只是猜測。 – sascha

（1）GAMS解算器IPOPTH使用MA27通常比使用MUMPS的IPOPT獲得更好的性能。（2）GAMS函數和梯度評估可能共享一些子表達式;有時這可以節省一些時間（3）通過讓CONVERT求解器將模型轉換成（醜陋的，標量的）Pyomo代碼，可以快速嘗試pyomo。 –

Pyomo通過將模型轉換爲NL文件格式來連接到Ipopt。它假定「ipopt」可執行文件位於PATH中（Ipopt使用ASL編譯）。所有在優化過程中發生的功能評估發生在Ampl Solutions Library中的C中。

來源

2016-11-25 19:50:06

跳越與GAMS在our own benchmarks相比毫不遜色;如你所願。派生計算完全在Julia（快速）中，沒有編譯C代碼。

來源

2016-11-26 04:26:06 mlubin

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

回答

相關問題