Lmod 跨工程待办交接单（给 eda_tools_ins 侧）¶

来源：slurm 项目 2026-10-05 变更 slurm_ins/lmod_site_package_20261005/（SOP 见该目录）目的：把不在 slurm 生成器管辖内、需 eda_tools_ins 侧（Synopsys/ / Cadence/）处理的 Lmod 事项集中交接口径：【已确认】=本机实测；【待决策】=需项目方定；本文件只记事与判据，不代替各工程的 SOP

0. 怎么用¶

按第 2 节「待处理清单」逐条派工：每条给出现象与证据 → 需哪个工程做什么 → 验收判据 → 落点。第 1 节是属主现状表，先看它再动手——多数问题的根因是「同一路径有两个属主」。

1. module 树属主现状【已确认】¶

/opt/modulefiles（NFS 192.168.31.249:/data/nfs/modulefiles，客户端六台 + 提交节点）是共享写入区，不同工程各写一部分：

模块路径	属主工程	生成方式	状态
`Core/{cadence,pdk,siemens,synopsys,site}.lua`	`slurm_ins`	yaml 生成器渲染（`--module-env`）	正常
`siemens/calibre/2026.1.lua` + `siemens/calibre/.modulerc.lua`	`slurm_ins`	同上	悬空：`install_dir=/opt/eda/...` 占位，实体不存在（`isDir` 守卫会 LmodError）
`siemens/calibre/2015.2_36.27.lua`	`eda_tools_ins/Cadence`（`ic617_install_20260926`）	装载工程渲染	正常（实际在用）
`synopsys/vcs/2023.12.lua`	`slurm_ins`（按 yaml 生成）	生成器渲染	悬空 + 双属主：`install_dir` 占位不存在；且被 `Synopsys/synopsys_module_fix_20260929/fix_modules.py` 判为「悬空」而删除
`synopsys/eda2018/1.0.lua`	`eda_tools_ins/Synopsys`（`synopsys_module_fix_20260929`）	工程脚本改动（补 SCL 入口）	正常（实际在用）
`synopsys/vcs-el7/1.0.lua`	`eda_tools_ins/Synopsys`（`vcs_el7_binutils_20260929`）	工程 `templates/` 渲染	正常
`synopsys_compat/*`（`bin/uname`、`lib64/.so`、`libexec/libpthread.so.0`）	`eda_tools_ins/Synopsys`（`rocky9_eda_compat_20260928`）	兼容层数据（不是 modulefile）	位置待商（见 C-1）
`cadence/virtuoso/IC06.17.700.lua`	`eda_tools_ins/Cadence`（`ic617_install_20260926`）	装载工程渲染	正常
`pdk/sky130/1.0.lua`	`slurm_ins`	生成器渲染	悬空：`install_dir=/opt/eda/pdk/sky130` 占位不存在
`pdk/saed32/1.0.lua`	`eda_tools_ins/Synopsys`（`synopsys_pdk_saed32_20260929`）	工程 `artifacts/` 渲染	正常

结论：Core/ 与 pdk/sky130、siemens/calibre/2026.1、synopsys/vcs/2023.12 归 slurm_ins；其余工具实体归 eda_tools_ins 两侧。任何一处改名/移动前，先查本表。

2. 待处理清单¶

A. 【最高优先】`synopsys/vcs/2023.12.lua` 的「写—删」拉锯¶

✅ 已结案（2026-10-05）：eda_tools_ins 侧作项目方定方案 1 并实施——slurm 侧已从 config/slurm_deploy.yaml 删除 synopsys.vcs 条目并退役清理该模块（备份在 .16:/var/backups/slurm/modulefiles/synopsys-vcs.removed.tar.gz）；eda 侧 fix_modules.py 已移除删除逻辑（改幂等确认）。两侧不再对同一文件做相反动作。变更档案：eda_tools_ins/lmod_cross_project_fix_20261005/。

现象【已确认】：同一个文件有两个相反动作——

