韋耀杰 符杰林 勞保強

(1 桂林電子科技大學(xué)信息與通信學(xué)院認知無線電與信息處理教育部重點實驗室 桂林 541004)

(2 中國科學(xué)院上海天文臺 上海 200030)

(3 云南大學(xué)物理與天文學(xué)院 昆明 650500)

1 引言

連續(xù)譜巡天是平方公里陣列(Square Kilometre Array, SKA)射電望遠鏡的主要觀測模式之一,主要涉及銀河系和河外星系成像星表, 用于探查宇宙的恒星形成史[1]. SKA連續(xù)譜巡天觀測是研究星系演化、宇宙中大規(guī)模結(jié)構(gòu)的演化、宇宙磁場等關(guān)鍵科學(xué)目標(biāo)的重要手段. 基于連續(xù)譜成像建立巡天區(qū)域的標(biāo)準(zhǔn)星圖, 將能為后續(xù)天文科學(xué)研究建立重要科研基礎(chǔ).

SKA是一個國際合作大科學(xué)工程, 旨在建造世界上最大的射電望遠鏡[2]. 它將分兩個階段建造,本文的成像管線主要為第一階段的低頻孔徑陣列SKA1-Low作先導(dǎo)應(yīng)用. SKA1-Low將落于西澳大利亞的默奇森地區(qū)[3], 此外, 世界各地也已開展了多個SKA先導(dǎo)望遠鏡項目, 例如位于荷蘭的低頻陣列(Low Frequency Array, LOFAR)[4]、位于英國的增強型多元素遠程鏈接干涉儀網(wǎng)絡(luò)(enhanced Multi Element Remotely Linked Interferometer Network, e-MERLIN)[5]、位于澳大利亞的澳大利亞SKA探路者(Australian Square Kilometre Array Pathfinder, ASKAP)[6]和默奇森寬場陣列(Murchison Wide-field Array, MWA)[7–8].

位于西澳大利亞默奇森射電天文臺的MWA望遠鏡是SKA三個先導(dǎo)望遠鏡之一. 銀河系與河外星系全天默奇森寬場陣列巡天(GaLactic and Extragalactic All-sky MWA survey, GLEAM)是MWA 2013–2015年間的寬視場連續(xù)譜巡天, 在72–231 MHz的頻率范圍內(nèi)對北緯30?以南的天空進行巡天覆蓋[9]. GLEAM巡天為MWA留下了重要的低頻巡天數(shù)據(jù)集,并且GLEAM數(shù)據(jù)正在用于許多銀河系、河外科學(xué)計劃. 雖然GLEAM取得了巨大的科學(xué)成果, 其低頻巡天數(shù)據(jù)有助于宇宙黎明和再電離時期的探測研究, 但它從根本上受到其較低分辨率和MWA原始配置的靈敏度限制, 仍有進一步優(yōu)化和改進的空間.

銀河系與河外星系全天默奇森寬場陣列拓展巡天(GaLactic and Extragalactic All-sky Murchison Widefield Array survey eXtended,GLEAM-X)是2018–2020年利用SKA先導(dǎo)望遠鏡MWA二期拓展陣列開展的新的射電連續(xù)譜巡天項目[10]. 該巡天的觀測頻率范圍是72–231 MHz, 巡天覆蓋范圍與GLEAM巡天相同, 即北緯30?以南所有的天空區(qū)域, 約30000 deg2. GLEAM-X的靈敏度和角分辨率能到達1–2 mJy和約45′′, 分別是GLEAM的約6倍和2倍以上. 因此, GLEAM-X將能夠探測到更多射電源, 所探測到的射電源也更清晰. 該巡天將能夠產(chǎn)出包括連續(xù)譜與偏振圖像、多頻段星表、瞬變體搜索數(shù)據(jù)和電離層測量等科學(xué)數(shù)據(jù)產(chǎn)品, 其中連續(xù)譜圖像和多頻段星表是該巡天的首要科學(xué)數(shù)據(jù)產(chǎn)品. GLEAM-X巡天總共進行了超過40000次的快照觀測, 總數(shù)據(jù)量約為2 PB, 處理完成所有觀測數(shù)據(jù)需要近2000萬CPU核小時. 面對GLEAM-X如此龐大的數(shù)據(jù)量, 急需開發(fā)自動化的并行處理管線進行數(shù)據(jù)的批量處理.

目前處理天文數(shù)據(jù)最常用的方法是在腳本中靜態(tài)地定義工作管線的步驟組件, 這些腳本要么在本地機器上按順序執(zhí)行, 要么包裝到作業(yè)腳本中,提交給作業(yè)調(diào)度系統(tǒng)來執(zhí)行[11]. 這對于SKA規(guī)模的數(shù)據(jù)處理(具有數(shù)千萬個并發(fā)任務(wù))并不可行, 而且管線的故障檢測和后續(xù)恢復(fù)操作(例如重新執(zhí)行)的代價非常高昂. 在數(shù)據(jù)并行處理方面, 工業(yè)數(shù)據(jù)密集型應(yīng)用程序通常使用通用的數(shù)據(jù)并行框架, 如MapReduce[12]、Dryad[13]、Spark[14]等來處理大批量數(shù)據(jù), 但直接使用它們來處理SKA天文數(shù)據(jù)時會出現(xiàn)兩個問題: (1)大多數(shù)的數(shù)據(jù)并行框架需要將大的數(shù)據(jù)集拆分為小的數(shù)據(jù)塊, 然后并行處理每個拆分塊, 然而天文數(shù)據(jù)集通常涉及多個復(fù)雜維度來對數(shù)據(jù)集進行切片, 通用的數(shù)據(jù)并行框架難以支持SKA天文數(shù)據(jù)的多維度拆分; (2)現(xiàn)有數(shù)據(jù)并行框架的數(shù)據(jù)流優(yōu)化對于商業(yè)工作管線可能非常有效, 但是它們在天文數(shù)據(jù)管線中的相關(guān)性和實用性卻非常有限, 難以滿足天文數(shù)據(jù)處理的科學(xué)標(biāo)準(zhǔn).

