哪些因素限制了ANSYS Fluent的並行核數？

01-15

背景：2015.09.09，ANSYS和Cray Inc.與兩家超級計算中心攜手合作，將ANSYS? Fluent?擴展到12.9萬個計算內核。
問題：

MPI方式會不會對並行核數有限制（不考慮license限制）？
對於ANSYS公司來說，不需要擔心license問題，他們將Fluent擴展到12.9萬個計算內核是改變了硬體？還是改變了ANSYS Fluent代碼？或者是優化了MPI方式？

假設硬體無限制，Fluent理論上是不是能夠並行無限個核數？

問題：
MPI方式會不會對並行核數有限制？

MPI協議本身對並行規模是沒有什麼限制的。有限制的話，應該就是節點編號使用的數據類型的上限。不過即便是32位整型，現在也應該沒人用完過吧。

至於整個求解器的並行，就有點意思了。

Fluent老早就實現MPI並行了，所以不存在從串列到並行的困難。但是超大規模MPI並行（&>=10K processors，個人標準，非業界共識）和小規模的MPI並行（&<= 1K processors，同前)，是有質的區別的。為了搞這個新聞，這些年ANSYS可能對程序進行了一些優化和特別處理，具體的就不得而知了。就我能想到的，可能有以下兩點。

1. 通信開銷增長和通信能力之間的平衡。小規模並行一般不需要考慮通信的壓力。但如果存在all to all 通信（矩陣乘向量操作是需要的），那麼隨著計算節點的增長，通信開銷的增長（O(N^2)）是比較可怕的。一種解決思路是把信息交換限制在常數個鄰居節點上。但是這樣又會導致線性系統求解的效率不能充分發揮。因為每次迭代中信息最遠只能傳播到有幾個鄰居節點所覆蓋的網格範圍。通信效率和線性系統求解的效率之間需要有一個平衡。當前，在IB的支持下，這個平衡點相當偏向線性系統求解。所以也不排除硬體通信能力可以保證實現這麼大規模global solver的可能。

2. 通信和並行的容錯處理。如果你用200個核並行，一個case跑2個小時，可以不考慮中間有節點宕機，通信錯誤等等。萬一倒霉碰上了，大不了重算。但是在12.9萬個計算內核上跑並行，中間有人掉鏈子的概率就比較大了。算到中間掛了1個節點怎麼辦，中間發生了通信錯誤怎麼辦？全部重新算么？這顯然不好。回滾到上一步么？要回滾的話，上一步的信息是不能保存在當前節點上的，否則節點死了，歷史數據也沒了。

如果求解器scaling調教的比較成熟的話，工業市場可能會發生一些變化。比如大家都不自己搭小集群了，轉而去租用超算。這樣ANSYS就不用去各個用戶推銷了，往超算賣一套就是了。但這還是會有問題，算完並不算完。算出來的一大堆數據是遠程可視化呢，還是拷下來？這都是很考驗網速的事情。

僅個人觀點。

阻擋ansys測試更多核心的第一因素我猜是沒有那麼多核心，很少有超算能有12.9萬個核心，比如TACC的stampede，前年我剛開始有訪問權的時候是world ranking top 6，也只有6400個節點，每個節點16個processor。而且因為硬體不完全一致，就算只有一個用戶的時候，6400節點也是不能同時使用的。

一般來說，CFD中不用那麼巨大數量的核心數很明顯的原因肯定是因為CPU之間的通信使得scaling並不那麼理想，當你增加核心數的時候，每個時間步所需要的時間並不是一直減小的。我記得GE和ansys若干年前試過上千個核，效率好像還可以吧，不記得出處了。OpenFOAM測試過icoFoam在某些問題上似乎也能在上千核心情況下保證不錯的並行效率。但是上萬個核心還得保證一定的效率，就我來說很難想像這是多麼大的一個問題。

另外，時間步隨著雷諾數增加也是會增加的，而且這部分沒法並行，依舊是制約CFD進行太多核心並行化的一個因素。

舉個例子，就算對於一個超大的問題，你用了足夠多的核心，你每個時間步只用0.01s（簡直快得慘絕人寰），但是你需要statistical averaging，總共要算一億步，一百萬秒你看看是多久。。

如果你有個無限大的網格的話，你要假設硬體無限制那當然可以無限並行，這個無限制其實包括很多東西了。。。

湖大有個超算中心，以前在裡面聽過幾節課，後來逃課太多期終考試都沒過。我覺得fluent應該是在演算法上做了不少優化。比如cae中常用的排序，矩陣運算，解方程什麼的都需要修改下原程序，方便並行化，這點fluent與普通的程序並行化沒什麼區別。當然cpu核心數並非越多越好，當核心數達到一定程度，核心之間的通信就會很消耗資源，程序加速的效果就沒有那麼明顯了。這個貌似有公式可以算出來。這方面並行計算相關的書介紹的會更專業。

it is just a toy for ansys inc.

1、實際工程問題，根本用不到那麼多核，國內我見過的最多的是用了512核

2、在調用超多計算核心的情況下，除了通信開銷以外，還有一個很重要的問題是，分配給每個核計算核心的求解數據。

舉例，1億網格的模型，分配給1000個計算核心，那每個計算核心分配的網格大概只有10萬，這點計算量對現在的CPU來說，還不夠塞牙縫的，剩下的時間就是等等等了，等別的計算核心的數據，然後匯總。。。。

這個問題對於普通研究，就算是工業上的分析都沒多少意義，我們公司花了幾百萬弄了個計算機群，也就有600核，所以，你說討論12w以上的，我只能呵呵了

商業軟體比如Fluent的設計初衷應該就不是大規模並行，大規模並行要考慮各種問題，除了solver還有pre- post processing。