---
# System prepended metadata

title: enviroment module Note
tags: [lmod]

---

# enviroment module Note


::: spoiler \[Prompt\] 我想問使用env module適用於任何套件嗎，還是只有指定的，以及這是中心化的嗎，我如果自己製作了套件怎麼使用適配上env module來管理版本。

Environment Modules（環境模組）系統雖然強大，但它的適用範圍和管理方式有些限制。讓我們深入討論你提出的幾個問題：
1. 環境模組適用於任何套件嗎？

Environment Modules 理論上可以管理任何軟體套件的環境，只要這些軟體依賴於環境變數（如 PATH、LD_LIBRARY_PATH 等）來進行安裝和運行。但實際上，它主要用於那些在高效能計算（HPC）環境中常見的軟體包，比如編譯器、數學庫、MPI、CUDA 等。這是因為這類軟體包通常會有多個版本共存的需求，而這個工具正是為了解決這類問題設計的。

一些常見的例子包括：

    不同版本的編譯器（如 GCC、Clang）
    數據科學工具（如 Python、R）
    高效能計算的庫和工具（如 OpenMPI、CUDA）

但如果是某些與環境變數無關或無需版本控制的簡單軟體，可能不會使用到 Environment Modules，例如一些單一用途的命令行工具。
2. 這是中心化的嗎？

Environment Modules 本身並不是中心化的工具。它在一個系統上運行時，所有的模組配置和管理通常會被安裝在一個中心位置，比如 /etc/modulefiles 或 /usr/share/modules/modulefiles，這取決於你的 Linux 發行版和系統配置。這個中心位置可以被系統管理員控制，確保所有用戶使用一致的軟體環境。

但你也可以在自己的家目錄中創建和管理自己的模組。這意味著你不必依賴系統管理員來安裝或配置模組，從而可以實現去中心化的管理。
例子：

你可以在自己的目錄下創建一個 modulefiles 文件夾，並將模組加載路徑指向那裡：

bash

mkdir -p ~/my_modules/modulefiles
module use ~/my_modules/modulefiles

這樣你就可以在自己的環境中加載、卸載和管理自定義模組，而不需要系統級別的權限。
3. 如何讓自己的套件適配 Environment Modules？

如果你自己製作了一個軟體或套件並且希望使用 Environment Modules 來管理它的多個版本，那麼你需要為它編寫一個模組文件，這個文件會描述如何設置軟體的環境變數（如 PATH、LD_LIBRARY_PATH 等）。
實現步驟：

    創建模組文件： 首先，你需要在 modulefiles 目錄中為你的套件創建一個模組文件。假設你的套件名叫 myapp 且有兩個版本 1.0 和 2.0，你可以創建相應的目錄結構：

    bash

mkdir -p ~/my_modules/modulefiles/myapp

然後在 myapp 目錄下為每個版本創建一個文件，例如：

bash

touch ~/my_modules/modulefiles/myapp/1.0
touch ~/my_modules/modulefiles/myapp/2.0

編寫模組文件： 模組文件是一個簡單的腳本，當加載該模組時，它會動態修改環境變數。下面是一個簡單的 myapp 1.0 版本的模組文件範例：

在 ~/my_modules/modulefiles/myapp/1.0 文件中寫入：

bash

#%Module1.0
proc ModulesHelp { } {
    puts stderr "This module loads MyApp 1.0"
}

module-whatis "MyApp version 1.0"

set     myappdir    /home/user/myapp/1.0
prepend-path    PATH            $myappdir/bin
prepend-path    LD_LIBRARY_PATH $myappdir/lib

這個模組文件將設置 PATH 和 LD_LIBRARY_PATH 來指向你的套件目錄，這樣當用戶加載 myapp/1.0 時，系統就會知道在哪裡找到執行文件和庫。

加載你的模組： 在編寫完模組文件後，用戶可以通過 module 命令來加載和切換你的套件版本。例如：

bash

module load myapp/1.0

切換版本： 如果你有多個版本的 myapp，用戶可以自由切換不同的版本：

bash

    module switch myapp/1.0 myapp/2.0

4. 模組文件的靈活性

模組文件可以非常靈活，不僅僅是用來設置路徑，你還可以用來配置各種環境變數，甚至是基於系統條件來動態設置環境。比如你可以根據不同的作業系統或硬體架構來設置不同的路徑。
總結

Environment Modules 適用於任何需要通過環境變數進行配置的軟體，但對於那些不依賴環境變數的軟體可能不適用。
    這個系統不是強制的中心化管理，你可以在自己的目錄中配置和使用自定義的模組。
    如果你自己開發了軟體，可以通過編寫模組文件來將它與 Environment Modules 集成，以管理多個版本的切換和使用。
:::

::: spoiler [Prompt] 我還想問這個env module是可以被其他linux發行版的包管理器安裝嗎？他們的env module跟ubuntu是一樣的嗎
是的，Environment Modules 可以被安裝在多個 Linux 發行版上，並且在不同發行版之間它的基本功能和用法是一致的。它不是 Ubuntu 專有的工具，而是一個通用的軟體，許多發行版都能使用。不同發行版可以通過各自的包管理器來安裝 Environment Modules，如：

    Ubuntu/Debian：可以使用 apt 安裝

    bash

sudo apt install environment-modules

CentOS/RHEL：可以使用 yum 或 dnf 安裝

bash

sudo yum install environment-modules

Fedora：使用 dnf

bash

sudo dnf install environment-modules

Arch Linux：使用 pacman

bash

sudo pacman -S environment-modules

openSUSE：使用 zypper

bash

    sudo zypper install environment-modules

不同發行版的 Environment Modules 一樣嗎？

基本上，Environment Modules 的核心功能和命令在所有發行版上是相同的。無論是在 Ubuntu、CentOS 還是其他 Linux 發行版，主要的命令如 module load、module unload、module list 等都會保持一致。

