观潮 · 模式预报与气象 AI 观察

WPS 4.7.0 的 oneAPI 配置里 DM_FC 写错了：串行用 ifx，MPI 那一路却落到 gfortran

2026-10-17

> 有人指出 WPS 4.7.0 发行版给 oneAPI 的那份 arch 配置里存在一处不一致：串行 Fortran 编译器指定为 ifx，但 MPI 那一路的 DM_FC 指向 mpif90，而这个 wrapper 脚本内部调用的是 gfortran 而不是 ifx。发帖人原话说配置里写的是 mpifort，随后自己更正为 mpif90 并承认是笔误。在一台全新安装 Ubuntu 26.04、只装了 Intel oneAPI 没装 gfortran 的机器上，WPS 编译直接失败；把 DM_FC 换成 mpiifx 之后编译通过，但他明确声明还没有运行测试可执行文件。另一位参与者补充：这件事此前已向 NCAR 反映过，得到的答复是 wrapper 脚本不在 arch 的配置范围内。

问题出在哪一行

打开 WPS 4.7.0 针对「Linux x86_64, Intel oneAPI compilers」的那份 arch 配置，编译器相关的关键变量是这样的：

```

SFC = ifx

SCC = icx

DM_FC = mpif90

DM_CC = mpicc

FC = CONFIGURE_FC

CC = CONFIGURE_CC

LD = $(FC)

FFLAGS = -FR -convert big_endian

F77FLAGS = -FI -convert big_endian

CC_TOOLS =

```

同一份配置里，串行路径用的是 Intel 的 ifx 与 icx，分布式内存并行路径却用 mpif90 和 mpicc 这两个通用 wrapper。mpif90 是 shell 脚本，真正决定调用哪个 Fortran 编译器的行写在脚本内部——发帖人提到在第 127 行写着 FC=gfortran。

变量 · 配置里的值 · 实际落到的编译器

`SFC` · ifx · Intel ifx

`SCC` · icx · Intel icx

`DM_FC` · mpif90 · 脚本内部指定的 gfortran

`DM_CC` · mpicc · 随 wrapper 而定的 C 编译器

发帖人的判断是：既然要用 oneAPI 这套编译器，为了一致性，DM_FC 应该指向 oneAPI 发行版里的 mpiifx。他同时留了余地——除非存在某种理由刻意要在 MPI 下用 GNU 编译器，而这个理由他也表示想知道。

为什么多数人不会撞上

这条配置问题之所以长期没被触发，是因为绝大多数机器上同时装着 gfortran。发帖人的措辞很直白：大概 99% 的用户会把 gfortran 与 Intel 编译器一起装上，于是 mpif90 wrapper 找得到 gfortran，99% 的情况下编译是成功的。

只有在一台干净系统上才会暴露。发帖人的复现环境是全新安装的 Ubuntu 26.04，装了较新版本的 Intel oneAPI，当时尚未安装 GNU Fortran。结果是 WPS 编译直接失败——mpif90 脚本里的 FC=gfortran 找不到目标编译器。

三个 wrapper 脚本的关系

帖子把 Intel 的 MPI wrapper 命名沿革也梳理了一遍，这是理解建议值的前提：mpiifort、mpif90、mpiifx 都是可读的 csh 脚本。发帖人的理解是 ifort 是 ifx 编译器先前的名字，而 mpiifort 指向的是 mpiifx wrapper；Intel 把 ifort 改名为 ifx，是为了与 C 编译器 icx 的命名保持一致。

据此他给出的建议是有优先级的：

建议程度 · 取值 · 理由

更好 · `mpiifx` · 与 icx 命名一致，属于 oneAPI 现行写法

可接受 · `mpiifort` · 指向同一个 wrapper，但名字沿用了旧称

现状 · `mpif90` · wrapper 内部落到 gfortran，与 SFC=ifx 不一致

另一层隐患：混合环境下的 MPI.mod

除了装了 gfortran 就能编过之外，发帖人还担心一件他没有答案的事：在 oneAPI 与 GNU 并存的混合环境里，究竟会加载哪一个 MPI.mod。他的原话是「不知道」。也就是说，即便编译通过，MPI 模块也可能来自与本意不同的那套工具链，而这种不一致不会在编译日志里明确报错。

官方为什么没改

另一位参与者回忆，这件事此前就已经和 NCAR 提过，对方（他记得是 islas 或 mgduda，自己也说不确定是哪一位）的解释是：因为它是一个 wrapper，所以没有放进 arch 配置里。这条答复解释了现状的来源，但没有给出后续是否会调整的承诺。

还没做的事

• 可执行文件没有测试。 发帖人换成 mpiifx 后确认 WPS 编译成功，但明确写了「have not tested the executables」——编译通过与运行结果正确是两件事，这一步还没走完。
• 「99%」是发帖人的估计，不是统计数字。 这条数据用来说明多数环境下的表现，不能当成实测覆盖率。
• 混合环境下加载哪个 MPI.mod 没有被判定。 发帖人自己说不知道，帖子中也没有进一步验证。
• 没有讨论 DM_CC。 讨论集中在 Fortran 一侧的 DM_FC，mpicc 是否同样需要换成容器解释 mpiicx，帖子没有涉及。

一句话判断

这是一处「串行用 Intel、并行悄悄落到 GNU」的配置不一致，在干净机器上会让 WPS 直接编译失败，修法是让 DM_FC 指向 mpiifx；但改完的可执行文件尚未验证，而 NCAR 维持现状的理由是 wrapper 不在 arch 的职责范围内。

在观潮中打开（含配图与交互）→