6 月初，NCAR 先後舉辦了一年一度的 Joint MPAS/WRF Users Workshop 和 CESM Workshop。這些工作坊的主角大多都是研究人員，身為技術人員的我能夠看到自己的名字和貢獻過的程式出現在其他人的演講之中，甚感欣慰。不過，最近一次員工大會瀰漫著一股憂慮不安的氣氛，有些員工現在已經在放無薪假、甚至很不幸的被裁員。這樣看來，想一想我在 NCAR 剩下的時日可能也不多了，好像應該記錄、回顧一下自己做了什麼事情。
2023 年 11 月 6 日，我在 NCAR 報到成為軟體工程師，首要任務是將 MPAS 動力核心移植到 CAM-SIMA 這個大氣模式裡。「動力核心 (dynamical core)」指的是大氣模式中負責計算控制方程 (governing equation) 的部分，可以說是整個模式的計算中樞。簡單來說，透過求解控制方程，你就可以知道未來的風會怎麼吹，還有空氣的氣壓、密度、溫度、水氣會如何變化。至少，這是傳統的物理基礎 (physics-based) 模式背後的原理，新興的機器學習基礎 (ML-based) 模式則是另一種玩法。而所謂的「模式 (model)」其實就是電腦程式，它們的功能很單純－－根據物理定律模擬地球。由於系統需求龐大，所以通常在超級電腦上才會發現它們的身影。
NCAR 主導開發的 CESM 是地球科學領域廣泛使用、開放源碼 (open source) 的一個地球系統模式，由數個專門領域的獨立模式互相耦合而成。這些模式分別模擬地球的不同部分，例如大氣、陸地、冰層、海洋、海冰等，透過定時將各自的模擬結果進行資料交換，使得模式之間可以相互影響 (即稱「耦合 (couple)」)，共同模擬出地球從過去到未來的整體狀態。為什麼需要耦合呢？舉個例子，想像一下現在大氣模式模擬出某個地方正在下雨，這些雨水降落到地面、離開了大氣。此時，大氣模式將時間、地點、多少雨量等資訊傳遞給陸地模式，如此一來陸地模式就可以接手模擬這些雨水之後的去向。也就是說，當有質量 (模式內可以考慮的各種水物、化學物種等)、能量 (輻射、可感熱、潛熱等) 跨越單一模式邊界的情形，或者需要更新邊界條件的時候，必須藉由耦合其他模式才能完整考慮這些現象，所以才會叫做地球「系統」模式。
CESM 目前的大氣模式稱為 CAM，而我參與開發的 CAM-SIMA 則是 NCAR 規劃的下一代大氣模式，預計在 (遙遠的？) 將來會取代 CAM－－前提是這個 SIMA 計畫沒有因為預算被砍光而中止的話。如果用程式碼行數來估計它們的規模，CESM 的程式碼大約有 490 萬行，CAM 大約佔其中的 100 萬行。但是我們知道，程式碼行數和品質其實沒有什麼相關，NCAR 的軟體工程師也常常自嘲每天都在和祖傳的義大利麵程式奮鬥。CAM-SIMA 的誕生，目標是整合 NCAR 分散在各個實驗室的模式技術與軟體生態，打造一個集合天氣、氣候、化學等應用於一身的通用型大氣模式，並且在移植既有功能的過程中同步檢討過去的程式架構與設計，一步一腳印的重構 (refactor)、重寫 (rewrite)，或者乾脆捨棄 (deprecate) 已經不堪使用的部分。不過，CAM 的歷史可以回溯到 1996 年，它的前身甚至可以繼續考古到 1983 年，想要重構、重寫這麼一個經過 40 年以上的累積、上百萬行的科學結晶，同時也是軟體工程的惡夢，談何容易。
背景終於解釋完了，回到我的首要任務：將 MPAS 動力核心移植到 CAM-SIMA 裡。這個部分其實是 CAM 的既有功能之一，但是因為當初的開發者寫得實在太悲劇了，導致後續維護變得異常困難 (出於好奇，我用 git blame 看過到底是誰在敗壞我們的程式品質，Well, well... 位階都比我高而且有些還在 NCAR，趕緊惦惦比較好)。於是，我臨危受命開始把 MPAS 動力核心整個砍掉重練－－此時我才到職不滿 2 個月。現在想起來覺得，這些主管還真敢放手艱鉅任務給菜鳥呢。
快轉到現在，CAM-SIMA 的 MPAS 動力核心已經達到當初設定的軟體開發里程碑，除了接近與 CAM 功能對等 (feature parity)，還具備以下特點：
- 符合 Fortran 2018 (ISO/IEC 1539-1:2018) 語言標準。
- 新增支援訊息傳遞介面 (Message Passing Interface, MPI) 標準裡規範的 Fortran
mpi_f08介面，舊的 Fortranmpi介面支援仍然保留。 - 新增支援單精度浮點數 (single-precision floating-point) 的運算精確度，原本的雙精度浮點數 (double-precision floating-point) 維持為預設。
- 程式碼、邏輯與宿主模式 (host model) 脫鉤，MPAS 動力核心改為自己獨立編譯，再以靜態連結函式庫 (static library) 的方式連結至宿主模式。這裡的宿主模式指的是 CAM-SIMA，但是以設計上而言，任何其他的大氣模式都可以透過這個函式庫來實作支援 MPAS 動力核心。
- 採取物件導向 (object-oriented) 設計，MPAS 動力核心以不透明物件 (opaque object) 的形式顯露給宿主模式，保護其內部的資料結構、狀態不被宿主模式竄改。宿主模式必須透過呼叫物件上的成員函式 (在 Fortran 裡以 type-bound procedure 稱之) 與 MPAS 動力核心互動。
- 統一宿主模式與 MPAS 動力核心之間的應用程式介面 (Application Programming Interface, API)，不再允許宿主模式呼叫 MPAS 的內部函式。
- 完整、詳盡的程式碼註解，如果跟方程式有關則包含推導方法或文獻出處，然後 API 參考文件可以直接從程式碼自動產生。
- 單元測試。
乍看之下，好像都是面向開發者的改動，有沒有讓一般使用者有感的改動呢？當然有。在以下的效能測試結果中，CAM 和 CAM-SIMA 跑完全相同的模擬，比較個別 MPI 處理程序的記憶體用量 (縱軸) 隨執行時間 (橫軸) 的變化。黑線為 CAM 跑雙精度的 MPAS 動力核心；紅線為 CAM-SIMA 跑雙精度的 MPAS 動力核心；綠線為 CAM-SIMA 跑單精度的 MPAS 動力核心。線的終點代表模式結束模擬所需要的時間，因此線的長度越短越好，代表模式跑得比較快、需要比較短的時間就可以完成相同的模擬。
圖一顯示，CAM 和 CAM-SIMA 都存在一些負載平衡的毛病，MPI master rank 特別吃記憶體，比其他 MPI rank 高得多，然後在結束模擬的時候，MPI master rank 的記憶體用量還會暴衝，因為它負責寫模式輸出。不過，我覺得這個是 ESMF 框架的鍋，應該不是模式端可以解決的 (馬上印證軟體工程師最喜歡甩鍋...)。除此之外，主要差別在圖二就顯而易見。
圖二放大圖一的縱軸。同樣使用雙精度的 MPAS 動力核心，CAM-SIMA (紅線) 執行速度比 CAM (黑線) 快 24% (1.98 → 1.60 小時)，記憶體用量少 28% (16.1 → 11.6 GB)。然後，由於 CAM 沒有單精度的 MPAS 動力核心，所以只好 CAM-SIMA 自己跟自己比，可以看到單精度的 MPAS 動力核心 (綠線) 比雙精度 (紅線) 再更快 72% (1.60 → 0.93 小時)，記憶體用量再更少 28% (11.6 → 8.3 GB)。
這樣的效能提升等於讓使用者免費升級了兩個世代以上的 CPU 吧！記憶體還可以少插幾條。CAM-SIMA 的路線圖上亦有加入 GPU 支援的規劃，這個在 CAM 是不可能的。不過，仍然要回到一樣的問題，SIMA 計畫如果中止，夭折的 CAM-SIMA 就會無法上線接班 CAM，目前的結果大概就打水漂了。
最後，回顧自己的職涯軌跡，一直都圍繞在高效能運算 (high-performance computing) 這個主題上，有的時候偏向硬體和系統 (系統工程師)、有的時候偏向軟體 (軟體工程師)。雖然以工作內容和其他諸多因素而言，我依然更喜歡前者，尤其是過去在國網中心的時光。不過，NCAR 的工作經驗對我來說是一個全新卻收穫滿滿的探索－－因為我現在知道，自己的程式能力也足夠走出一條路。如果 NCAR 接下來要繼續動刀，那麼我的下一站會在何方？🌠
縮寫對照表：
- CAM: Community Atmosphere Model
- CESM: Community Earth System Model
- ESMF: Earth System Modeling Framework
- MPAS: Model for Prediction Across Scales
- NCAR: National Center for Atmospheric Research
- SIMA: System for Integrated Modeling of the Atmosphere
- WRF: Weather Research and Forecasting