此外, 現(xiàn)有的GLEAM-X管線還存在著一些問題: (1)管線的每個步驟都由獨立的腳本文件來執(zhí)行, 各個管線步驟的運行參數(shù)修改和部署實現(xiàn)較為繁瑣, 不利于管線的自動化批量處理; (2)由于GLEAM-X的快照數(shù)據(jù)量較大, 成像時間更長, 單條管線的處理需要更多的計算資源, 且單條管線的處理時間較長, 需要一個能根據(jù)數(shù)據(jù)處理任務(wù)的計算需求自動分配硬件資源、同時處理大批量快照數(shù)據(jù)的高效穩(wěn)定的多管線并行處理方法; (3)隨著SKA建設(shè)的不斷推進, 其所產(chǎn)生的數(shù)據(jù)量也將會增加數(shù)十倍, 傳統(tǒng)的并行方式可能不足以支持如此大規(guī)模的數(shù)據(jù)流擴展并行, 因此, 并行處理方法還需要有更靈活的適配能力和更強大的可擴展性, 能將單條管線擴展為上萬條管線并行處理.

因此, 針對以上問題, 我們將多個獨立的管線步驟整合成規(guī)范統(tǒng)一的成像流程并驗證其數(shù)據(jù)處理的正確性, 然后嘗試使用基于任務(wù)排隊系統(tǒng)的管線Bash腳本并行方式、基于Message Passing Interface (MPI)的并行擴展方式、基于Data Activated Liu Graph Engine (DALiuGE)執(zhí)行框架的自動化并行處理方式3種方法將原本的單一串行管線改進為多條管線并行的數(shù)據(jù)處理流程, 并通過對比各方法的綜合運行性能來尋找最優(yōu)的并行處理方案.

2 低頻射電干涉陣列成像管線

本文的低頻射電干涉陣列成像管線選取自MWA GLEAM-X成像管線, 本章主要介紹GLEAM-X觀測數(shù)據(jù)、成像管線的詳細流程步驟.

2.1 GLEAM-X觀測數(shù)據(jù)

與GLEAM巡天相同, GLEAM-X整個天區(qū)巡天由7次不同位置的漂移掃描完成, 整個觀測頻段劃分為5個子頻段, 能提供接近連續(xù)覆蓋的頻率范圍, 但棄用了受衛(wèi)星等射電頻率干擾嚴重的135–138 MHz附近的頻段. 每個子頻段的帶寬為30.72 MHz, 每個子頻段由連續(xù)的24個頻率通道組成, 每個通道頻率帶寬為1.28 MHz, 每個頻率通道標(biāo)注為0–255的數(shù)字編號, 5個子頻段中心頻率通道編號分別為: 69、93、121、145和169. GLEAMX觀測是一系列為期4周共28晚的快照觀測,為了避免太陽光照對觀測的影響, 漂移掃描觀測僅在夜間進行. 在一晚的觀測時間內(nèi), 每個子頻段以0.5 s的時間分辨率每120 s記錄一次數(shù)據(jù), 稱為2 min快照觀測數(shù)據(jù), 10 min則完成5個子頻段數(shù)據(jù)的觀測. 每個快照數(shù)據(jù)文件以起始觀測的GPS時間作為ID號命名.

2.2 成像管線流程步驟

本文的低頻射電干涉陣列成像管線是基于開源的GLEAM-X成像管線開發(fā)1https://github.com/tjgalvin/GLEAM-X-pipeline, 管線主要用于處理GLEAM-X的快照觀測數(shù)據(jù). 該管線的主要流程步驟如圖1所示, 具體步驟描述如下:

圖1 GLEAM-X快照數(shù)據(jù)成像管線Fig.1 Imaging pipeline for GLEAM-X snapshot data

(1)原始快照觀測數(shù)據(jù)下載(Download Data).目前, 快照數(shù)據(jù)主要通過MWA全天虛擬天文臺(All-Sky Virtual Observatory, ASVO)[15]下載,MWA ASVO給用戶提供了兩種下載方式. 第一種方式是利用ASVO網(wǎng)頁交互式界面的‘New Data Job’功能提交下載作業(yè), 等待作業(yè)完成后, 通過提供的下載鏈接手動下載數(shù)據(jù). 第二種方式是, 利用ASVO提供的命令行客戶端(manta-ray-client),將需要下載的快照數(shù)據(jù)的觀測ID寫入逗號分隔值(Comma-Separated Values, CSV)格式文件, 提交下載作業(yè)后, 可以實時監(jiān)測下載作業(yè)的狀態(tài)并在作業(yè)完成后自動下載數(shù)據(jù). 因此, 第二種方式比較適用于數(shù)據(jù)的大批量自動下載. 下載的原始觀測快照數(shù)據(jù)為ZIP壓縮文件, 該壓縮文件包含: 可見度數(shù)據(jù)文件(gpubox.fits)、觀測元數(shù)據(jù)文件(metafits和ppds)、射電頻率干擾(Radio Frequency Interference, RFI)初步標(biāo)記文件(flags.zip和mwaf);

(2)快照數(shù)據(jù)解壓與數(shù)據(jù)預(yù)處理(Cotter). 對下載完成的快照數(shù)據(jù)壓縮文件進行解壓, 然后進行數(shù)據(jù)預(yù)處理. 數(shù)據(jù)預(yù)處理步驟采用的是Offringa等人開發(fā)的Cotter軟件[16], 該軟件是MWA數(shù)據(jù)專用的數(shù)據(jù)預(yù)處理軟件, 通過讀取可見度、觀測時間與頻率等數(shù)據(jù), 按照預(yù)設(shè)的4 s時間分辨率和40 kHz頻率分辨率對可見度數(shù)據(jù)進行時間平均和頻率平均;之后讀取RFI初步標(biāo)記文件信息,Cotter使用Andr′e Offringa’s Flagger(AOFlagger)[17]軟件中的算法進行RFI檢測和損壞天線的標(biāo)記, 并計算相關(guān)統(tǒng)計數(shù)據(jù)和校正電纜長度延遲相位; 最后, 由于后續(xù)步驟的數(shù)據(jù)處理軟件或程序是基于CASA核心軟件庫Casacore[18]開發(fā)的, 還需要將處理后的文件轉(zhuǎn)換為通用天文軟件應(yīng)用程序Common Astronomy Software Applications (CASA)的MeasurementSet(MS)[19]格式文件;

(3)故障天線標(biāo)記(Autoflag). 由于步驟(2)中的損壞天線標(biāo)記是根據(jù)觀測時的記錄文件進行的, 個別天線故障沒有被及時記錄, 這一步驟是根據(jù)觀測工程師或者校準(zhǔn)源數(shù)據(jù)處理中提供的天線受損記錄, 進行重新標(biāo)記, 以免有漏標(biāo)的故障天線影響后續(xù)的數(shù)據(jù)處理結(jié)果;