slurm_ins 的 config/slurm_deploy.yaml 里 families.synopsys.tools 含 vcs/2023.12，--module-env 会生成该文件；
Synopsys/synopsys_module_fix_20260929/fix_modules.py 把它判为「指向不存在的 /opt/eda/synopsys/vcs/2023.12」的悬空模块并删除（synopsys/vcs/2023.12.lua.removed）。

2026-10-05 --module-env 已把它重新生成（synopsys/vcs/2023.12.lua 现存在于共享盘），下一次任何人跑 fix_modules.py --apply 又会删掉。两边都不知道对方（Synopsys/docs/PROJECT-MAP.md 只在 module_fix 卡片里写了一句「slurm 部署器复跑重建部分模块后须重跑本脚本」）。

需做什么（二选一，请项目方定）：

方案 1（推荐，归 slurm 侧）：真实 VCS 实体是 /tools/synopsys/vcs-mx/N-2017.12-SP2，且已由 synopsys/eda2018/1.0.lua 提供 vcs 命令 → slurm_ins 直接从 yaml 删掉 synopsys/vcs 条目（生成器不再产出），并由 eda_tools_ins 侧从 fix_modules.py 中移除那段删除逻辑（改为幂等确认）。好处：一个模块只在一个地方定义。
方案 2（归 eda 侧）：若确实要保留 synopsys/vcs/2023.12 这个名字指向真实工具树，则由 eda_tools_ins 把它纳入自己的装载工程（写进 synopsys_module_fix_20260929 的职责），并请 slurm_ins 从 yaml 删除条目，避免生成器覆盖。

验收判据：/opt/modulefiles/synopsys/vcs/2023.12.lua 在「跑过 --module-env」与「跑过 fix_modules.py --apply」之后状态一致（都在或都不在），且 module load synopsys && module load vcs/2023.12 && command -v vcs 有确定结论（成功，或该模块不存在）。

落点：slurm_ins/config/slurm_deploy.yaml（一侧）＋ Synopsys/synopsys_module_fix_20260929/（另一侧）。

B. 【高】`siemens/calibre/` 一目录双属主 + 默认版本归属¶

✅ 已结案（2026-10-05）：实测确认 calibre/2026.1 无实体（.18 上 /opt/eda 不存在、 /tools/mentor/calibre 仅有 aoi_cal_2015.2_36.27）→ 取「移除悬空 2026.1」分支：slurm 侧已删 yaml 条目，并退役清理 siemens/calibre/2026.1.lua 与 .modulerc.lua（备份在 .16:/var/backups/slurm/modulefiles/）。此后该目录仅存 2015.2_36.27.lua 一个版本， module load calibre 裸名加载恢复，实测 .18 命中 /tools/mentor/calibre/aoi_cal_2015.2_36.27。变更档案：eda_tools_ins/lmod_cross_project_fix_20261005/。

现象【已确认】：

siemens/calibre/2015.2_36.27.lua 由 Cadence/ic617_install_20260926 维护（实体在 /tools/mentor/...，在用）；
siemens/calibre/2026.1.lua 由 slurm_ins 生成（悬空，/opt/eda/siemens/calibre/2026.1 不存在）；
2026-10-05 起 slurm_ins 又在该目录新增 .modulerc.lua：module_version("calibre/2026.1","default") + "latest"。

问题：当前 module load calibre 会命中悬空的 2026.1（报 LmodError），而实际可用的 2015.2 反而要写全版本号才能加载。这是本轮引入的行为回退，必须由两侧一起定。

需做什么：

eda_tools_ins/Cadence 确认：calibre 2026.1 到底有没有实体（HANDOFF 待办 #2 已挂「实体本机不存在」）？
若有（在别处）→ 告知 slurm_ins 真实 install_dir，由 yaml 改指；
若没有 → slurm_ins 应从 yaml 删掉该条目（生成器不再产出 2026.1），并把 .modulerc.lua 的默认版本改为 2015.2_36.27（可行时），或整个撤掉 .modulerc.lua，恢复 module load calibre/2015.2_36.27 的既有用法。
约定：siemens/calibre/.modulerc.lua 归 slurm_ins 生成器所有，Cadence 侧不得写该文件；Cadence 侧若需别名/默认版本，改为提给 slurm_ins 在 yaml 里配 default_version / version_aliases。

