基于OpenMP 4.0的發動機燃燒模擬軟件異構并行優化

楊梅芳 車永剛,2 高 翔

1(國防科技大學計算機學院 長沙 410073)2(國防科技大學并行與分布處理重點實驗室 長沙 410073)(1520241161@qq.com)

近年來，高超聲速飛行器成為世界各航空航天大國關注和研究的熱點[1]，其馬赫數超過5(馬赫數為飛行速度與當地聲速之比，是無量綱數，記為Ma.從馬赫數可以大致了解飛行器速度的狀況——是亞聲速，還是超聲速，甚至是高超聲速.馬赫數小于1者為亞聲速，近乎等于1為跨聲速，大于1為超聲速；一般情況下，若馬赫數大于5為高超聲速)，在軍事和民用方面都具有巨大的潛在價值[2].實現高超聲速飛行的關鍵是發動機，超聲速燃燒沖壓發動機(簡稱超燃沖壓發動機)是高超聲速飛行器主要推進裝置之一.超燃沖壓發動機內部的流動與燃燒機制非常復雜，對發動機內高速、復雜的非定常流的測試極為困難，并且測試的裝置也非常復雜和昂貴，目前世界上只有少量可用的測試裝置.基于計算流體動力學(computational fluid dynamics, CFD)數值模擬的方法成為研究超燃沖壓發動機內部燃燒與流動問題的一種重要方法.

超燃沖壓發動機數值模擬軟件LESAP(large eddy simulation for air-breathing propulsion)[3-6]采用CFD技術模擬超燃沖壓發動機中的流動與燃燒.超燃沖壓發動機內的超聲速燃燒是復雜的多物理、多尺度問題，湍流、物質混合及燃燒反應相互耦合，流動與燃燒發生在極大時空尺度范圍內，對其進行數值模擬需要精細的網格及大量時間步，導致巨大的計算開銷，因此如何利用現代高性能計算機系統實現高效的超燃沖壓發動機燃燒模擬軟件成為關鍵問題.

在高性能計算機體系結構方面，以“主處理器+加速器或協處理器”方式進行協同工作的眾核異構型高性能計算機日益成為主流[7].在2016年的TOP500[8]中，位于第2的以Intel集成眾核處理器MIC (many integrated core)作為加速部件的天河二號[9]超級計算機就是典型的眾核異構型計算機.針對這種CPU+MIC的異構并行[10]體系結構，目前主要有5種編程模式：CPU原生模式、CPU為主MIC為輔模式(也稱offload模式)、CPU和MIC對等模式、MIC為主CPU為輔模式、MIC原生模式.其中CPU為主MIC為輔模式是MIC編程中最常用的模式[11]，目前MIC上的offload異構移植實現方式主要有2種： 一種是由Intel研發的語言擴展LEO(language extensions for offload)[12]；另一種則是2013年7月由OpenMP架構評審委員會(OpenMP ARB)發布的OpenMP 4.0[13].目前國內外基于CPU+MIC異構的CFD應用[14-18]移植方式都采用Intel’s LEO.

OpenMP 4.0規范是用于共享內存并行系統的多線程程序設計的一套指導性注釋編程接口.和舊版本的OpenMP相比，OpenMP 4.0新增了對加速器、SIMD的編程等功能.OpenMP 4.0是業界的工業標準，獨立于廠商，相較于Intel提出的Offload語法更具有可移植性和可繼承性，編程也更為方便.本文嘗試采用CPU為主MIC為輔模式，使用MPI+OpenMP 4.0編程模型，對LESAP軟件進行面向CPU+MIC混合異構平臺的并行移植和性能優化.

1 發動機燃燒模擬軟件LESAP分析

1.1 軟件介紹

超燃沖壓發動機燃燒模擬軟件LESAP是典型的燃燒模擬軟件，通過2階時間分裂方法將化學反應與流場模擬解耦，實現超燃沖壓發動機內湍流燃燒的數值模擬.在計算模型上，可采用混合雷諾平均N-S模擬大渦模擬(navier-stokeslarge eddy simulation, RANSLES)[19]、大渦模擬或直接數值模擬(direct numerical simulation, DNS).對燃燒化學反應模擬采用了詳細的化學反應模型，在流場求解時對無粘通量計算采用5階WENO(weighted essentially non-oscillatory)格式[20]，對粘性通量采用2階中心差分格式.時間格式采用隱式雙時間步方法，其中的子迭代采用上下對稱高斯-賽德爾(lower-upper symmetric Gauss-Seidel, LU-SGS)算法.