(4)天空模型建立與校準(zhǔn)解生成(Auto Calibrate).鑒于GLEAM-X與GLEAM的巡天天區(qū)覆蓋范圍和觀測頻率均相同, 因此可以使用現(xiàn)有的GLEAM視場模型對GLEAM-X觀測數(shù)據(jù)進行校準(zhǔn). 首先, 在已發(fā)表的GLEAM星表中尋找GLEAM-X快照觀測數(shù)據(jù)視場范圍內(nèi)同波段、同位置的射電分量或源信息(流量密度和位置等). 然后, 基于這些信息制作出該快照數(shù)據(jù)的初始天空模型, 并按照Andre格式輸出模型文件2https://github.com/PaulHancock/MWA-SkyModel. 最后, 天空模型文件和快照數(shù)據(jù)輸入到校準(zhǔn)算法進行校準(zhǔn)解的產(chǎn)生, 校準(zhǔn)算法采用Offringa等人提出的MitchCal算法[20], 該算法將計算出天空模型與實際快照觀測的可見度數(shù)據(jù)所有點的幅度和相位偏移量, 這些偏移量再進行最小二乘法擬合獲得最終的校準(zhǔn)解, 這個校準(zhǔn)解可以修正實際快照數(shù)據(jù)的幅度和相位誤差;

(5)目標(biāo)場數(shù)據(jù)校準(zhǔn)(Apply Calibrate). 將步驟(4)中生成的校準(zhǔn)解應(yīng)用于快照觀測的可見度數(shù)據(jù)進行幅度和相位校準(zhǔn), 這一步能夠消除觀測設(shè)備和大氣等大部分干擾因素的影響;

(6)基線數(shù)據(jù)標(biāo)記(Uvflag). 掃描檢查校準(zhǔn)后的可見度數(shù)據(jù)是否有遺漏的RFI未進行標(biāo)記, 將標(biāo)記的故障天線對應(yīng)UV基線的可見度數(shù)據(jù)進行標(biāo)記.該步驟能夠盡可能地消除廣播調(diào)頻信號和數(shù)字電視信號對該頻段觀測數(shù)據(jù)的干擾影響;

(7)深度成像(Deep Image). 深度成像主要利用w方向疊片潔化(W-Stacking Clean, WSClean)軟件[21]中的wsclean命令實現(xiàn), 最終生成2 min快照圖像. 主要的成像參數(shù)設(shè)置如表1所示. 在成像方面,GLEAM-X的觀測視場大小與GLEAM相同, 但角分辨率提高了約2倍, 因此輸出的圖像大小需增大2倍, 即8000×8000. 每個像素的大小(像素分辨率)一般設(shè)為望遠鏡角分辨率的四分之一或五分之一,可以由基礎(chǔ)像素分辨率除以子頻段中心頻率的編號數(shù)(單位rad)得到每個數(shù)據(jù)的具體像素分辨率, 其中基礎(chǔ)像素分辨率為0.6. 由于GLEAM-X觀測視場較大(約30?×30?), 視場范圍內(nèi)將包含不同大小尺度的射電源,傳統(tǒng)的潔化(Clean)方法已經(jīng)無法滿足其成像處理的更高動態(tài)范圍的要求, 而WSClean支持多尺度潔化(Multi-scale Clean)算法[22], 能夠更好地重建延展結(jié)構(gòu)的射電源. 因此在參數(shù)設(shè)置上選擇multiscale的主要迭代潔化增益為0.85, 即在每個主要迭代中減去85%的流量密度, 多尺度增益參數(shù)使用默認值0.15. 最初的GLEAM數(shù)據(jù)使用了具有魯棒性參數(shù)為-1的“Briggs”圖像加權(quán)[23],但這種加權(quán)不適用于MWA二期擴展配置, 對于GLEAM-X,通常首選natural的加權(quán)模式以最大限度地提高靈敏度, 但是與GLEAM相比, natural加權(quán)的角分辨率提高僅為1.5倍, 并且點源靈敏度沒有最大化. 為了在保持整體靈敏度的同時平衡分辨率的提高, 最終選擇了+0.5魯棒性參數(shù)的“Briggs”圖像加權(quán)[24],它提供的自動調(diào)節(jié)權(quán)重(weighting)方法, 可以獲得更均衡的成像效果. 此外設(shè)置潔化最大迭代次數(shù)為10000000次, 迭代閾值在均方根RMS (Root Mean Square)噪聲1σ-3σ之間動態(tài)調(diào)節(jié), 在成像中所選取的數(shù)據(jù)為校準(zhǔn)過后的數(shù)據(jù)列;

表1 wsclean成像主要參數(shù)設(shè)置Table 1 Main parameter settings of wsclean imaging

(8)成像后處理(Postimage). 對深度成像生成的圖像執(zhí)行電離層校正, 主要為了消除電離層引起的干擾. 電離層的干擾會導(dǎo)致射電源的相位偏移,該偏移會隨電離層位置的不同而發(fā)生變化. 對于成像后的快照圖像, 首先使用背景噪聲估計(Background And Noise Estimation,BANE)[25]工具計算背景和RMS噪聲σ, 并使用源查找軟件包Aegean[25]進行源查找, 最小閾值為5σ. 之后根據(jù)Hurley-Walker等[26]的方法, 使用[27]軟件包的星表交叉匹配功能, 將查找到的源與GLEAM巡天星表進行交叉匹配, 通常保留約3000個交叉匹配源, 從中選取750個較亮的源, 更多的源無法提高校正的準(zhǔn)確性, 而且會增加計算負擔(dān), 因此選擇該值作為收益遞減點. 然后, 根據(jù)快照圖像中保留的源與參考星表源之間的位置差異計算偏移量,使用這些偏移量來創(chuàng)建修正模型, 將其應(yīng)用于原始快照圖像, 并將修正后的結(jié)果內(nèi)插回圖像完成位置校正. 之后使用[28]軟件包以類似的方式進行流量密度校正, 最后重新使用Aegean對處理后的快照圖像進行源查找, 對比源的數(shù)量檢驗校正效果;

(9)圖像重設(shè)(Rescale). 對步驟(8)處理后的圖像進行圖像重縮放. 首先, 讀取上一步Aegean對圖像進行源查找的結(jié)果, 使用stilts軟件[29]將其與步驟(4)的天空模型進行交叉匹配, 獲取快照圖像與參考模型的赤經(jīng)(Right Ascension, RA)和赤緯(Declination, Dec)的偏移量以及流量密度的比值,使用sigma_clip算法[29]來識別和去除小于中位數(shù)減標(biāo)準(zhǔn)差或大于中位數(shù)加標(biāo)準(zhǔn)差的異常值數(shù)據(jù), 接著對修正前后的RA和Dec數(shù)據(jù)進行多項式擬合并繪制擬合曲線的圖像以供后續(xù)的誤差分析使用, 然后生成快照圖像的背景、RMS和拼接權(quán)重文件,最后根據(jù)RA、Dec的偏移量(?RA、?DEC)計算出GLEAM-X快照圖像的矢量化函數(shù), 對圖像像素進行矢量化處理, 重設(shè)圖像的比例尺, 生成重新縮放的fits文件.