验收判据：module load siemens && module load calibre 在六台 + .28 上成功且加载到有实体的版本；module -t avail 中无指向不存在目录的 calibre 条目。

落点：slurm_ins/config/slurm_deploy.yaml；Cadence/docs/HANDOFF.md 待办 3。

C. 【中】兼容层位置与 module 树整洁¶

C-1 synopsys_compat/ 放在 module 树里【已确认】：/opt/modulefiles/synopsys_compat/（bin/uname、lib64/{liblcms.so.1,libmng.so.1,libtiff.so.3}、libexec/libpthread.so.0）是兼容层数据、不是模块，却被 synopsys/eda2018/1.0.lua 以 LD_PRELOAD / PATH 引用；而另一套同类兼容层（vcs-el7 用的 el7 binutils）在 /opt/compat —— 两处不一致，且模块树里混入非模块目录会被 module spider / spider 缓存遍历。

需做什么：由 Synopsys/rocky9_eda_compat_20260928（属主）决定是否统一到树外位置（建议 /opt/compat 或 /data/nfs/compat），并同步改 eda2018 模块里的引用；slurm_ins 侧只需知道最终路径（无 yaml 条目，无需改）。

验收判据：/opt/modulefiles 下只含模块定义与 .modulerc*；module load synopsys && module load eda2018/1.0 && vcs -ID 仍正常（LD_PRELOAD 生效）。

✅ C-1 已结案（2026-10-05）：取「迁到节点本地 /opt/compat」分支——实测六台 work + .28 的 /opt/compat 已含全部制品（el6 库 + shim + uname，sha256 与 NFS 源一致），NFS 那份为冗余副本。已改 eda2018 模块引用（并移除 PATH 前置，避免引入 /opt/compat/bin 下的 el7 binutils）、制品源迁入工程 artifacts/share、退役 /opt/modulefiles/synopsys_compat；部署工程新增 compat_share_local（支持操作机本地制品源）。实测 .18：ls /opt/modulefiles 仅 cadence Core pdk siemens synopsys；语法自检 No errors found；dc_shell / spyglass 正常。变更档案：eda_tools_ins/lmod_cross_project_fix_20261005/SOP.md 附录 C。（注：本项无需 slurm_ins 侧改动——无 yaml 条目。）

✅ C-2 已结案（2026-10-05）：三个悬空模块（synopsys/vcs/2023.12、siemens/calibre/2026.1、pdk/sky130/1.0）均无实体，已全部退役清理——前两个随 A/B，第三个本轮追加。处置后 .18 语法自检 No errors found，module avail 不再有指向不存在目录的条目。变更档案：eda_tools_ins/lmod_cross_project_fix_20261005/（附录 B）。

C-2 悬空模块统一清理【已确认】：以下模块的 install_dir 是 yaml 占位值、实体不存在（加载即 LmodError），但会出现在 module avail 里造成困惑：

模块	install_dir（占位）
`synopsys/vcs/2023.12`	`/opt/eda/synopsys/vcs/2023.12`
`siemens/calibre/2026.1`	`/opt/eda/siemens/calibre/2026.1`
`pdk/sky130/1.0`	`/opt/eda/pdk/sky130`

需做什么：eda_tools_ins 侧确认这三个工具的真实落点（VCS 见 A；sky130 也在 eda_tools_ins 待办 #2 里）。给出后由 slurm_ins 改 yaml 的 install_dir；确认不落地的条目由 slurm_ins 直接删除（生成器已有「登记即清理」机制，删条目时把路径登记进 obsolete_module_file_dirs 即可，无需手工删共享盘）。