唯一可能的區別是安裝目錄和預設的模組文件路徑。比如在某些發行版上，模組文件可能預設安裝在 /usr/share/modules/modulefiles，而在其他發行版上可能會是 /etc/modulefiles。但是這些路徑都可以根據系統需求來配置，因此這並不會對最終使用產生太大影響。
Environment Modules 是否與發行版的包管理器整合？

Environment Modules 不依賴於某個具體的包管理器，它獨立於系統的包管理機制。這意味著你可以使用模組系統來管理和切換某些軟體的版本，而無需每次都依賴發行版的包管理器。

例如，你可以使用包管理器來安裝多個版本的 gcc，然後使用 Environment Modules 來輕鬆地切換不同版本的 gcc，而不必每次都修改環境變數。這與包管理器的作用是互補的，讓你可以在同一系統中同時運行不同版本的工具或軟體。
自製軟體和模組管理

無論你在哪個 Linux 發行版上，Environment Modules 都可以管理自製的軟體版本。你只需在自己的系統上編寫模組文件，並將它們放在適當的模組文件夾中，這一點在不同發行版之間也是一致的。
總結

Environment Modules 可以在多個 Linux 發行版上通過包管理器安裝。
    各個發行版的 Environment Modules 功能一致，只有安裝目錄和模組文件路徑可能略有不同。
    它不依賴於發行版的包管理系統，可以靈活管理多版本的軟體，並與包管理器互補工作。
:::