3 基于任務(wù)排隊系統(tǒng)的成像管線Bash腳本并行優(yōu)化

本章主要介紹在CSRC-P (China SKA Regional Centre Prototype)原型機上對管線的部署實現(xiàn)和并行優(yōu)化, 并對其正確性進行驗證.

3.1 成像管線在CSRC-P上的環(huán)境部署

開源版本的GLEAM-X管線是基于Singularly容器鏡像環(huán)境和澳大利亞Pawsey超算中心Galaxy超級計算機軟件環(huán)境開發(fā)和運行的[30]. 為了能夠在CSRC-P原型機上部署并運行該成像管線, 我們進行了管線軟件環(huán)境的部署以及相關(guān)代碼的修改.

所部署的軟件包括: cotter v4.6、AOFlagger v3.0、mwa-reduce-2022、WSClean v2.9、stilts v3.4等. 由于原型機所有節(jié)點安裝的操作系統(tǒng)為Centos 7.03https://www.centos.org/, 我們編寫了一個能自動化進行所有軟件部署安裝的Bash腳本, 腳本內(nèi)包含了下載、解壓、編譯、配置、安裝等軟件部署步驟的命令語句, 且涵蓋了需要以同樣步驟安裝的大量前置依賴軟件包的部署命令. 為了便于用戶動態(tài)地修改自己的軟件環(huán)境, 且不影響其他用戶的軟件環(huán)境, 實驗的軟件環(huán)境采用環(huán)境變量管理工具Modules4http://modules.sourceforge.net進行管理, 當(dāng)進行GLEAM-X巡天數(shù)據(jù)處理時, 只需要在提交的任務(wù)腳本中載入對應(yīng)軟件的模塊文件modulefiles,即可使用所部署的數(shù)據(jù)處理軟件環(huán)境.

此外, 通過多次實驗發(fā)現(xiàn), 由于GLEAM-X的快照數(shù)據(jù)量較大、成像時間更長, 與GLEAM數(shù)據(jù)的一個計算節(jié)點可以同時運行多條管線的處理方式不同, GLEAM-X需要更多的內(nèi)存和計算資源,單個快照數(shù)據(jù)處理就需獨占一個計算節(jié)點. 例如,使用兩個計算節(jié)點并行處理兩個GLEAM-X快照數(shù)據(jù)包平均總用時7.2 h, 而使用單個計算節(jié)點處理相同的兩個快照數(shù)據(jù)包平均總用時9.5 h, 處理時間同比增加31%. 其主要原因在于, 在深度成像中WSClean采用的大視場成像算法是w方向疊片(wstacking), 其中w是基線(u、v、w)坐標(biāo)系的w軸,從地心指向目標(biāo)源相位中心方向. 該算法首先將三維可見度數(shù)據(jù)根據(jù)w值, 劃分為不同w層的二維可見度數(shù)據(jù), 然后分別對不同w層的二維可見度數(shù)據(jù)進行柵格化和FFT (Fast Fourier Transformation)成像, 最后不同w層得到的圖像乘以w因子并進行疊加得到最終的圖像結(jié)果[21]. 消耗的內(nèi)存和計算資源與w的大小和圖像的像素大小有關(guān). 由于需要產(chǎn)生的快照圖像的像素大小增大了, 所以在深度成像時, 消耗的內(nèi)存和計算資源也大大增加, 對于具有大規(guī)模計算節(jié)點資源的SKA區(qū)域中心(SKA Regional Centre, SRC)來說, 能夠大大縮短數(shù)據(jù)處理時間, 更適合于將來大規(guī)模連續(xù)譜巡天數(shù)據(jù)的處理.w-stacking的時間復(fù)雜度(Time Complexity,TC)[21]由下式給出:

其中,O表示算法的最壞時間復(fù)雜度, 即算法在最壞情況下所需的時間復(fù)雜度,Npix為圖像像素大小,Nvis為可見度數(shù)據(jù)長度,wmax為最大w值,αFOV為成像視場(Field Of View, FOV).

3.2 成像管線在CSRC-P上的任務(wù)排隊并行優(yōu)化

GLEAM-X成像管線所有處理步驟的執(zhí)行命令和代碼均采用Bash腳本進行封裝[31], 為了提高數(shù)據(jù)處理效率, 保證單個計算節(jié)點處理單條管線,我們設(shè)計了批量數(shù)據(jù)處理方法, 即通過任務(wù)排隊系統(tǒng)同時并行處理多個快照觀測數(shù)據(jù). 圖2表示基于Bash腳本任務(wù)排隊并行優(yōu)化的基本原理, 具體如下:

圖2 基于Bash腳本任務(wù)排隊并行優(yōu)化原理圖Fig.2 Principle diagram of task queuing and parallel optimization based on Bash script

(1)通過充分利用原型機作業(yè)調(diào)度系統(tǒng)中的任務(wù)依賴和計算節(jié)點分配功能進行并行處理, 我們編寫了一個總管線任務(wù)腳本, 其中涵蓋了管線所有處理步驟的子腳本, 并將每個步驟所需的運行參數(shù)做了頂層設(shè)置, 可以根據(jù)實際運行環(huán)境在總?cè)蝿?wù)腳本頂部進行統(tǒng)一設(shè)置和修改;

(2)用戶在登陸節(jié)點(Login Nodes)提交總?cè)蝿?wù)腳本, 通過計算節(jié)點分配功能將整條管線步驟隊列(Array)的每個子步驟分配到同一個計算節(jié)點(Operation Node)上運行, 利用前一個步驟提交后返回的任務(wù)編號(jobid)和任務(wù)依賴來實現(xiàn)任務(wù)排隊,待上一個步驟完成后自動執(zhí)行下一個步驟任務(wù),實現(xiàn)單條管線的處理運行;

