現在做科學計算相關的工具有很多。除了大多數時候用在超算上的module環境管理之外，也有很多有趣的軟件。而且並不是所有人所有時候都可以使用超算，超算也並不是科學計算的唯一硬件解決方案。我寫這個文章之前，嘗試管理我們組的服務器環境有一年的時間了，其中run過4，5個不同的模式，也算是在搭建環境上有點心得，正好今天總結分享下。
一開始我在搭建環境的時候，就是簡單的有pre-build包就直接安裝，沒有就源代碼編譯，走的耿直路線，但是很快就發現，隨着服務器庫環境的逐漸復雜，這樣的作法會使得整個環境變量混論不堪，而且每次還要去找對應的庫編譯安裝的位置，也是非常的耗時耗力。
后來我找到了4中比較好用且相對成熟的服務器環境管理工具(這里不提module，畢竟我主要使用的是組里的一個intel6154工作站，不是集群)。
conda
首先是conda,這里放在第一個介紹是因為我的包管理器的啟蒙就是它。使用非常方便簡潔，在日常的python使用中基本上涵蓋了所有常用庫，而且還有intelpython的神秘加成。推薦使用的時候對於不同的項目都新建一個env，不僅僅可以使開發的環境相對獨立，而且在未來的給他人介紹自己寫的代碼的時候，也可以方便的分享依賴庫(conda list -e > requirements.yml )。對於主要使用python開發的項目，十分推薦。
spack
而后是spack,這是一個可支持不同平台的包管理系統。開發的主要目的就是為了更方便的安裝科學計算所需要的庫，並且支持不同編譯器/編譯器版本之間的切換，可以說是十分方便。spack的使用邏輯和conda很像，這也是我把spack放在第二個講的原因。spack安裝非常方便，只要求host上有python環境，而后直接按照spack doc上的說明就可以了。spack install可以安裝庫，而且使用一定的語法指定庫的特性，如spack install hdf5%gcc7 就表示使用spack安裝gcc編譯的hdf5庫，在不添加pre-build mirror的條件下，整個安裝過程可以理解為先下載對應的庫和依賴的源碼包然后按照指定的編譯方式進行編譯安裝，這里只是簡單的舉了一個例子，實際使用的時候會有更多靈活的性質。安裝好的spack庫會存放在spack_root下的/opt目錄中，與linux日常使用的/opt目錄類似，install的庫使用hash散列，方便查找以及彼此區分。在使用的時候我們可以直接使用庫名——Tab查看選擇，或者直接使用庫的hash值進行類似module load的操作(這里是spack load)。所以雖然spack也有類似於conda env create的功能，但是一般情況下spack load就可以滿足大部分的需要了，無需特殊使用。但是我也要潑潑冷水，spack雖然功能好用，但是在實際使用的時候，庫安裝的時間還是很感人的，畢竟是和源碼安裝類似的過程，build時間占了很長的部分，所以強烈建議使用pre-build mirror。但是有的時候mirror中沒有對應的庫，那就只能慢慢install了。另外，spakc的安裝對於網絡的穩定要求比較高，而且在結界之內使用體驗較差，最好搭配相應的工具使用。
docker/singularity
下一個就是docker/singularity。前者可能大佬們都聽說過了，docker是進程級的獨立環境，早期是由linux容器實現的，所以在linux機器中可以使用GPU。但是win和mac的機器中，docker 容器和驅動之前隔了一層虛擬機，因此無法直接使用GPU等加速設備。不要問為啥mac也是要靠一層虛擬機，我只能說不是所有滿足Unix標准的都是好os(玩笑)。docker是一般情況下，最好的環境配置方案，只要可以在docker hub上找到對應的docker image，直接pull下來，然后啟動容器就可以直接測試環境了。由於是對於含GPU科學計算應用，只需要host的驅動較高，可以向下兼容一定的cuda版本，那么使用docker管理不同的cuda環境是最經濟的方式。之前我不了解docker的應用，在host上裝了多個版本的cuda，直接導致host驅動gg，這都是血的教訓！但是docker也有不太ok的地方，首先就是上手比較麻煩，在一開始的操作中容易image和container傻傻分不清，引起一些錯誤。另外就是docker bind folder的時候會有權限的問題，這個問題對於一般的使用可以接受，但是使用久了還是蠻麻煩的，所以我這里推薦使用singularity，它可以看作是一個為超算環境打造的docker，對mpi/openmp等並行庫的支持比較好，而且支持在singularity環境中使用環境$user，減少了很多文件權限的問題，使用之后感覺在科學計算這個場景上是更優的選擇。而且singularity的很多操作是面向文件的，我們很多時候只需要在它的images market上直接下載sif文件(當然也可以使用singularity pull，但是網速你懂的)然后直接singularity shell *.sif就可以進入環境了，配合--writable option可以修改容器環境，也可以在完成對容器環境的修改之后重新build一個新sif file用於環境分發。不可謂不方便。而且singularity和spack類似，不需要管理員權限，就可以自行編譯安裝，以及運行環境，可以讓超算用戶也獲得較為靈活的環境控制。(docker是不能的，因為它需要root start一個守護進程！)
在未來的科學計算應用中，我的傾向是使用后面的容器技術做環境的分發。畢竟對於很多科學模式/程序，庫依賴關系錯綜復雜，很多研究人員的青春和頭發都獻給了無聊的環境搭建工作，有了容器這個利器，只需要在發布相應版本的計算代碼的時候同時發布對應的images即可，對於非異構的項目甚至可以做到多平台分發，大大的增加的科研flow的效率。自己立下個flag，'origin -flag ->' !