[enviroment modules offical 1 : home](https://modules.readthedocs.io/en/latest/)
[enviroment modules offical 2 : other home](https://modules.sourceforge.net/)


:::spoiler [Prompt] lmod 和 enviroment module的差別是什麼？
Lmod 和 Environment Modules (通常稱為 Tcl Modules) 是兩種常見的環境模組系統，主要用於管理 Linux 環境中的軟體模組，特別是在高效能運算（HPC）領域。雖然它們功能相似，但在設計和特性上有所不同。以下是它們的區別：
1. 來源與開發

    Environment Modules（Tcl Modules）：這是最早的模組系統，最初由 Richard L. Henderson 在 1990 年代開發，使用 Tcl（Tool Command Language）作為腳本語言。
    Lmod：這是後來由 Robert McLay 開發的模組系統，旨在改進和擴展原本的 Tcl Modules，使用 Lua 作為其腳本語言。

2. 語言和設計

    Environment Modules 使用 Tcl 語言來編寫模組文件，該語言在 Unix 系統上有較長的歷史。
    Lmod 使用 Lua 語言，相對簡單且執行速度更快。Lmod 通常被認為更靈活，並且擁有更高效的模組處理能力。

3. 模組衝突管理

    Environment Modules 需要用戶手動處理模組之間的衝突，並沒有內建的自動化衝突解決機制。
    Lmod 則提供更智能的依賴和衝突處理系統，可以自動偵測並解決模組間的衝突。這使得 Lmod 更容易在多版本環境下管理不同軟體套件。

4. 層級與繼承

    Environment Modules 缺乏對層級結構的支援，這意味著你必須手動管理各種版本的軟體模組。
    Lmod 支援層級模組（hierarchical modules），允許用戶在不同層次載入模組。例如，載入一個指定版本的編譯器後，會自動載入與該編譯器相容的其他軟體。

5. 擴展性

    Environment Modules 的擴展性較有限，隨著系統模組數量的增加，會變得更難管理。
    Lmod 設計上更為現代，支援擴展與搜索功能，例如可以通過 module spider 命令查找特定版本的模組。

6. 向下相容性

    Lmod 具有向下相容性，這意味著它可以執行以 Tcl Modules 格式撰寫的模組文件，這使得從舊的系統過渡到 Lmod 更加容易。
    Environment Modules 則不支援 Lua 語言撰寫的模組文件。

7. 額外功能

    Lmod 提供更多進階功能，例如模組版本棧、反覆操作支援以及更多高效能計算場景下所需的管理工具。
    Environment Modules 提供的功能相對基礎。

小結：

Lmod 是一個更先進和靈活的模組系統，適合需要管理大量軟體和依賴關係的環境。Environment Modules 則是最早的解決方案，較適合於較簡單的系統需求。如果你需要進行多模組管理，並且關注衝突解決和模組層級結構，Lmod 是一個更好的選擇。

如需更多詳細資訊，請參考Lmod 官方文檔或Environment Modules 官方網站。
:::

:::spoiler [Prompt] lmod適配env module的語法並且支持更多功能？

是的，Lmod 適配了傳統的 Environment Modules（通常稱為 Tcl Modules）的語法，並且在此基礎上提供了更多的功能。這使得 Lmod 能夠同時支持舊系統中的 Tcl Modules 模組文件，並為用戶帶來額外的優勢與靈活性。以下是一些關鍵點來說明它如何兼容並擴展功能：
1. 語法相容性

    Lmod 對 Tcl Modules 的語法具有向下相容性。也就是說，用於 Tcl Modules 的模組文件（modulefile）可以直接在 Lmod 中運行，這讓從 Tcl Modules 過渡到 Lmod 變得非常簡單。
    這種相容性意味著 Lmod 可以無縫集成到那些已經使用 Tcl Modules 的系統中，而無需重新編寫現有的模組文件。

2. 更多功能

Lmod 不僅支持傳統語法，還提供了許多額外功能：

層級式模組管理（Hierarchical Module System）：Lmod 支持基於層級的模組結構，允許根據軟體的依賴關係和版本來自動選擇和載入模組。例如，當你載入某一版本的編譯器時，Lmod 可以自動選擇與該編譯器兼容的其他工具。
    模組版本搜索（Module Spider）：Lmod 提供了 module spider 命令，可以讓你查詢所有已安裝的模組及其版本，這在擁有大量軟體版本的環境中非常有用。
    衝突解決與依賴關係管理：Lmod 可以自動解決模組間的衝突，並且在載入模組時處理模組的依賴關係。這種智能處理功能讓軟體環境的管理變得更加簡單。
    支援 Lua 擴展：Lmod 使用 Lua 語言來撰寫模組文件，這使得它可以更高效且靈活地處理各種情境。此外，Lmod 還支持動態模組生成，可以根據不同環境生成自定義模組文件。

3. 性能優化

Lmod 針對大型環境進行了性能優化，能夠更快速地加載和卸載模組，特別是當系統中有成千上萬個模組時，Lmod 的執行效率會顯著優於 Tcl Modules。
4. 擴展性與社群支持

Lmod 社群不斷增加新功能和更新，並且被廣泛應用於各大學和高效能計算機中心。這使得 Lmod 能夠提供更好的擴展性和社群支持。
總結：

Lmod 具備傳統 Tcl Modules 語法的相容性，因此可以在不更改現有模組文件的情況下使用。然而，Lmod 提供了更多先進的功能和性能優勢，讓它成為更強大、更靈活的模組管理工具。對於那些想要在現代環境中管理複雜軟體依賴關係的用戶來說，Lmod 是一個更好的選擇。

如果你想更深入地了解 Lmod，這裡有 Lmod 的官方文檔，你可以從中找到更多資訊。
:::

lmod 可能比 enviroment module 提供更好的性能，這值得拋棄後者。



:::spoiler [Prompt] Tmod , TCL mode, enviroment modules都是相同的東西的不同名稱嘛
Tmod、Tcl Modules 和 Environment Modules 其實是指相同的東西，它們是不同名稱的用法。這個系統最初被稱為 Environment Modules，是用來動態管理 Unix/Linux 環境中的軟體包。它通常使用 Tcl 語言來撰寫模組文件，這就是為什麼它有時會被稱為 Tcl Modules 或者簡稱 Tmod。
名稱的解釋：

Environment Modules：這是最正式和標準的名稱，指的是這整個環境模組管理系統。它允許用戶方便地加載、卸載、切換和查詢軟體環境模組。
    Tcl Modules：這個名稱反映了模組文件使用 Tcl 語言編寫的事實。因此，有時人們會用這個名稱來指代 Environment Modules。
    Tmod：這是一個更簡短的名稱，有些用戶或文檔中會用這個縮寫來表示 Tcl Modules 或 Environment Modules。

小結：

Tmod、Tcl Modules 和 Environment Modules 其實都是指同一個系統，只是因為它的腳本語言和使用情境不同，才出現了這些名稱。
:::

翻:Texas Advanced Computing Center 德州高級計算中心 TACC

學習目標轉成 `lmod`，希望不要被背刺。

## lmod 連結
[Documentation](https://lmod.readthedocs.org)
[GitHub](https://github.com/TACC/Lmod)
[SourceForge](https://lmod.sf.net)
[TACC Homepage](https://www.tacc.utexas.edu/research-development/tacc-projects/lmod)
[Lmod Test Suite](https://github.com/rtmclay/Lmod_test_suite)
翻:Test Suite 測試程序
### sub
[lmod offical 4 : github tcl2lua.tcl 腳本](https://github.com/TACC/Lmod/blob/main/src/tcl2lua.tcl)
[lmod offical 2 : from Tmod to Lmod](https://lmod.readthedocs.io/en/latest/)
[lmod offical 3 : user guide](https://lmod.readthedocs.io/en/latest/010_user.html)


:::spoiler 目錄(google翻譯)
Lmod簡介

如果您是 Lmod 新手，請閱讀使用者指南，可能還有常見問題指南。希望了解如何擁有自己的個人模組的用戶應閱讀高級用戶指南。

 Lmod 使用者指南
 編寫模組檔案簡介
 常見問題解答
 個人模組檔案進階使用者指南
 Lmod 的新功能

安裝Lmod

任何希望在個人電腦或系統上安裝 Lmod 的人都應該閱讀安裝指南以及過渡到 Lmod 指南。其餘指南可依需求閱讀。

 安裝 Lua 和 Lmod
 如何過渡到 Lmod（或如何在不安裝 Lmod 的情況下測試 Lmod）
 Lua 模組檔函數
 TCL 模組檔案函數
 Lmod 環境變量
 模組名稱和模組命名約定
 Lmod 如何選擇要載入的模組文件
 為所有使用者提供一套標準的模組
 從 TCL/C 環境模組轉換為 Lmod

高級主題

 如何報告 Lmod 中的錯誤
 類別 PATH 變數的規則
 隱藏模組
 如何使用軟體模組層次結構
 為您的網站配置 Lmod
 網站和使用者對預設值、別名和隱藏模組的控制
 hide{}：隱藏模組的更強大方法
 禁止{}：一種將模組標記為可見但不可載入的方法
 TCL .modulerc 文件
 Lmod如何將TCL模組檔轉換為Lua
 依賴模組
 模組檔案範例從簡單到複雜
 電腦程式的簡潔輸出
 模組、MPI 和平行檔案系統之間的交互
 共享家庭檔案系統上的 Lmod
 用戶蜘蛛緩存
 系統蜘蛛緩存
 使用模組蜘蛛命令
 蜘蛛工具
 棄用模組
 模組屬性
 偵錯模組文件
 調試Lmod
 SitePackage.lua 和鉤子
 Lmod 本地化
 EasyBuild 和 Lmod 的集成
 提供自訂標籤供使用
 載入風暴：載入時間長或載入失敗
 追蹤Lmod
 黏性模組
 使用 SitePackage.lua 修改 Lmod 行為
 Shell 腳本和 Lmod
 追蹤模組使用情況
 使用 settarg 組合模組和建置系統
 提高 Lmod 的性能
 模組擴充
 反映系統層次結構的個人層次結構
 安全支援社群模組集合
 檢查站點模組檔案中的語法
:::
:::spoiler 目錄精選
Software Module Hierarchy
Providing A Standard Set Of Modules for all Users
Hidden and Forbidden Modules
Module Properties and Custom Labels
Configuring Lmod for your site
Dependent Modules
How Lmod Picks which Modulefiles to Load
Lmod Environment variables
:::

:::spoiler [Prompt] 請幫助我塞選過時的，舊系統遷移到新系統，沒必要的，額外安裝新的工具的文章。並挑選說明好用的必學的主要功能的文章，只需要輸出文章標題就好，不用額外說明。(省略一大堆文章標題)
User Guide for Lmod
An Introduction to Writing Modulefiles
Frequently Asked Questions
Lmod Environment variables
How Lmod Picks which Modulefiles to Load
Providing A Standard Set Of Modules for all Users
Rules for PATH-like variables
Hidden Modules
How to use a Software Module hierarchy
Configuring Lmod for your site
Module Properties
Debugging Modulefiles
Modulefile Examples from simple to complex
Terse output for computer programs
The Interaction between Modules, MPI and Parallel Filesystems
Sticky Modules
Shell scripts and Lmod
Tracking Module Usage
:::
### 中文文章
[指令速食口糧](https://man.twcc.ai/@TWCC-III-manual/ryDQk2yKO)
Note: 小記: 記得用研究研究 module -h
[速食口糧英文版(或reference，不確定全不全)(連過去巨慢)](https://confluence.ecmwf.int/display/UDOC/Lmod+modules+command+reference+list)
翻: European Center for Medium-Range Weather Forecasts 歐洲中期天氣預報中心 ecmwf

### sub(AI picked and I added)
[安裝lua, tcl 和 lmod](/cyk-sgBWSWqAl7aTXwzLwg)
有三個指令能用，應該都是類似的。
:::spoiler lmod - 會輸出環境變量
```
--------------------------------------------------------- /media/hlajungo/D/linux/modulefiles ----------------------------------------------------------
   gcc/9    gcc/10 (D)

--------------------------------------------------------- /opt/apps/lmod/lmod/modulefiles/Core ---------------------------------------------------------
   lmod    settarg

  Where:
   D:  Default Module

If the avail list is too long consider trying:

"module --default avail" or "ml -d av" to just list the default modules.
"module overview" or "ml ov" to display the number of modules for each name.

Use "module spider" to find all possible modules and extensions.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".


MODULEPATH=/media/hlajungo/D/linux/modulefiles:/opt/apps/modulefiles/Linux:/opt/apps/modulefiles/Core:/opt/apps/lmod/lmod/modulefiles/Core;
export MODULEPATH;
_ModuleTable001_=X01vZHVsZVRhYmxlXyA9IHsKTVR2ZXJzaW9uID0gMywKY19yZWJ1aWxkVGltZSA9IDcyMDAsCmNfc2hvcnRUaW1lID0gMC4wMDA0NTcwNDg0MTYxMzc3LApkZXB0aFQgPSB7fSwKZmFtaWx5ID0ge30sCm1UID0ge30sCm1wYXRoQSA9IHsKIi9tZWRpYS9obGFqdW5nby9EL2xpbnV4L21vZHVsZWZpbGVzIiwgIi9vcHQvYXBwcy9tb2R1bGVmaWxlcy9MaW51eCIsICIvb3B0L2FwcHMvbW9kdWxlZmlsZXMvQ29yZSIsICIvb3B0L2FwcHMvbG1vZC9sbW9kL21vZHVsZWZpbGVzL0NvcmUiLAp9LApzeXN0ZW1CYXNlTVBBVEggPSAiL21lZGlhL2hsYWp1bmdvL0QvbGludXgvbW9kdWxlZmlsZXM6L29wdC9hcHBzL21vZHVsZWZpbGVzL0xpbnV4Oi9vcHQvYXBwcy9tb2R1bGVmaWxlcy9D;
export _ModuleTable001_;
_ModuleTable002_=b3JlOi9vcHQvYXBwcy9sbW9kL2xtb2QvbW9kdWxlZmlsZXMvQ29yZSIsCn0K;
export _ModuleTable002_;
_ModuleTable_Sz_=2;
export _ModuleTable_Sz_;

```
:::


:::spoiler ml - 跟module一樣，但只要兩個字。
```
--------------------------------------------------------- /media/hlajungo/D/linux/modulefiles ----------------------------------------------------------
   gcc/9    gcc/10 (D)

--------------------------------------------------------- /opt/apps/lmod/lmod/modulefiles/Core ---------------------------------------------------------
   lmod    settarg

  Where:
   D:  Default Module

If the avail list is too long consider trying:

"module --default avail" or "ml -d av" to just list the default modules.
"module overview" or "ml ov" to display the number of modules for each name.

Use "module spider" to find all possible modules and extensions.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".


```
:::
文章原話:D
For those of you who can’t type the mdoule, moduel, err module command correctly, Lmod has a tool for you. With ml you won’t have to type the module command again. The two most common commands are module list and module load \<something> and ml does both

:::spoiler module - module。
```
--------------------------------------------------------- /media/hlajungo/D/linux/modulefiles ----------------------------------------------------------
   gcc/9    gcc/10 (D)

--------------------------------------------------------- /opt/apps/lmod/lmod/modulefiles/Core ---------------------------------------------------------
   lmod    settarg

  Where:
   D:  Default Module

If the avail list is too long consider trying:

"module --default avail" or "ml -d av" to just list the default modules.
"module overview" or "ml ov" to display the number of modules for each name.

Use "module spider" to find all possible modules and extensions.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".


```
:::

Note: `man module`有使用說明
:::spoiler man module 輸出

MODULE(1)                                                User Contributed Perl Documentation                                                MODULE(1)

module

SYNOPSIS
       module [options] sub-command [args ...]

DESCRIPTION
       This tool allow a user to control their environment by load and unloading modulefiles.  See https://lmod.readthedocs.org for more details.

OPTIONS
       -h -? -H --help
           This help message

       -s availStyle --style=availStyle
           Site controlled avail style: system (default: system)

       --regression_testing
           Lmod regression testing

       -b --brief
           brief listing with only user specified modules

       -D  Program tracing written to stderr

       --debug=dbglvl
           Program tracing written to stderr (where dbglvl is a number 1,2,3)

       --pin_versions
           When doing a restore use specified version, do not follow defaults

       -d --default
           List default modules only when used with avail

       -q --quiet
           Do not print out warnings

       --expert
           Expert mode

       -t --terse
           Write out in machine readable format for commands: list, avail, spider, savelist

       --initial_load
           loading Lmod for first time in a user shell

       --latest
           Load latest (ignore default)

       -I --ignore_cache
           Treat the cache file(s) as out-of-date

       --novice
           Turn off expert and quiet flag

       --raw
           Print modulefile in raw output when used with show

       -w twidth --width=twidth
           Use this as max term width

       -v --version
           Print version info and quit

       -r --regexp
           use regular expression match

       --gitversion
           Dump git version in a machine readable way and quit

       --dumpversion
           Dump version in a machine readable way and quit

       --dumpname
           Dump the name Lmod in a machine readable way and quit

       --check_syntax --checkSyntax
           Checking module command syntax: do not load

       --config
           Report Lmod Configuration

       --miniConfig
           Report Lmod Configuration differences

       --config_json
           Report Lmod Configuration in json format

       --mt
           Report Module Table State

       --timer
           report run times

       -f --force
           force removal of a sticky module or save an empty collection

       --redirect
           Send the output of list, avail, spider to stdout (not stderr)

       --no_redirect
           Force output of list, avail and spider to stderr

       --show_hidden -A --all
           Avail and spider will report hidden modules

       --spider_timeout=timeout
           a timeout for spider

       -T --trace
           trace major changes such as loads

       --nx --no_extensions
           Do not print extensions

       --loc --location
           Just print the file location when using show

       --terse_show_extensions
           report extensions when doing a terse avail

       --pod
           Generate pod format

COMMAND OVERVIEW
       module [options] sub-command [args ...]

       Help sub-commands:

         help                              prints this message
         help                module [...]  print help message from module(s)

       Loading/Unloading sub-commands:

         load | add          module [...]  load module(s)
         try-load | try-add  module [...]  Add module(s), do not complain if not
                                           found
         del | unload        module [...]  Remove module(s), do not complain if not
                                           found
         swap | sw | switch  m1 m2         unload m1 and load m2
         purge                             unload all modules
         refresh                           reload aliases from current list of
                                           modules.
         update                            reload all currently loaded modules.

       Listing / Searching sub-commands:

         list                              List loaded modules
         list                s1 s2 ...     List loaded modules that match the
                                           pattern
         avail | av                        List available modules
         avail | av          string        List available modules that contain
                                           "string".
         category | cat                    List all categories
         category | cat      s1 s2 ...     List all categories that match the
                                           pattern and display their modules
         overview | ov                     List all available modules by short
                                           names with number of versions
         overview | ov       string        List available modules by short names
                                           with number of versions that contain
                                           "string"
         spider                            List all possible modules
         spider              module        List all possible version of that module
                                           file
         spider              string        List all module that contain the
                                           "string".
         spider              name/version  Detailed information about that version
                                           of the module.
         whatis              module        Print whatis information about module
         keyword | key       string        Search all name and whatis that contain
                                           "string".

       Searching with Lmod:

         All searching (spider, list, avail, keyword) support regular expressions:

         -r spider           '^p'          Finds all the modules that start with
                                           `p' or `P'
         -r spider           mpi           Finds all modules that have "mpi" in
                                           their name.
         -r spider           'mpi$         Finds all modules that end with "mpi" in
                                           their name.

       Handling a collection of modules:

         save | s                          Save the current list of modules to a
                                           user defined "default" collection.
         save | s            name          Save the current list of modules to
                                           "name" collection.
         reset                             The same as "restore system"
         restore | r                       Restore modules from the user's
                                           "default" or system default.
         restore | r         name          Restore modules from "name" collection.
         restore             system        Restore module state to system defaults.
         savelist                          List of saved collections.
         describe | mcc      name          Describe the contents of a module
                                           collection.
         disable             name          Disable (i.e. remove) a collection.

       Deprecated commands:

         getdefault          [name]        load name collection of modules or
                                           user's "default" if no name given.
                                           ===> Use "restore" instead ====
         setdefault          [name]        Save current list of modules to name if
                                           given, otherwise save as the default
                                           list for you the user.
                                           ===> Use "save" instead. ====

       Miscellaneous sub-commands:

         is-loaded           modulefile    return a true status if module is loaded
         is-avail            modulefile    return a true status if module can be
                                           loaded
         show                modulefile    show the commands in the module file.
         use [-a]            path          Prepend or Append path to MODULEPATH.
         unuse               path          remove path from MODULEPATH.
         tablelist                         output list of active modules as a lua
                                           table.

       Important Environment Variables:

         LMOD_COLORIZE                     If defined to be "YES" then Lmod prints
                                           properties and warning in color.

       Lmod Web Sites

         Documentation:    https://lmod.readthedocs.org
         GitHub:           https://github.com/TACC/Lmod
         SourceForge:      https://lmod.sf.net
         TACC Homepage:    https://www.tacc.utexas.edu/research-development/tacc-projects/lmod

         To report a bug please read https://lmod.readthedocs.io/en/latest/075_bug_reporting.html

AUTHOR
       Robert McLay mclay@tacc.utexas.edu

perl v5.34.0                                                          2024-10-16                                                            MODULE(1)
    
:::
                                                                                   
[User Guide for Lmod](https://lmod.readthedocs.io/en/latest/010_user.html)
ml 的語法和 module差的有點，+來添加 -來去除
有個 family(“MPI”) 語法，能把modules綁在一起，並確定唯一性。
這會創建env var LMOD_FAMILY_MPI
會有 "lib"-"compiler" 的 modulefile來管理
想想，當lib有多個版本
翻: saner 理智的, san理智

A much saner strategy is to use a module hierarchy. Each compiler module adds to the MODULEPATH a compiler version modulefile directory. Only modulefiles that exist in that directory are packages that have been built with that compiler. When a user loads a particular compiler, that user only sees modulefile(s) that are valid for that compiler.

所以，有不同的編譯器，每個編譯器不同的版本，每個套件不同的版本，每個套件有這三個維度。然後每個套件都要這樣歸類，lmod可以作到這樣的管理模式，有編譯器選擇，編譯器版本選擇，套件版本選擇。這稱為 Module Hierarchy ，除了這些，還會有更多需求。

compiler-x.y.z-mpi-x.y.z-package-x.y.z
這個package depends on compiler+mpi，一開始會show 所有，然後 load compiler 後只show depends on this compiler 的 packets，然後在load mpi，就只顯示這個compiler這個mpi，這樣就很棒。

目前出現了一個問題，apt安裝的二進制檔案都塞在/usr/bin裡面，我需要把他們分別裝入不同的目錄才能使用，lmod是基於目錄和環境變量管理的。spack可以和module協作，但可能還是需要從原代碼裝D:，因為可能有套件是spack沒提供或版本不是我們需要的。

目前打算去裝gcc，這樣就有足夠的gcc版本來實驗module。

:::spoiler [Prompt]等等，gcc是用gcc編譯出來的？
是的，GCC（GNU Compiler Collection）本身就是一個編譯器，而它的源碼是用 GCC 本身來編譯的。這種情況被稱為“自編譯”（self-compilation）。以下是一些相關的細節：
自編譯的過程

    初始版本：
        通常，最初的 GCC 版本是使用 C 語言的其他編譯器（例如，CC、DJGPP 或其他）來編譯的。這是因為早期的 GCC 版本可能尚未存在於某些系統上。

    自編譯：
        一旦你有了一個版本的 GCC，你可以使用它來編譯新的 GCC 版本。這意味著可以在已有的 GCC 基礎上進行開發和優化，這樣就形成了一個循環。

    交叉編譯：
        在某些情況下，開發者可能會選擇交叉編譯 GCC，以便為不同的硬體架構生成編譯器。

相關的考量

    版本兼容性：
        不同版本的 GCC 之間可能存在不兼容的變化，這意味著一個版本的 GCC 可能無法編譯另一個版本的 GCC，尤其是當引入重大變更時。

    依賴管理：
        編譯新的 GCC 版本時，通常需要指定一些庫和依賴，這些庫和依賴也可能需要使用 GCC 編譯，這樣會形成一個相互依賴的環境。

    性能和優化：
        使用最新版本的 GCC 編譯自己，可以利用新的優化特性和性能改進，使生成的二進制文件更高效。

總結

總的來說，GCC 確實是用自己編譯的，這是一個常見的現象，在許多編譯器和編程語言中都會看到類似的自編譯過程。這種設計使得編譯器能夠不斷進化並引入新的功能和優化。
:::

gcc-releases-gcc-11.4.0 依賴於GMP 4.2+, MPFR 3.1.0+ and MPC 0.8.0+
[gcc-releases-gcc-11.4.0安裝網址](https://github.com/gcc-mirror/gcc/tags)
[gcc安裝說明](https://gcc.gnu.org/install/configure.html)
[GMP-6.2.1安裝網址](https://github.com/alisw/GMP/tags)
[GMP安裝說明(挺好笑的)](https://github.com/alisw/GMP/blob/master/INSTALL)
NOTE: 別裝在/usr/local(預設的)裡，用./configure --prefix=/opt/...來裝在我們期望的位置。這帶來了令一個問題，以後需要的套件是不是都要源碼安裝了._. (我會想念一行指令就完成安裝的日子)，畢竟包管理器不能指定好版本跟位置(?)

:::spoiler [Prompt] 我有一個問題，當我的env var中有兩個目錄都有執行檔gcc ，它會用哪個阿？
在環境變數中，當有多個目錄都包含相同的可執行檔（例如 gcc）時，系統會根據 PATH 環境變數中的順序來決定使用哪一個執行檔。以下是一些重要的細節：
如何決定使用哪個 gcc

    PATH 變數的順序：
        PATH 變數是一個以冒號分隔的目錄列表，當你在命令行中執行某個命令時，系統會按照 PATH 變數中目錄的順序依次搜尋可執行檔。

    第一個找到的可執行檔：
        當你輸入 gcc 命令時，系統會從 PATH 變數中第一個找到的可執行檔執行。因此，如果你有兩個目錄，分別是 /usr/local/bin 和 /usr/bin，且這兩個目錄下都有 gcc 可執行檔，那麼如果 /usr/local/bin 在 PATH 中排在 /usr/bin 前面，則會使用 /usr/local/bin/gcc。

如何查看 gcc 的位置

你可以使用 which 命令來查看執行的 gcc 版本的具體路徑，例如：

bash

which gcc

這條命令會返回 gcc 可執行檔的完整路徑，讓你知道實際使用的是哪一個。
:::


[MPFR安裝說明]

在裝好gcc之前，我需要先設定好模組階層關係

:::spoiler [Prompt] 一般來說在HPC裡面，套件裝在哪裡，modulefile裝在哪裡？
在高效能運算（HPC）環境中，套件和模組文件（modulefile）通常根據系統架構、管理策略和易於維護的需求來存放。以下是常見的做法：
1. 套件安裝位置

HPC 系統中的軟體套件通常不會安裝在系統的默認目錄（例如 /usr 或 /bin），而是放在專門的目錄下，以便進行更好的管理和版本控制。常見的套件安裝目錄包括：

    /opt: 這個目錄通常用來安裝由系統管理員管理的應用程式和庫。例如，編譯器、MPI、數值計算庫等會安裝在 /opt 下的子目錄中，如 /opt/gcc/9.3.0。
    /apps: 許多 HPC 系統將套件安裝在 /apps 目錄下，這是一個自定義目錄，方便進行軟件分類與版本管理。例如：
        /apps/gcc/10.2.0
        /apps/openmpi/4.1.0
    /software 或 /shared: 某些 HPC 環境中也會使用 /software 或 /shared 作為軟體安裝位置，這些目錄通常與多個節點共享。

安裝路徑通常是根據軟件的用途和版本進行區分的，例如 /apps/\<category>/\<software>/\<version>。
2. 模組文件（modulefile）存放位置

模組文件用來讓用戶方便地加載和管理不同版本的軟體。它們通常存放在與安裝目錄分開的專門位置。模組文件的存放位置主要取決於系統的模組管理工具（如 Lmod），以下是常見的目錄結構：

    /etc/modulefiles 或 /usr/share/modulefiles: 一些系統會把模組文件存放在 /etc 或 /usr/share 目錄下，這是全系統共享的路徑。

    /apps/modulefiles: 一個更靈活的做法是在 /apps 目錄下創建一個 modulefiles 子目錄，這樣可以與實際的套件安裝位置緊密結合。例如：
        /apps/modulefiles/Compiler/gcc/10.2.0.lua
        /apps/modulefiles/MPI/openmpi/4.1.0.lua

    /opt/modulefiles: 對於安裝在 /opt 的套件，模組文件有時會被放在 /opt/modulefiles 下。這樣可以清楚地將模組文件和軟體安裝區分開來。

3. 模組層次結構（Module Hierarchy）

許多 HPC 環境使用 Module Hierarchy，根據編譯器和 MPI 層次來管理軟體包。例如，GCC 和 OpenMPI 都有不同的版本，並且需要確保每個軟件包只能與兼容的編譯器和 MPI 版本一起使用。這樣的層次結構有助於避免版本衝突和不兼容問題：

bash

/apps/modulefiles/Compiler/gcc/10.2.0
/apps/modulefiles/MPI/openmpi/4.1.0/gcc/10.2.0
/apps/modulefiles/Package/mytool/1.0.0/gcc/10.2.0/openmpi/4.1.0

在這樣的結構中，編譯器模組和 MPI 模組分層管理，當用戶加載某個編譯器時，只能看到與該編譯器版本兼容的模組。
4. 總結

    套件：通常安裝在 /opt、/apps 或 /software 等專用目錄下，這樣有助於進行版本控制和隔離不同版本的軟體。
    模組文件：通常存放在 /etc/modulefiles 或 /apps/modulefiles 等專用目錄中，以方便模組管理工具（如 Lmod）管理模組層次結構。

這樣的結構使得 HPC 環境中的軟體管理更加靈活、版本控制更加精確，並且允許用戶方便地加載和切換不同版本的軟體。
:::

我打算把 modulefile 放在/opt/apps/modulefile目錄下，實際套件放在/opt裡。

:::spoiler [Prompt] 好吧，假設我作為管理員在opt/app架設好了編譯器MPI和其他套件完整的階層模組，多個用戶該怎麼在同時間存取不同的套件？
在HPC環境中，如果你作為系統管理員已經在 /opt/app 架設好完整的模組層次結構，讓用戶能夠同時存取不同版本的編譯器、MPI和其他套件是完全可行的。這是 module 系統和模組層次結構（Module Hierarchy）的核心功能。下面將解釋多個用戶如何在同時間存取不同的軟件，以及如何配置系統來支持這一點。
1. 模組層次結構（Module Hierarchy）

模組層次結構是通過不同編譯器、MPI 和其他套件的層次化結構來組織軟件的。常見的結構是：

    編譯器層次：例如，GCC、Intel Compiler 等
    MPI層次：例如，OpenMPI、MPICH，這些通常依賴於特定的編譯器版本
    軟件層次：具體的科研軟件或者其他工具，通常依賴於某個編譯器和 MPI

每一層次的模組文件會根據當前環境的變數（如編譯器版本、MPI 版本）來決定用戶可以看到的模組。例如，用戶加載了 GCC 9 之後，只能看到與 GCC 9 兼容的 MPI 和軟件套件。
設置示例

你可以按照以下方式組織模組層次：

bash

/opt/app/modulefiles
    ├── Core
    │   └── gcc/9.3.0
    │   └── gcc/10.2.0
    ├── gcc
    │   ├── 9.3.0
    │   │   └── openmpi/4.0.3
    │   │   └── mpich/3.3.2
    │   ├── 10.2.0
    │       └── openmpi/4.1.0
    │       └── mpich/3.4.1

    Core 目錄下存放核心模組，例如編譯器（GCC）。
    編譯器加載之後，會擴展 MODULEPATH 讓用戶看到該編譯器支持的 MPI 版本和其他軟件。

2. 如何多用戶同時存取不同版本的軟件？

module 系統通過環境變數來管理不同軟件版本，因此每個用戶在當前會話中的環境是獨立的。這意味著多個用戶可以同時加載不同的模組並使用不同的軟件版本，而互不影響。
使用場景：

    用戶 A 加載 GCC 9.3.0 並使用 OpenMPI 4.0.3
    用戶 B 加載 GCC 10.2.0 並使用 MPICH 3.4.1

這兩個用戶的 MODULEPATH 將會被獨立地設置，指向相應的軟件版本。
3. module 系統如何工作？

每個用戶的 shell 環境中有獨立的 MODULEPATH 環境變數：

    用戶加載某個編譯器（如 module load gcc/10.2.0）。
        這會修改 MODULEPATH，添加 GCC 10.2.0 相關的 MPI 和軟件模組目錄。
    用戶加載特定版本的 MPI（如 module load openmpi/4.1.0）。
        這會進一步修改 MODULEPATH，使得與該 MPI 版本兼容的軟件模組可見。
    當用戶卸載或切換模組時，MODULEPATH 會自動更新，確保每個用戶看到的是其所需的環境。

4. 多用戶同步操作

每個用戶的模組操作只會影響他自己的會話環境，這樣：

    用戶可以在同一系統上同時使用不同版本的編譯器、MPI 或其他套件。
    模組系統依賴環境變數而不是全局設定，因此不會出現多用戶衝突。

5. 性能與存取問題

    文件系統性能：如果有大量用戶同時訪問同一文件系統（如 /opt/app），需要確保文件系統能夠處理高並發請求，例如使用高性能並行文件系統（如 Lustre 或 GPFS）。
    模組文件管理：模組文件的管理通常由系統管理員負責，確保新安裝的軟件能夠被正確配置和加載，並且不同軟件版本之間不會產生衝突。

6. 用戶自定義模組

如果某些用戶需要特定的軟件版本或者自定義的環境，他們可以通過將自己的模組文件放在個人目錄中，並將該路徑加入 MODULEPATH 環境變數來實現個性化管理。
總結

    使用模組層次結構（Module Hierarchy）可以確保用戶同時存取不同版本的軟件而不會互相干擾。
    多個用戶可以同時加載不同的編譯器、MPI 和其他軟件，系統會通過環境變數來管理軟件版本的可見性。
    系統管理員可以集中管理模組文件，並根據需要進行權限限制和性能優化。
:::

這看起來很符合我們的需求:D，多個用戶，每個用戶獨立，開新的窗口，module load 一大堆套件，然後運行。

這需要測試過，我該怎麼運行多用戶的測試呢？
1. ACM server?需要root，和管理者交流
2. 開個虛擬機器，兩個帳戶試試看？很好，但我需要讓別人使用
3. 開個花錢的server？很好，讓人連進來，load 模組，然後運行:D。

還有一些問題，像是我們需要把東東放在指定的位置，這需要配合，然後他們需要熟悉這套方式。像是gcc就要自己編譯，不能夠什麼apt install 打下去就直接用。
1. 讓他們會且熟悉基於module運行程式。
2. 從源碼編譯可能對他們來說太複雜，需要讓他們在關鍵的套件上捨棄包管理器，而使用源碼安裝，並且能夠設定安裝在指定的位置。
3. 以前的思路是把東西找來-> 跑程式，現在是變成把東西安裝到指定的地點 -> 撰寫module file -> load module file ->跑程式，我得先摸熟xAx



:::spoiler [Prompt] apt 可以指定版本和安裝位置嘛？
使用 apt（或 apt-get）安裝軟件時，可以指定軟件版本，但無法直接指定安裝位置。這是因為 apt 包管理器會根據預設的系統路徑來安裝軟件，並不支持像 spack 或手動編譯時自定義安裝位置的功能。下面詳細解釋這兩個問題：
:::
spack反而是一個選項。待學習，目前以源碼安裝為主。

:::spoiler [Prompt] 我想問一下，在多節點上實施這套方法，是不是直接把主電腦的/opt當作nfs，然後灌到所有的子節點上？
是的，在多節點的高效能運算（HPC）環境中，將主節點的 /opt 目錄通過 NFS（Network File System）共享給所有子節點是一個常見的實踐方法，這樣可以確保所有節點能夠訪問相同的軟件和模組配置。這樣的配置有以下好處：
1. 軟件共享與一致性

當你把軟件安裝在 /opt 目錄下，並通過 NFS 將該目錄掛載到所有的計算節點時，所有節點都會使用相同的軟件版本，這確保了軟件環境的一致性，避免了每個節點單獨安裝和維護的麻煩。
2. 模組管理共享

當你使用 Lmod 或其他模組管理系統，將模組檔案放在 /opt 下時，子節點可以通過 NFS 訪問相同的模組，這樣每個節點可以方便地加載正確的模組配置。這是因為 Lmod 的模組檔案位於 /opt/modulefiles 或類似位置，NFS 掛載後可以確保每個節點都能訪問和加載相同的模組檔案。
3. 簡化管理

使用 NFS 共享後，你只需要在主節點上維護 /opt 目錄內的軟件和模組檔案。如果需要更新或安裝新的軟件，子節點會自動獲得最新的版本，這樣可以大大簡化軟件的更新和維護工作。
實施步驟大致如下：

    主節點設置 NFS 服務： 在主節點上，將 /opt 目錄通過 NFS 共享出來。編輯 /etc/exports 文件，加入以下內容：

    bash

/opt *(rw,sync,no_root_squash)

然後執行以下命令來啟用 NFS 服務：

bash

sudo exportfs -a
sudo systemctl restart nfs-kernel-server

子節點掛載 NFS 共享： 在所有子節點上，將主節點的 /opt 目錄掛載到本地的 /opt 目錄下。在 /etc/fstab 文件中添加如下條目，以自動掛載 NFS 共享：

bash

<主節點IP>:/opt /opt nfs defaults 0 0

然後手動掛載：

bash

    sudo mount -a

    驗證： 確認每個子節點都能正確地掛載 /opt 目錄，並且可以訪問模組和軟件。你可以在子節點上使用 module avail 命令，檢查是否可以正確加載來自 /opt 目錄的模組。

注意事項：

    NFS 性能：NFS 性能受限於網絡的帶寬和延遲。如果節點數量龐大或者讀寫負載較高，可以考慮使用高效能的共享文件系統（如 Lustre、BeeGFS）來替代 NFS。

    掛載權限：確保 NFS 共享的權限正確，特別是使用 no_root_squash 選項，這樣可以防止子節點的 root 權限被降權，保證正常使用安裝在 /opt 目錄中的軟件。

總之，這種方法簡化了多節點上的軟件安裝與管理工作，對於高效能運算集群是非常實用的配置策略。
:::
chatgpt 提到了 Lustre 和BeeGFS這些東西，新的複雜度D:，看一下大約的節點數量，超過20個就需要學這個。
看來module設計，把東西統一裝在/opt，nfs(或其他分散式檔案系統)是運行叢集電腦的根基，我需要花心力在隊員間推廣D:。之前我分兩次在兩個電腦上分別安裝程式，還能跑起來，真是奇蹟:D。

[要1000行了，換下個文章](/Fq7OdVxdQZS0hbiF_FazHg)