(3)并行運行多條管線時, 在單條管線的最外層, 將單條管線的執(zhí)行放入到循環(huán)結(jié)構(gòu)中, 通過定義任務(wù)隊列(Task Queue)的循環(huán)次數(shù)(即并行運行的管線條數(shù))在單個循環(huán)內(nèi)確定單條管線的標(biāo)識ID和分配的計算節(jié)點編號. 將每個步驟的腳本文件提交到對應(yīng)管線的計算節(jié)點上進行任務(wù)排隊, 通過多次循環(huán)地提交任務(wù)來將多條管線分配到多個計算節(jié)點(即一個計算節(jié)點執(zhí)行一條管線處理), 實現(xiàn)基于任務(wù)排隊的管線Bash腳本的多節(jié)點并行處理.

3.3 并行成像管線的GLEAM-X數(shù)據(jù)驗證

為了驗證部署的環(huán)境以及修改后的管線的正確性, 我們選取一個GLEAM-X快照原始觀測數(shù)據(jù)進行測試. 快照數(shù)據(jù)觀測ID是1212314512, 觀測起始時間為協(xié)調(diào)世界時(Universal Time Coordinated,UTC)2018-06-06 10:01:34,觀測相位中心為(RA, Dec) = (176.87?,-25.78?). 管線處理該快照數(shù)據(jù)用時6.7 h, 最終生成圖像數(shù)據(jù)包含多頻率綜合(Multi Frequency Synthesis, MFS)和4個子頻段的總強度即射電偏振斯托克斯I分量(Stokes I)圖像結(jié)果, 頻率范圍為170–200 MHz, 圖像RMS噪聲4.2 mJy/beam與GLEAM-X文獻[10]給出的結(jié)果相符.

為了進行對比分析, 選取MFS的總強度圖像進行射電源搜尋并建立星表, 使用Aegean軟件搜尋出的射電源共有11409個, 使用星表和表格操作工具(Tool for OPerations on Catalogues And Tables,TOPCAT)[32]進行交叉匹配, 設(shè)置允許的最大偏差為45 arcsec (GLEAM-X角分辨率). 與已發(fā)表的GLEAM星表匹配的源個數(shù)為10234,匹配的源個數(shù)占源總數(shù)的89.7%, 剩余匹配的主要原因是GLEAMX的分辨率和靈敏度較高, 相較于GLEAM能夠探測到更多的射電源, 因此新多出的射電源與原有的GLEAM星表存在不匹配現(xiàn)象. 與廣域紅外巡天探測器(All the Wide-field Infrared Survey Explore,ALLWISE)星表匹配的源個數(shù)為11399, 匹配的源個數(shù)占源總數(shù)的99.9%, 表明獲得的射電星表幾乎都能夠找到紅外波段的對應(yīng)體. 通過統(tǒng)計指標(biāo)?RA、?DEC和Peak_flux的比值得到如下統(tǒng)計圖3和表2. 圖3為GLEAM-X快照圖像星表分別與ALLWISE星表和GLEAM星表交叉匹配的統(tǒng)計分布圖, 并繪制了分布圖的擬合曲線, 表2為圖3中各個分布函數(shù)的高斯擬合結(jié)果, 分別統(tǒng)計了各個分布函數(shù)高斯擬合的平均值、幅度值、標(biāo)準(zhǔn)差. 通過與兩個星表進行匹配, ?RA、?DEC的均值均在0左右, Peak_flux比值的均值在1左右, 標(biāo)準(zhǔn)差在0左右,標(biāo)準(zhǔn)差能反映一個數(shù)據(jù)集的離散程度, 標(biāo)準(zhǔn)差越小則數(shù)據(jù)離散越小, 由統(tǒng)計結(jié)果可以得出經(jīng)由我們改進過后的GLEAM-X成像管線在CSRC-P上的數(shù)據(jù)處理結(jié)果是可靠的.

表2 圖3中各個分布函數(shù)的高斯擬合結(jié)果Table 2 Gaussian fitting results for each distribution in Fig. 3

圖3 圖(a)和(b)為GLEAM-X快照圖像星表與ALLWISE星表交叉匹配統(tǒng)計結(jié)果. 圖(a): ?RA分布圖; 圖(b): ?DEC分布圖.圖(c)–(e)為GLEAM-X快照圖像星表與GLEAM星表交叉匹配統(tǒng)計結(jié)果. 圖(c): Peak flux比值分布圖, SGLEAM-X為GLEAM-X星表的Peak_flux值, SGLEAM為GLEAM星表的Peakflux值; 圖(d): ?RA分布圖; 圖(e): ?DEC分布圖. 圖中紅色虛線為分布圖的擬合曲線.Fig.3 Panels (a) and (b) display the statistical results of cross-matching between the GLEAM-X snapshot image catalog and the ALLWISE catalog, respectively. Panel (a): distribution of ?RA, ?RA is RA difference of two catalogs; Panel (b): distribution of ?Dec, ?DEC is DEC difference of two catalogs. Panels (c) to (e) show the statistical results of cross-matching between the GLEAM-X snapshot image catalog and the GLEAM catalog. Panel (c): Peak_flux ratio distribution, SGLEAM-X is Peakflux of the GLEAM-X catalog, SGLEAM is Peak_flux of the GLEAM catalog; Panel (d): distribution of ?RA; Panel (e): distribution of?Dec. Red dashed lines are the fitting curve of the difference distributions.

4 基于MPI的管線腳本并行擴展

為了更全面地開展性能測試對比, 我們對原型機上部署的基于Bash腳本的管線進行了MPI擴展修改, 以此來與其他的擴展方式進行性能比較.

MPI是一個跨語言的通訊協(xié)議, 屬于消息傳遞式并行程序設(shè)計, 在今天仍為高性能計算的主要模型[33]. 問題的分解策略、進程間的數(shù)據(jù)交換策略都需要由用戶來手動確定, 在挖掘潛在并行性方面更主動, 但并不利于流程的自動化處理.

為了實現(xiàn)MPI并行擴展, 我們使用python編程獲取通信域MPI-COMM-_WORLD中的進程號, 通過python內(nèi)置函數(shù)os.system對原本管線步驟的每一個Bash腳本生成子進程執(zhí)行, 并以MPI函數(shù)的形式來進行調(diào)用. 在原本所需的腳本參數(shù)的基礎(chǔ)上新增一個進程ID號, 用以識別劃分多條管線并行運行且獨立計算每條管線的運行時間. 之后再額外提交一個設(shè)置和運行MPI的任務(wù)腳本來執(zhí)行MPI擴展程序, 通過修改預(yù)分配的節(jié)點個數(shù)來設(shè)定并行運行的管線條數(shù), 最終能夠獲得與其他并行方式相同的成像結(jié)果.

5 基于DALiuGE執(zhí)行框架的成像管線自動化并行實現(xiàn)