LESAP軟件是典型的CFD應用軟件，包含10 000余行Fortran-90代碼，計算流程復雜，計算量巨大.原始版本實現了初步的MPI+OpenMP 2層混合并行，是高度并行化的應用，適合做CPU+MIC異構移植.整個LESAP軟件數值模擬流程圖如圖1所示，輸入文件主要有網格數據、邊界條件和控制參數，網格輸入文件按照區域分解原則被均勻劃分成多個網格區塊，每個MPI進程處理一個網格區塊.主要計算部分在一個時間步循環中，包含燃燒化學反應計算(reaction)和流場通量計算(march)，該時間步循環要迭代數萬步才能獲得可用的結果.

Fig. 1 Flowchart of LESAP圖1 LESAP軟件數值模擬流程圖

在現實模擬中，LESAP需要大規模精細的網格來捕獲燃燒現象的詳細情況，計算量巨大.因此，LESAP的計算開銷很高，對其進行優化和異構移植具有重要意義.

1.2 計算熱點分析

本文在至強E5-2692 v2 處理器(主頻2.20 GHz)上進行測試以分析軟件的計算熱點.采用原始的串行程序，測試數據為單塊網格(含1 492 400個網格單元)，使用Vtune測得各個子程序執行時間百分比，如表1所示.由表1可知，程序時間開銷主要集中在與燃燒化學反應計算相關的子程序ws、與流場通量計算相關的子程序f_weno上.

Table 1 The Execution Time Percent of Subroutines in LESAP表1 各個子程序占總執行時間的百分比

2 面向CPU+MIC異構計算平臺的并行優化

相比多核的英特爾至強處理器，英特爾MIC架構具有更小的內核和更多的硬件線程，以及更寬的矢量單元，可以滿足高度并行化的應用需求，提高整體性能[11].MIC編程有許多編程模式，比較實用的模式有：1)native原生模式，程序只在MIC上執行計算任務，CPU處于空閑狀態；2)offload加載模式，即從CPU端啟動主函數，將部分計算核心通過offload模式加載到MIC上執行，Intel’s LEO 和OpenMP 4.0 都可以完成加載任務；3)symmetric對等模式，即從CPU和MIC各自啟動主函數，各自執行自己所負責的計算任務.

本文采用CPU為主MIC為輔的加載模式，使用MPI+OpenMP 4.0編程模型實現CPU+MIC異構協同并行，充分利用MIC眾核的性能優勢.CPU+MIC混合并行的難點主要是任務分配和負載均衡的問題，并且加載模式需要使用PCIe接口在兩種設備之間傳輸大量數據，是主要的性能瓶頸[21].下面將介紹如何使用OpenMP 4.0實現CPU+MIC異構協同并行、SIMD向量化、CPU與MIC間數據傳輸優化以及任務分配和負載均衡問題.

2.1 OpenMP 4.0 實現CPU+MIC異構協同并行

我們采用了一種異構并行計算模式，如圖2所示.單結點上運行多個MPI進程，每個進程處理一個網格區塊，每個進程使用OpenMP多線程方式利用結點內的一組CPU核.MPI進程有2種：一種是P1類型，完全在CPU上運行；另一種是P2類型，用一個CPU核發起主函數，通過使用OpenMP 4.0將計算量大、需要高度并行的計算核心加載到MIC上計算.

Fig. 2 The parallel model of running configuration圖2 CPU+MIC異構混合并行的并行模式

為了減少線程在核上的動態遷移帶來的額外開銷，我們采用了進程線程綁定的方式.對于P1類型的進程，根據進程數和CPU核數均勻分配多個CPU核，每個線程綁定一個CPU核；對于P2類型的MPI進程，則只需要一個線程，綁定到一個CPU核上.