验收判据：module load <家族> 后 module -t avail 里不再出现指向不存在目录的条目。

D. 【中】命名与默认版本（Lmod 行业标准，建议非破坏性做法）¶

现象【已确认】：现有两个模块名不符合 Lmod 通行的 vendor/tool/version：

synopsys/vcs-el7/1.0.lua（名字里混了「el7」这个环境标识）
synopsys/eda2018/1.0.lua（「eda2018」是批次名，不是工具名；内部其实是一整套 20 个工具入口的集合模块）

为什么本轮不动它：module load synopsys && module load eda2018/1.0 已写进 Synopsys/docs/*、design/ 的作业脚本与文档，改名会破坏存量用法。

需做什么（由项目方定，建议 B 方案）：

方案 A（不改名，推荐）：保留现名，在 synopsys/.modulerc.lua 里加别名，如 module_version("eda2018/1.0", "2018")、module_version("vcs-el7/1.0", "vcs/el7")，让标准写法与旧写法并存；
方案 B（改名）：vcs-el7 → vcs/2023.12-el7，eda2018 → 保持（集合模块本就不该套 vendor/tool/version），同时用 .modulerc.lua 保留旧名别名。

约定：.modulerc.lua 必须放在该模块的属主工程里生成（谁写 modulefile 谁写 modulerc），不要让 slurm 生成器代管——否则又是双属主。

验收判据：新旧两种写法都能 module load 成功；module --default avail 输出可读。

✅ D 已结案（2026-10-05）：采用方案 A（不改名 + 加别名）。实测修正一处机制认知—— module_version("vcs-el7/1.0","vcs/el7") 只能得到 vcs-el7/vcs/el7（别名被附加到 name 所在目录），要得到顶层 vcs/el7 必须用全局别名 module_alias("vcs/el7","vcs-el7/1.0")。故： synopsys/eda2018/.modulerc.lua 用 module_version("eda2018/1.0","2018")（属主 rocky9 工程）； synopsys/.modulerc.lua 用 module_alias("vcs/el7","vcs-el7/1.0")（属主 vcs_el7_binutils_20260929 工程，只登记该模块别名，避免双属主）。实测 module load eda2018/2018、module load vcs/el7 （ld 2.27-44.base.el7）与原名写法均成功；module avail 出现 vcs/el7(@vcs-el7/1.0)。变更档案：eda_tools_ins/lmod_cross_project_fix_20261005/SOP.md 附录 C。

E. 【低】`deprecate()` 标注（需项目方判断，不建议盲目加）¶

Lmod 的 deprecate() 可在加载老版本时提示「建议换新」。候选：cadence/virtuoso/IC06.17.700、siemens/calibre/2015.2_36.27、synopsys/eda2018。

注意：这三个都还在用（IC617 是模拟侧主力），加 deprecate() 会误导用户。只有在确定替代版本已就位时才加。本轮不做，仅登记。

落点：各装载工程的 modulefile 模板。

🔸 维持不做（2026-10-05 复核）：C-1/D 落地时一并复核，三个候选模块仍在用、替代版本未就位，加 deprecate() 会误导用户，故继续仅登记。见 eda_tools_ins/lmod_cross_project_fix_20261005/SOP.md 附录 C.8。

F. 【低】模块树语法自检¶

EPEL 的 Lmod 自带 check_module_tree_syntax（/usr/share/lmod/lmod/libexec/）。建议两侧收尾各跑一次（slurm_ins 的 --module-env 之后、eda_tools_ins 的装载工程之后），作为「模块树被谁改坏了」的第一道探测。

/usr/share/lmod/lmod/libexec/check_module_tree_syntax /opt/modulefiles

验收判据：无 syntax error 输出。

3. 需一并修正的文档口径（两处，均已与实际不符）¶

文件	现文	问题	建议改为
`eda_tools_ins/docs/HANDOFF.md` 第 4 节红线	「Lmod module 定义由 slurm 部署器生成，勿手工修改」	事实上有 6 处（`eda2018`、`vcs-el7`、`virtuoso/IC06.17.700`、`calibre/2015.2_36.27`、`pdk/saed32`、`synopsys_compat`）由 eda 侧装载工程渲染写入	「module 树是共享写入区；各工程只写自己那部分（属主见交接单第 1 节），改前先查属主，勿手工直接改文件——改模板后重跑对应工程」
`Cadence/docs/HANDOFF.md` 第 4 节红线 ⑤	「slurm `module_env` 与 `pdk_integration` 均只写不删」	自 2026-10-05 起 `slurm` 生成器新增 `obsolete_module_file_dirs`：在 yaml 中登记的退役目录会被备份后删除（备份在 `.16:/var/backups/slurm/modulefiles/`）	「`slurm module_env` 默认只写不删；但在 `obsolete_module_file_dirs` 登记过的路径会被备份后清理，删条目时须同步登记」

口径修正建议由 eda_tools_ins 侧自行落笔（那是它们的 HANDOFF）；slurm 侧已在 slurm_ins/docs/BASELINE.md 第 3 节记下本条机制。

4. 不要在跨工程变更里做的事（避免踩旧坑）¶

不要直接改 /opt/modulefiles 下的文件：六台 + 提交节点共享，且会被两侧生成器覆盖。改模板/配置后重跑各自工程。
不要把 IC617 纳入 slurm 生成器：它是单文件组合环境（IC617 + MMSIM151 + ASSURA41 三套路径、14 个环境变量），与生成器「一个工具一个 modulefile」的模型不匹配，纳入即被覆盖（Cadence/docs/HANDOFF.md 红线 ⑥ 已记）。
不要在 pdk/saed32/1.0.lua 里加 family()：家族标识只能由 Core/pdk.lua 声明，重复声明会触发 Lmod 家族冲突并连带卸载入口模块（saed32 文件注释里已实测记录）。
csh 侧改动必须双轨：LDAP 用户 loginShell 是 /bin/csh，只读 /etc/profile.d/*.csh；只改 .sh 的注入对 csh 用户等于没改（机制详 slurm_ins/docs/BASELINE.md 第 3 节）。

5. 两侧接口约定（本轮起生效，建议写进各自 SOP）¶

写入前先查属主（第 1 节表）；跨属主改动先在本交接单里追加一条，再动。
生成器/装载工程是唯一入口；共享盘上的 .lua 视为产物。
slurm_ins 侧新增能力（2026-10-05 起）：
站点扩展点 /etc/lmod/site/SitePackage.lua（经 LMOD_PACKAGE_PATH 覆盖 msgHook，已消除 module avail 尾部提示块）——eda 侧不要再各自压提示；
退役清理 obsolete_module_file_dirs：登记路径（目录或单文件皆可），部署器备份后清理；
默认版本/别名 .modulerc.lua 生成（default_version / version_aliases）。
eda2018 类的「集合模块」不受生成器管辖：其 PATH 入口表变动（如新增第 N 棵树、补 ICC 入口）仍由 synopsys_module_fix_20260929 / synopsys_icc_install_20260929 负责；每次 slurm_ins --module-env 复跑不影响它（生成器不写该路径）。
追加记录（2026-10-05，A/B 收敛）：跨属主改动已按第 1 条留痕——slurm_ins 删 yaml 的 synopsys.vcs / siemens.calibre 条目并退役清理 3 个路径；eda_tools_ins/Synopsys 的 fix_modules.py 移除对 vcs 的删除逻辑。两侧口径：同一模块只在一个地方定义；synopsys / siemens 家族入口保留（工具条目清空），故 eda 侧模块仍可见。变更档案：eda_tools_ins/lmod_cross_project_fix_20261005/。

来源：/home/rain/Documents/eda_tools_ins/docs/LMOD-CROSS-PROJECT-TODO.md ｜最后更新：2026-10-05 17:32（由 build/sync.py 同步，请勿在站点侧修改）