本節(jié)主要介紹DALiuGE執(zhí)行框架的處理機制以及將成像管線移植到執(zhí)行框架中的兩個主要實現(xiàn)部分: 管線步驟的DALiuGE執(zhí)行框架組件開發(fā);管線的DALiuGE邏輯圖組合和物理圖部署運行.

5.1 DALiuGE處理機制

數(shù)據(jù)激活流(Liu)圖形引擎(DALiuGE)是一個專門用于以圖形方式處理超大規(guī)模射電天文數(shù)據(jù)集的工作流圖形執(zhí)行框架[11]. DALiuGE提供分布式數(shù)據(jù)管理平臺和可擴展的管線執(zhí)行環(huán)境, 以支持射電天文數(shù)據(jù)的自動化、軟實時、數(shù)據(jù)密集型處理.

與現(xiàn)有的處理框架相比, DALiuGE的主要優(yōu)勢在于:

(1)自動化資源調(diào)度管理: DALiuGE將管線的邏輯圖與其運行時的物理圖實現(xiàn)分離, 管線的運行能夠以負載平衡、數(shù)據(jù)移動最小化成本的方式映射到當(dāng)前可用的計算資源上, 能夠均衡整體工作負荷(包括計算時間和內(nèi)存使用)以實現(xiàn)最佳的資源調(diào)度分配;

(2)數(shù)據(jù)驅(qū)動: DALiuGE的執(zhí)行是由數(shù)據(jù)激活的, 每個單獨的數(shù)據(jù)項都會自動觸發(fā)對其自身的處理流程. DALiuGE將數(shù)據(jù)建模為圖的節(jié)點(Drop),將它們視作為可管理的實體, 允許數(shù)據(jù)和應(yīng)用程序觸發(fā)和接收事件. 這種去中心化也使得執(zhí)行框架具有很強的可擴展性和靈活性, 由于其完全去中心化的執(zhí)行模式, DALiuGE可以并發(fā)管理和執(zhí)行數(shù)千萬個任務(wù);

(3)生命周期管理: DALiuGE還在執(zhí)行引擎中集成了一個數(shù)據(jù)生命周期管理組件, 能夠跟蹤Drop的執(zhí)行并在必要時自動遷移或刪除[11].

DALiuGE的開發(fā)很大程度上是基于射電天文的處理需求, 并且DALiuGE采用了通用的、數(shù)據(jù)驅(qū)動的框架架構(gòu), 適用于許多其他數(shù)據(jù)密集型應(yīng)用程序, 因此我們選擇以DALiuGE執(zhí)行框架來實現(xiàn)GLEAM-X成像管線分布式并行優(yōu)化.

5.2 管線步驟的DALiuGE執(zhí)行框架組件開發(fā)

由于GLEAM-X管線所有處理步驟的執(zhí)行命令和代碼均采用Bash腳本進行封裝, 而DALiuGE的Drop組件主要是使用python語言編寫. 雖然DALiuGE自帶有簡單的Bash腳本組件可以使用, 但直接使用Bash腳本組件執(zhí)行效率不高. 從本質(zhì)上來說, 這種移植方式并不能充分發(fā)揮DALiuGE的性能, 因此我們選擇將GLEAM-X管線的整體代碼移植到DALiuGE的python組件中, 使其成為真正的DALiuGE組件程序. 無論使用哪種方法, 我們都將確保最終處理結(jié)果與原GLEAM-X管線一致.

DALiuGE的核心是數(shù)據(jù)驅(qū)動. Drop是一個無狀態(tài)程序單元, 當(dāng)Drop接收到數(shù)據(jù)時開始運行處理, 并在處理完成時輸出數(shù)據(jù). 我們在對GLEAM-X管線代碼進行詳細分析的基礎(chǔ)上, 將每一個管線步驟重新編寫為DALiuGE組件, 構(gòu)建了一系列Drop組件. 這些Drop組件繼承自DALiuGE的兩個標(biāo)準(zhǔn)Drop, 即PythonApp和FileDrop. PythonApp用于執(zhí)行腳本程序, 需要自行編寫, FileDrop用于傳輸變量, 在連接管線流程圖時根據(jù)輸入輸出的端口自動生成.

關(guān)于組件的編寫, DALiuGE提供一個組件項目模板5https://github.com/ICRAR/daliuge-component-template, 該模板涵蓋應(yīng)用程序組件和數(shù)據(jù)組件, 包括項目設(shè)置、測試、格式合規(guī)性、構(gòu)建、文檔、發(fā)布和持續(xù)集成等. 組件的編程需要修改apps.py文件來實現(xiàn), 通過組件規(guī)定的注釋方式可將App所需的參數(shù)在天文圖形語言環(huán)境編輯器(Editor for the Astronomical Graph Language Environment, EAGLE)可視化為可修改選項, 方便用戶隨時修改而不再需要涉及py文件的編程. 此外, 可以為組件添加自定義的輸入和輸出端口, 端口是獲取數(shù)據(jù)和信息進出組件的主要方式,端口始終連接到數(shù)據(jù)組件,并為應(yīng)用程序組件提供同質(zhì)I/O接口, 默認情況下只允許匹配端口之間的連接, 可以將任何想要的內(nèi)容寫入輸出端口, 但需要注意其他組件要能夠正確理解和解釋.

圖4為DALiuGE中成像管線的邏輯圖, 包含PythonApp和FileDrop共20個Drop, 其中執(zhí)行主要功能的PythonApp有10個, 分別是1個為了滿足DALiuGE中Scatter組件的并行需要而編寫的并行配置App Drop (ProduceConfigApp)、根據(jù)管線主要步驟編寫的9個App Drop和連接管線流程圖時根據(jù)輸入輸出端口自動生成用于傳輸任務(wù)編號(jobid)的10個FileDrop. 具體說明如下：

圖4 成像管線的邏輯圖Fig.4 Logic graph for the imaging pipeline

ProduceConfigApp:并行配置.DALiuGE自帶的Scatter組件會根據(jù)組件參數(shù)(Number of copies)的數(shù)目將包含在內(nèi)的管線流程拆分為多個并行處理實例, 因此需要根據(jù)Scatter的輸出數(shù)量, 按照總觀測ID下載CSV文件和包含全觀測ID的文本文件,通過ProduceConfigApp為每一條并行處理管線配置相應(yīng)的單條下載CSV文件和觀測ID文本文件, 并將CSV文件名和文本文件名傳輸?shù)较乱粋€Drop.