我們設計靈活的輸入參數，以便于充分利用硬件資源，如表2所示.用戶可以結合自身的硬件環境，動態地設置用于計算的CPU、MIC卡數以及每個結點用于計算的網格數，并且可以調整每個結點上的CPU與MIC卡的任務分配，從而解決負載不均衡的問題.

Table 2 The Input Control Parameters of LESAP表2 LESAP運行時輸入的控制參數

在用戶設置了相應的參數后，LESAP再用這些參數根據本文設計的變量計算方法，見表3，得到相應的進線程綁定參數.

Table 3 The Variables Needed to Compute When the LESAP Runs表3 LESAP運行時通過計算得到的變量

Nproc4MIC是每個結點控制MIC卡的進程數，為每塊MIC卡處理的網格塊數NBperMIC與使用的MIC卡數NMIC之積.進程號按塊分配，每個結點上編號靠后的Nproc4MIC個進程用于控制MIC.該類進程即為P2類型進程，即offload進程，每進程綁定一個CPU核進行控制.剩下的每個結點上純CPU計算的進程數Nproc4CPU=NProcperNode-Nproc4MIC.該類進程即為P1類型進程，即純CPU計算，每進程綁定的線程數NTperCPUProc=(NCoreperNode-Nproc4MIC)Nproc4CPU.

為了更好地理解本文并行異構計算模式，這里給出一個例子，參數輸入格式如下：

mpirun -nRankNum-NNodeNum./
LESAP &nstep_maxsubstp_maxNnode
NCoreperNode&NBperNodeNMIC
NBperMICNTperMICProc.

假設輸入為：

mpirun -n 8 -N 1 .LESAP 1 10 1 24 8 3 2 224.

表示在單結點內運行8進程，處理的網格塊數為8.單步迭代10次，單結點內有24個CPU核，處理8塊網格數據，使用3塊MIC卡，每塊MIC卡分別處理2個網格塊，每個MIC進程開啟224個線程.那么P2類進程數Nproc4MIC=NBperMIC×NMIC=2×3=6,使用了6個CPU核來控制offload.P1類進程數Nproc4CPU=NProcperNode-Nproc4MIC=8-6=2，每P1進程綁定的CPU核數為

NTperCPUProc=(NCoreperNode-Nproc4MIC)/
Nproc4CPU= (24-6)/2=9.

OpenMP4.0編譯指導語句中增加了!$omp target，可以將CPU上的數據和代碼加載到MIC上運行.如圖3所示，OpenMP 4.0可以將部分高并行化的計算任務交給MIC卡計算，比如LESAP中的燃燒反應模塊中的ws子程序，實現以CPU為主MIC為輔的異構協同計算.其中to,from,tofrom指定了CPU與MIC之間的數據傳輸方式，使用布爾變量use_coprocessor標記MPI進程的計算核是在CPU上運行還是在MIC上運行,device可以指定使用的MIC卡設備號.

Fig. 3 The implementation of offloading to MIC usingOpenMP 4.0 device constructs
圖3 支持MIC設備加載模式計算的OpenMP 4.0實現

LEASP軟件計算流程復雜，函數調用關系復雜，異構移植的原則是根據表1中的子程序執行時間比例，盡量將運行時間開銷大的子程序進行移植，在移植變量或者子程序到MIC之前，需要用OpenMP 4.0的編譯指導語句!$omp declare target對變量或者子程序進行聲明.

2.2 CPU與MIC之間的數據傳輸優化

CPU與MIC之間大量的數據傳輸，是CPU+MIC混合異構并行的性能瓶頸.本文通過以下方法對數據傳輸進行了優化：1)MIC設備上的數據復用，不僅可以減少數據的傳輸時間開銷，還可以減少MIC卡的內存開銷；2)CPU與MIC間按需進行數據傳輸，每次在CPU和MIC間進行數據傳輸時，只傳遞相應計算步中需要使用到的變量，以此來降低CPU與MIC之間的數據傳輸開銷.

OpenMP4.0提供了2種編譯指導語句可以實現數據傳輸優化:1)!$omp target data，可以創建大的device data數據環境，當一個變量在一個封閉的device data數據環境內時，新的數據環境可以從這個封閉的環境中使用這個變量，也即復用這個變量，而不需要分配額外的內存，也不需要初始化和賦值.2)!$omp target update，可以保持MIC端和CPU端的變量的值一致.

本文使用!$omp target data盡早建立一個device data環境，將需要多次使用的數據傳輸到MIC上，并將需要加載到MIC上的代碼段放到這個device data數據環境中.在這個環境內可以通過!$omp target map傳輸新數據，并將代碼加載到MIC上.如果出現數據更新時，則使用!$omp target update tofrom來傳輸數據，保證數據的一致性.CPU與MIC之間數據傳輸優化的OpenMP 4.0實現方式如圖4所示:

Fig. 4 Optimizing the data movement by OpenMP 4.0. the structured-block can be loops and or subroutines圖4 CPU與MIC之間數據傳輸優化的OpenMP4.0實現

2.3 CPUMIC協同計算負載均衡優化

由于主頻與核數的不同，CPU與MIC之間的處理能力存在差異.為了達到不同平臺之間的負載均衡，需要根據CPU和MIC的任務處理能力進行任務分配.本文主要做了以下2個層次的負載均衡：1)CPUMIC協同計算時，單結點內CPU設備與MIC設備之間的負載均衡;2)設備(CPU或者MIC)內部各線程之間的負載均衡.

2.3.1 CPUMIC設備間的負載均衡

由于CPU與MIC的計算能力不同，所以CPU與MIC劃分的網格數不能相同.動態分配的方式雖然在負載均衡性能上效果很好，但是會增加額開銷，MPI進程間通信的開銷比進程內通信開銷大很多.并且LESAP軟件屬于數據密集型應用，網格數據劃分只能采用靜態數據劃分的方法，為了減少通信開銷，我們采用靜態任務劃分，每個進程處理一個網格塊.

為了充分利用CPU和MIC的任務處理能力，提高LEASP軟件的最佳模擬性能，我們增加了MIC卡數、每個MIC卡的網格計算塊數和MIC卡上的線程數等控制參數.在運行LESAP軟件時，設置不同的控制參數可以對MIC和CPU進行任務分配.

假定整個模擬流場區域由K個均勻劃分的網格塊組成，單結點內創建a個P1類型的MPI進程，創建b個P2類型的MPI進程，整個計算的總進程數為P=a+b.每個進程處理一個網格塊，則P=K，實現CPU與MIC設備間的負載均衡的關鍵是使用多少塊MIC卡處理多少網格數據，下面建立其數學描述.

假設M為CPU端網格塊數，i為使用的MIC卡數，N為每塊MIC卡處理的網格塊數，則有

a=M,M∈{1,2,…,K-1},

(1)

b=i×N,b∈{1,2,…,K-1},

(2)

K=M+i×N.

(3)

Fig. 5 8-grid calculation example allocated in a single-node CPU+MIC heterogeneous platforms圖5 8塊網格算例在單結點CPU+MIC異構平臺上的任務分配

假設t為MIC線程數，T為模擬運行時間，本文的負載平衡方案是通過調節M,i,N,t,MIC_KMP_AFFINITY,尋找一個最佳負載分配方案，使得模擬運行時間T最小，即大致達到了負載均衡.圖5為8塊網格算例在單結點CPU+MIC異構平臺上的任務分配圖，8塊網格算例，2塊網格由CPU端處理，剩下6塊網格由3塊MIC卡處理，每塊MIC處理2塊網格.

2.3.2 CPUMIC設備內的負載均衡

設備內的負載均衡分2個層次，一個是循環迭代分配到線程上的方式，另一個是線程分配到硬件計算核心上的方式.在每個設備(CPU或MIC)內，通過OpenMP實現了多線程并行.對于第1個層次，OpenMP提供了schedule設置線程分配方式，主要有static靜態分配和dynamic動態分配.由于LESAP計算過程中每個進程所計算的網格單元數固定，并且每次迭代任務量相同，我們選擇了static靜態分配.