9個App與成像管線中的步驟按順序?qū)?yīng).downloadApp: 數(shù)據(jù)下載; cotterApp: 數(shù)據(jù)預(yù)處理;autoflagApp: 故障天線標(biāo)記; autocalApp: 生成校準(zhǔn)解; apply_calApp: 目標(biāo)場數(shù)據(jù)校準(zhǔn); uvflagApp:基線數(shù)據(jù)標(biāo)記; imageApp: 深度成像; postimageApp: 成像后處理; rescaleApp: 圖像重設(shè).

5.3 管線的DALiuGE邏輯圖組合和物理圖部署運行

以上的PythonApp組件編寫完成后為py文件,還需要使用DALiuGE中的轉(zhuǎn)換文件生成對應(yīng)組件的palette文件. 在EAGLE[11]中導(dǎo)入組件palette文件, 便可在EAGLE中生成可使用的組件模塊. 拖放組件模塊將單條管線所需的組件按照管線步驟依序連接并包含在Scatter組件范圍中, 通過改變Scatter中的‘Number of copies’參數(shù)來選擇將管線并行為想要的條數(shù), 最終組合成管線邏輯圖.

管線邏輯圖搭建好后, EAGLE提供Translation選項將邏輯圖轉(zhuǎn)化為物理圖, 如圖5所示. 物理圖由DALiuGE翻譯引擎從邏輯圖計算而來, 然后顯示在EAGLE界面中. 它表示將邏輯圖轉(zhuǎn)換為管線的物理執(zhí)行圖, 并將該圖映射到實際的計算機集群上.

圖5 成像管線的物理圖. 圖為將Scatter內(nèi)的Drops拷貝為4份, 然后并行處理4個GLEAM-X數(shù)據(jù)的物理圖.Fig.5 Physical graph for the imaging pipeline. The panel represents the physical graph of the imaging pipeline, where the Drops in Scatter have been replicated into 4 copies to enable parallel processing of 4 GLEAM-X data.

當(dāng)Translation過程產(chǎn)生的物理圖在DALiuGE執(zhí)行引擎上部署和實例化時, 就會成為跨多個資源單元的分布式執(zhí)行計劃中相互連接的Drop集合[11]. 由于該管線需要在CSRC-P原型機上以分布式多節(jié)點方式并行運行, 因此需要在原型機的DALiuGE中進行部署執(zhí)行. 這需要將之前組合好的管線邏輯圖保存為graph文件存儲入原型機系統(tǒng)內(nèi), 通過提交多節(jié)點任務(wù)腳本將graph文件以DALiuGE的集群方式部署執(zhí)行. DALiuGE會根據(jù)給定的計算節(jié)點數(shù)自動調(diào)度并行管線的運行, 在計算節(jié)點與并行條數(shù)相當(dāng)?shù)那闆r下, 均勻分配實現(xiàn)單個計算節(jié)點運行一條成像管線的最佳方式運行. 同時在提交目錄下產(chǎn)生節(jié)點管理的log文件、運行空間的環(huán)境文件、監(jiān)測運行狀態(tài)的輸出文件, 可以實時地了解和監(jiān)控執(zhí)行進度. 待最后一條管線執(zhí)行完畢后DALiuGE會自動結(jié)束任務(wù), 最終實現(xiàn)自動化的分布式并行成像管線處理.

6 性能測試與結(jié)果分析

6.1 并行方式總結(jié)

通過對上述并行方式的實現(xiàn), 我們總結(jié)了3種并行方法的優(yōu)化特性:

(1)在資源調(diào)度和任務(wù)分配方面,基于任務(wù)排隊的Bash腳本并行和MPI并行都需要用戶手動編程進行人工預(yù)分配, 而基于DALiuGE執(zhí)行框架的并行處理方式可以實現(xiàn)負載均衡的自動調(diào)度, 無需用戶進行額外的人工調(diào)度;

(2)在管線的并行執(zhí)行與控制方面, 基于任務(wù)排隊的Bash腳本并行方式執(zhí)行過程缺乏實時監(jiān)測和控制; MPI并行方式雖可以通過編程實現(xiàn)執(zhí)行過程的故障檢測, 但故障檢測的延遲性和后續(xù)恢復(fù)的成本仍非常高. 這兩種方式是由任務(wù)處理來驅(qū)動的簡單并行流程, 無法自動根據(jù)任何中間數(shù)據(jù)集和剛好可用的資源來動態(tài)地調(diào)整任務(wù)執(zhí)行, 往往需要更多的人工干預(yù), 這對于SKA規(guī)模(數(shù)千萬個并發(fā)任務(wù))的數(shù)據(jù)處理工作流程來說是不現(xiàn)實的. 而基于DALiuGE執(zhí)行框架的并行執(zhí)行是由數(shù)據(jù)驅(qū)動的,它將數(shù)據(jù)建模為邏輯圖的節(jié)點, 在內(nèi)存中實現(xiàn)為活動對象, 可以持續(xù)監(jiān)控并觸發(fā)后續(xù)任務(wù)的執(zhí)行, 同時其采用去中心化方式執(zhí)行任務(wù)節(jié)點和數(shù)據(jù)節(jié)點,在硬件條件滿足的情況下, 可以并發(fā)管理和執(zhí)行數(shù)萬個任務(wù), 極大地提升了管線的并行可擴展性和靈活性. 此外, 執(zhí)行框架中還集成了一個數(shù)據(jù)生命周期管理組件, 可以跟蹤節(jié)點活動并在必要時自動遷移或刪除;

(3)在管線的易用性和可遷移性方面,前兩種方式執(zhí)行管線都需要用戶具備專業(yè)編程知識, 通過腳本文件編程修改管線的運行設(shè)置來完成本地化部署, 部署步驟繁瑣且使用過程不夠簡單清晰. 而使用DALiuGE執(zhí)行框架的并行方式運行管線, 由于我們已將管線步驟集成入執(zhí)行框架中生成系統(tǒng)組件, 用戶只需在邏輯圖編輯器EAGLE中導(dǎo)入已制作好的成像管線邏輯圖, 即可通過修改步驟組件的可視化設(shè)置選項來實現(xiàn)無需編程的管線部署運行,用戶可以直觀地調(diào)整管線的各個步驟和并行設(shè)置,極大地增強了管線的易用性和可遷移性.

6.2 性能測試