對于第2個層次，在CPU設備內，為了減少線程在核上的動態遷移帶來的額外開銷，我們采用一個線程綁定一個CPU核的方式.在MIC卡內，我們通過環境變量MIC_KMP_AFFINITY來設置MIC上的線程與MIC計算核心的綁定方式，可取的值有：1)scatter分散模式，將線程優先分配到負載最輕的物理核心上；2)compact緊密模式，將線程按順序分配至邏輯核心上；3)balanced平衡模式，盡量將線程分配到負載較輕的物理核心，也會盡量將相鄰線程分配到同一個物理核心上.這3種方式都是靜態劃分方式，因此需要根據程序運行的實際負載情況，有針對性地進行設置，才能達到比較好的效果.

MIC卡包含眾多物理核，每個核上可以開啟4個線程，只有讓MIC卡上的核充分利用起來才能發揮MIC的最大性能.但如果線程數設置太多，線程開銷比較大，也會造成負載不均衡，所以需要尋找一個合適的線程數，可以保證程序的并發度和MIC核的高可利用率.

2.4 ws優化

由第1.2節的熱點分析可知，與燃燒化學反應計算相關的子程序ws占據了主要的計算時間.子程序ws計算部分主要集中在一個3重循環中，如圖6(a)所示.由于ws子程序在reaction函數的循環中被調用，源代碼為了提高OpenMP的并行粒度，直接對reaction中的循環做OpenMP并行化，子程序ws中的循環則不需再做OpenMP并行.由圖6(a)可以看出，IF條件語句的作用是根據chemf變量和CC變量計算出中間變量rPow，中間變量rPow在這個3層循環中的計算量是(ns-1)×Nrec×ns次.而Chemf(ir,is),CC(is)與最外層循環無關，中間變量rPow的計算量實際上存在大量的冗余.這部分代碼中的IF-ELSE分支語句導致編譯器無法自動向量化.本文對其進行循環拆分，將rPow單獨提前計算出結果，存放在一個二維數組中，如圖6(b)所示，計算量則變成Nrec×ns次,計算量減少(ns-2)×Nrec×ns次，剩余的代碼則可以通過增加!$omp simd private(is) reduction(*:pif)編譯指導語句實現向量化.ws計算過程中存在很多類似圖6中的rPow中間變量，我們對這些中間變量都進行了循環拆分優化，計算量較大幅度降低，性能得到較大的提升.

Fig. 6 The optimization for ws
圖6 ws中的循環拆分優化

3 測試結果與分析

3.1 測試平臺與環境

為了評估上節異構并行優化方案的有效性，我們在天河二號單個結點上進行了性能測試.測試平臺的環境與參數如表4所示，系統由2個12核的至強E5-2692 v2的CPU 和3塊57核的Xeon Phi 31S1P(MIC)加速器組成.CPU內存共128 GB，單MIC卡共8 GB內存.由于LESAP軟件采用Fortran90語言開發，編譯器使用Intel ifort v14，支持OpenMP 4.0.使用“-O2-axAVX-fno-alias”的編譯器優化選項，MIC_USE_2MB_BUFFERS=32 KB.性能計時僅針對圖1流程中的時間步迭代，不計讀取數據和初始化的時間，測試平均每個時間步的執行時間，每一個時間步含10次子迭代.采用網格規模約532萬(5 320 896)單元的9塊網格算例進行性能測試.

Table 4 The Test Platform and Environment of One Node表4 單結點測試平臺與環境

3.2 測試結果與討論分析

我們將LESAP軟件分為3個版本：1) MPI-OMP表示實現了MPI+OpenMP兩級并行，運行于CPU平臺的原始版本；2)HYB-OMP4表示使用OpenMP 4.0對原始版本進行了CPU+MIC異構并行移植，并經過數據傳輸優化和負載均衡優化后的運行于CPU+MIC混合平臺的版本；3)HYB-OPT 表示對上述異構版本進行了向量化優化后的最終優化版本.

3.2.1 CPU與MIC的負載均衡效果及分析

我們用規模約532萬網格單元的9塊網格算例對LESAP軟件的原始版本MPI-OMP只使用CPU進行并行數值模擬，在單結點上單步迭代執行時間約為64.72 s，占用CPU內存約9.9 GB.之后對HYB-OMP4版本進行負載均衡效果測試.測試目標是找出對于該網格算例最佳的CPUMIC的網格分配，MIC線程數以及MIC線程綁定模式，使得LESAP軟件負載均衡，達到最好的性能.測試平臺為含有2個至強CPU和3塊57核的MIC組成的單結點，則MIC卡數最大值為3.MIC卡上的57個物理核心中包含4個硬件線程，因為其中1個物理核心通常用于運行操作系統及相關服務，所以余下的56個核含224個線程.由于應用程序必須很好地擴展出超過100個線程才能達到高度并行的要求[21]，以充分利用MIC多核的優勢，我們在每塊MIC卡上使用的線程數分別為112(每核上開啟2個線程)或者224(每核上開啟4個線程)，并使用9塊網格在不同MIC卡數、MIC卡處理的網格塊數以及MIC_KMP_AFFINITY情況下進行對比.

測試結果如表5所示，其中i為MIC卡數，N為每塊MIC卡處理的網格塊數，t為MIC線程數，MIC_KMP_AFFINITY為設置MIC線程綁定模式的環境變量.根據實驗環境的硬件條件進行不同的條件設置，使得CPU與MIC端的負載盡可能平衡，從而得到一個最佳的性能.由表5可知，對于HYB-OMP4,線程的綁定方式對LESAP的性能沒有較大的提升.線程數為112與224在不同的硬件配置下，性能差異不大.HYB-OMP4的性能隨著使用的MIC數i和每塊MIC卡處理的網格塊數N的增加而增加.

Table 5 The Execution Time of HYB-OMP4 on Different Cases表5 不同條件下HYB-OMP4版本的單步迭代執行時間 s

可以看出，LESAP軟件的HYB-OMP4版本在天河二號單結點異構平臺處理約532萬網格單元的9塊網格算例時，MIC線程數t=112，綁定方式MIC_KMP_AFFINITY=compact時，選擇分配給CPU端處理的網格塊數M=3，分配給MIC處理的網格塊數i×N=3×2=6，單步迭代執行時間T最短，約23.28 s，與原始版本相比，加速比達2.78倍.

3.2.2 HYB-OPT最終版本的效果及分析

在HYB-OMP4的基礎上進行ws優化之后，得到HYB-OPT版本，我們使用該9塊網格算例進行測試以檢驗向量化優化的效果.取CPU端處理的網格塊數M=3，MIC處理的網格塊數i×N=3×2=6，MIC線程數t=112，綁定方式MIC_KMP_AFFINITY=compact，測得的單步迭代執行時間約為21.06 s.與HYB-OMP4相比，性能提升9.5%，與原始的純CPU版本MPI-OMP相比，加速比達到了3.07左右.LESAP軟件不同版本的單步迭代執行時間及加速比情況如圖7所示:

Fig. 7 The execution time and speed-up of different LESAP versions圖7 LESAP軟件不同版本的單步迭代執行時間及加速比

4 結論與未來工作

本文面向CPU+MIC異構并行平臺，針對一個實際的已經實現MPIOpenMP兩級并行的超燃沖壓發動機燃燒數值模擬軟件，使用OpenMP4.0實現以CPU為主MIC為輔模式的并行移植，并采用了數據傳輸優化、負載均衡優化及向量化優化等性能優化技術.針對異構平臺計算能力的差異，進行了一系列的負載均衡分析和測試.性能測試表明，對于約532萬網格單元規模的實際應用算例，LESAP軟件每時間步的平均執行時間從64.72 s減少到21.06 s，相對于原始版本加速比達到3.07.

本文工作充分利用異構并行計算平臺的特點，顯著縮短了超燃沖壓發動機燃燒數值模擬的執行時間，節省了機時費用開銷.后續工作主要是進一步提高CPU+MIC的協同并行計算能力，探究更為合理的CPU與MIC負載均衡模型，以取得更好的異構并行性能加速效果.

致謝感謝國防科學技術大學航天科學與工程學院汪洪波提供LESAP原始代碼!

[1]Niu Dongsheng, Hou Lingyun, Pan Pengfei, et al. Three-dimensional combustion numerical simulation of scramjet internal and external flow fields[J]. Journal of Aerospace Power, 2014, 29(4): 763-769 (in Chinese)(牛東圣, 侯凌云, 潘鵬飛, 等. 超燃沖壓發動機內外流場三維燃燒數值模擬[J]. 航空動力學報, 2014, 29(4): 763-769)