實驗環(huán)境由CSRC-P原型機的計算集群上的23個Intel X86計算節(jié)點和額外的管理與登錄節(jié)點以及4.5 PB的分布式存儲系統(tǒng)組成. 其中, 計算節(jié)點包括8個Purley CPU節(jié)點和15個華為CPU節(jié)點, 節(jié)點詳細參數(shù)指標(biāo)如表3所示. 分布式存儲系統(tǒng)采用分層的存儲設(shè)計, 使用全閃存NVMe存儲以及SSD固態(tài)硬盤作為數(shù)據(jù)交換介質(zhì), 總存儲為4.5 PB(Huawei oceanstor). 為了比較性能, 我們使用相同的16個數(shù)據(jù)和運行參數(shù)在相同的環(huán)境中測試, 分別使用基于任務(wù)排隊系統(tǒng)的管線Bash腳本并行方式、基于MPI的并行擴展方式和基于DALiuGE執(zhí)行框架的自動化并行處理方式運行GLEAM-X成像管線. 具體運行參數(shù)如下: 并行使用計算節(jié)點數(shù)為16個, 每個節(jié)點使用內(nèi)存為500 GB, 每個節(jié)點使用核心數(shù)為24、進程數(shù)為48. 根據(jù)我們的實驗,這3種并行方式的輸入和輸出結(jié)果完全相同, 這證明了我們在DALiuGE上的移植管線與原管線的功能等效.

表3 計算節(jié)點主要參數(shù)指標(biāo)Table 3 Main parameters and indexes of compute_node

6.3 結(jié)果分析

根據(jù)實驗結(jié)果可以看出, DALiuGE表現(xiàn)出比MPI和Bash版本更好的性能. 圖6顯示了用3種方式處理1、2、4、8、16個快照數(shù)據(jù)(每個快照數(shù)據(jù)處理占據(jù)1個計算節(jié)點)時的實驗結(jié)果.

圖6 基于Bash、MPI和DALiuGE的管線的性能對比Fig.6 Performance comparison of pipelines based on Bash,MPI and DALiuGE

DALiuGE的總平均處理時間為7.1 h, 而MPI和Bash分別為7.48 h和7.67 h, 圖中誤差棒(標(biāo)準(zhǔn)差)為測試每種并行方式在相同并行數(shù)據(jù)數(shù)量下實驗10次得出的, 可以看出在相同數(shù)量數(shù)據(jù)的情況下, DALiuGE的處理時間始終比MPI、Bash方式要少0.5 h到1 h, 且DALiuGE誤差棒較短、多次處理時間的標(biāo)準(zhǔn)差較小, 因此DALiuGE的處理運行更為穩(wěn)定且耗時更少. 隨著并行處理數(shù)據(jù)數(shù)量的增加, 處理時間隨之線性增加, 但DALiuGE依然是3種并行方式中處理時間最少的, 并且在并行擴展時, DALiuGE能在部署執(zhí)行時為多條并行管線自動調(diào)度分配計算節(jié)點; 而無論是MPI還是Bash并行方式都需要用戶先查詢計算資源的空閑情況, 然后再通過額外編程來手動對多條并行管線進行計算節(jié)點的分配, 這將會產(chǎn)生更多的人工調(diào)度時間成本, 并且隨著并行擴展數(shù)量的增加, 人工調(diào)度的時間成本也將越來越大, 這對于需要自動化處理海量數(shù)據(jù)的成像管線來說是很大的缺陷. 因此, 可以得出結(jié)論, 在以上3種并行方式中DALiuGE并行處理的GLEAM-X成像管線綜合性能最好.

7 總結(jié)與展望

作為目前建設(shè)中最大的射電望遠鏡, SKA不僅有著孕育世界級科研成果的使命, 而且將會產(chǎn)生世界上最大規(guī)模的數(shù)據(jù), 因此我們需要充分認識到SKA數(shù)據(jù)處理的巨大挑戰(zhàn)[34]. 從技術(shù)趨勢來看, 使用執(zhí)行框架來處理SKA的超海量數(shù)據(jù), 很可能是必然的選擇, DALiuGE正是在這種背景下被提出和開發(fā)的[33].

本文基于SKA-1先導(dǎo)望遠鏡數(shù)據(jù)研究實現(xiàn)自動化分布式數(shù)據(jù)處理的成像管線, 通過分析SKA-1分布式數(shù)據(jù)工作流, 研究管線與分布式工作流的DALiuGE執(zhí)行框架集成方法、任務(wù)分配和負載均衡方法, 實現(xiàn)了具有較高可擴展性的分布式數(shù)據(jù)處理管線. 根據(jù)我們的實驗, 集成入DALiuGE執(zhí)行框架的成像管線在運行性能上對比傳統(tǒng)的并行處理方式具備一定優(yōu)勢, 主要在于快速的任務(wù)定制和面向數(shù)據(jù)驅(qū)動的處理模型, 這符合科學(xué)區(qū)域中心的應(yīng)用需求. 基于DALiuGE執(zhí)行框架進行優(yōu)化的成像管線相較于一般并行處理方式具有更好的性能優(yōu)勢、更靈活的適配性和可擴展性, 可支持未來SKA第一階段試運行期間的大規(guī)模連續(xù)譜成像實驗. 本文主要研究管線在并行框架上的整體優(yōu)化, 注重于管線在多個計算節(jié)點上的并行度和可拓展性的提升以及管線在部署運行時的便利性, 用以解決大規(guī)?？茖W(xué)數(shù)據(jù)自動化處理問題, 對于管線內(nèi)部步驟的執(zhí)行代碼不做更細粒度的并行優(yōu)化. 對管線的內(nèi)部細節(jié)優(yōu)化以提升管線在單節(jié)點上的運行效率并與當(dāng)前在并行框架上的整體性優(yōu)化相結(jié)合將作為我們接下來更進一步的研究課題. 此外, DALiuGE的移植工作相當(dāng)耗費人力, 實際上, 將成像管線移植到DALiuGE上是一項相當(dāng)艱苦的工作, 這項工作在技術(shù)上的實現(xiàn)并不困難,但卻要消耗大量的人力.在本次研究中, 由于沒有輔助工具, DALiuGE的代碼調(diào)試效率很低, 我們花費了大量的時間和精力在移植和新代碼設(shè)計中, 因此在未來如何合理安排開發(fā)計劃和開發(fā)人員來完成最終的DALiuGE的移植開發(fā)仍是一個需要研究的問題.

致謝論文使用了GLEAM-X管線開發(fā)團隊的代碼, 論文作者感謝開發(fā)團隊所有成員包括Natasha Hurley-Walker, Paul Hancock, Gemma Anderson,John Morgan,Stefan Duchesne和Tim Galvin.(github鏈接: https://github.com/tjgalvin/GLEA M-X-pipeline)