[2]Baidupedia. Hypersonic aircraft[OL].[2016-04-12]. http://baike.baidu.com/view/3564607.htm

[3]Wang Hongbo, Wang Zhengguo, Sun Mingbo, et al. Combustion characteristics in a supersonic combustor with hydrogen injection upstream of cavity flameholder[J]. Proceedings of the Combustion Institute, 2013, 34(2): 2073-2082

[4]Wang Hongbo, Sun Mingbo, Qin Ning, et al. Characteris-tics of oscillations in supersonic open cavity flows[J]. Flow, Turbulence and Combustion, 2013, 90(1): 121-142

[5]Wang Hongbo, Wang Zhengguo, Sun Mingbo, et al. Large eddy simulation based studies of jet-cavity interactions in a supersonic flow[J]. Acta Astronautica, 2014, 93(1): 182-192

[6]Wang Hongbo, Wang Zhengguo, Sun Mingbo, et al. Simulations of combustion with normal and angled hydrogen injection in a cavity-based supersonic combustor[J]. Proceedings of the Institution of Mechanical Engineers Part G Journal of Aerospace Engineering, 2014, 228(4): 530-541

[7]Liu Li, Yang Guangwen. A highly efficient GPU-CPU hybrid parallel implementation of sparse LU factorization[J]. Chinese Journal of Electronics, 2012, 21(1): 7-12

[8]TOP500.org. Top 500 supercomputer sites[OL].[2016-11-25]. http://www.top500.org/

[9]Liao Xiangke, Xiao Liqun, Yang Chanqun, et al. MilkyWay-2 supercomputer: System and application[J]. Frontiers of Computer Science, 2014, 8(3): 345-356

[10]Wu Qiang, Yang Chanqun, Tang Tao, et al. Exploiting hierarchy parallelism for molecular dynaMICs on a petascale heterogeneous system[J]. Journal of Parallel & Distributed Computing, 2013, 73(12): 1592-1604

[11]Wang Endong, Zhang Qing, Shen Bo, et al. The Programming Guide for MIC High Performance Computing[M]. Beijing: China Water&Power Press, 2012

[12]Intel Corporation. User and Reference Guide for the Intel C++ Compiler 14.0[OL].[2016-04-12]. http://www.spec.org/mpi2007/flags/EM64T_Intel140_flags.20140908.html

[13]OpenMP Architecture Review Board. OpenMP application program interface version 4.0[OL].[2016-04-12]. http://www.openmp.org/

[14]McIntosh-Smith S, Boulton M, Curran D, et al. On the performance portability of structured grid codes on many-core computer architectures[C] //Proc of the 29th Int Conf on ISC 2014. Berlin: Springer, 2014: 53-75

[15]Liu Yang, Deng Liang. Acceleration of CFD engineering software on GPU and MIC[M] //Algorithms and Architectures for Parallel Processing. Berlin: Springer, 2015: 835-848

[16]Deng Liang, Bai Hanli, Zhao Dan, et al. Kepler GPU vs Xeon Phi: Performance case study with a high-order CFD application[C] //Proc of IEEE Int Conf on Computer and Communications. Piscataway, NJ: IEEE, 2015: 87-94

[17]Che Yonggang, Xu Chuanfu, Fang Jianbin, et al. Realistic performance characterization of CFD applications on Intel many integrated core architecture[J]. The Computer Journal, 2015, 58(12): 3279-3294

[18]Xu Chuanfu, Deng Xiaogang, Zhang Lilun, et al. Collaborating CPU and GPU for large-scale high-order CFD simulations with complex grids on the TianHe-1A supercomputer[J]. Journal of Computational Physics, 2014, 278: 275-297

[19]Spalart P, Jou W, Strelets M, et al. Comments on the feasibility of LES for wings, and on a hybrid RANS/LES approach[J]. Advances in DNS/LES, 1997, 1: 4-8

[20]Jiang Guangshan, Shu Chiwang. Efficient implementation of weighted ENO schemes[J]. Journal of Computational Physics, 1996, 126(1): 202-228

[21]Jeffers J, Reinders J. Intel Xeon Phi Coprocessor High Performance Programming[M]. San Francisco: Margan Kaufmann, 2013