WSL2 + OpenFOAM 并行排错实录

01计算拓扑与链路

整套计算流程在 Windows 宿主机与 WSL2 Ubuntu 之间展开：

Windows 宿主机
    │
    ▼
WSL2 (Ubuntu 24.04)
    │
    ▼
OpenFOAM 2606
    ├── 1. blockMesh (生成风洞外围背景网格)
    ├── 2. decomposePar (基于 Scotch 切分 16 个计算域)
    ├── 3. snappyHexMesh -parallel (16 进程并行贴体与边界层细化)
    ├── 4. reconstructParMesh -constant (合并并行拓扑)
    ├── 5. checkMesh -constant (全局正交度与面扭曲校验)
    ├── 6. simpleFoam -parallel (16 进程稳态求解)
    └── 7. reconstructPar -latestTime (合并收敛步物理场)
    │
    ▼
ParaView (宿主机加载 case.foam)

最终生成的算例规模：

• 模型：DrivAer Fastback（含光滑底盘、后视镜、简化车轮及 MRF 旋转域配置）。
• 规模：5,542,069 个流体单元（以六面体为主的多面体网格）。
• 求解：16 进程并行稳态求解，迭代过程中实时监控 $C_d$ 与 $C_l$。

02单机 MPI 启动假死

现场与排错

执行并行网格生成命令后，控制台在打印完底层 Pstream 初始化信息后不再有任何输出：

mpirun -np 16 snappyHexMesh -parallel -overwrite
Pstream initialized with nonBlocking
# 进程持续存在，无报错、不退出，CPU 占用率全线为 0%

单机运行 mpirun 时，Open MPI 并不是纯靠内存直接寻址启动。其进程管理器（PRRTE/ORTE）在拉起各个 rank 阶段，需要借助 TCP 或本地套接字进行进程握手与元数据同步（即带外通信，OOB）。

当时 WSL2 配置了 Windows 11 的镜像网络模式（networkingMode=mirrored）。在该模式下，宿主机的 VPN 客户端、系统网络过滤驱动（WFP）以及各种代理服务会直接介入 WSL 的网络栈。当 Open MPI 尝试通过回环或默认虚拟网卡进行进程间握手时，握手包被宿主机过滤规则拦截丢弃，导致启动流程无限期挂起。

处理办法

单机开发环境下不需要镜像网络带来的复杂路由特性，将 WSL2 改回成熟的 NAT 模式：

[wsl2]
networkingMode=NAT
localhostForwarding=true

保存后在 PowerShell 执行 wsl --shutdown 重启 WSL。

此外，运行 mpirun 时显式指定节点内进程间通信（BTL）只走共享内存，避免运行时尝试通过物理网卡走 TCP：

mpirun --mca btl self,sm -np 16 snappyHexMesh -parallel -overwrite

完成网络模式回退后，MPI 初始化直接通过，进入实际切分流程。

03hexRef8 细化拓扑报错

现场与排错

MPI 恢复后，snappyHexMesh 在进入细化迭代时突然抛出底层拓扑异常退出：

[12] --> FOAM FATAL ERROR: (openfoam-2606)
[12] cell 30874 of level 3 does not seem to have 8 points of equal or lower level
[12]      From Foam::labelListList Foam::hexRef8::setRefinement(...)
[12]      in file polyTopoChange/polyTopoChange/hexRef8/hexRef8.C

hexRef8 是 OpenFOAM 基于八叉树进行六面体 2:1 剖分的核心模块。它要求网格细化必须在连续的拓扑层级下进行（相邻单元层级差不得大于 1）。

检查 constant/polyMesh/boundary 发现，当前算例目录下已经存在 38 个几何 patch，单元总数已达数百万。这表明目录中残留了上一轮测试生成的半成品网格，而不是 blockMesh 刚生成的原始背景网格（Level 0）。

在已经切分过、带有高细化层级悬挂节点的网格上二次运行 snappyHexMesh，八叉树算法在现有拓扑上再次细化，直接打破了 2:1 过渡规则，触发底层断言崩溃。报错指出的 cell 30874 只是第一个被遍历到的受损单元，并非几何本身有破洞。

恢复操作

清理派生目录，强制流程从纯净的 Level 0 背景网格重新开始：

# 1. 移走污染的网格
mv constant/polyMesh constant/polyMesh_corrupted_bak
# 2. 重新生成背景网格并确认
blockMesh
checkMesh
# 3. 清理历史分区并重新划分
rm -rf processor*
decomposePar -force
# 4. 启动并行切网格
mpirun -np 16 snappyHexMesh -parallel -overwrite 2>&1 | tee log.snappyHexMesh

在执行 decomposePar 之前，执行 checkMesh 确认当前网格只包含外围 6 个边界面，是防止此类拓扑崩溃的最直接手段。

04SIMPLE 压力参考自由度

现场与配置修正

网格顺利生成并通过检查后，启动并行求解，simpleFoam 在第 0 步初始化时直接退出：

--> FOAM FATAL IO ERROR: (openfoam-2606)
Unable to set reference cell for field p
Please supply either pRefCell or pRefPoint
file: system/fvSolution/SIMPLE at line 36.

不可压缩 Navier-Stokes 方程中，压力仅以梯度形式（$\nabla p$）出现。在风洞或整车外流场设置中，若所有边界均为速度入口、固壁（无滑移）或滑移对称面，且出口边界未指定固定静压（fixedValue），系统离散出的压力泊松方程矩阵处于奇异状态（解存在常数漂移自由度）。

此时求解器要求人为指定一个空间位置锚定基准压力。在 system/fvSolution 的 SIMPLE 字典中补充参考点：

SIMPLE
{
    nNonOrthogonalCorrectors 1;
    pRefPoint               (0 0 30);
    pRefValue               0;
}

注意两点：

1. pRefPoint 选取的空间坐标必须落在当前流体计算域内部，且能被正常映射到网格单元上；若坐标落在车体 STL 几何内部，求解器依然会因无法寻址而报错。
2. 修改完定解参数后，仅需运行 decomposePar -fields -force 将物理场分发更新至各个 processor* 目录，不需要重新执行耗时的网格几何切分。

05任务管理器核心负载观察

16 进程计算启动后，Windows 任务管理器的 CPU 总体利用率仅显示在 20% 左右。

这一现象是因为任务管理器默认展示的是全 CPU 逻辑处理器的平均负载。在具备多核心/多线程的现代 CPU 上，16 个 MPI 进程即使打满 16 个核心，加权后整体百分比依然显得偏低。

判断多核是否真正吃满算力的有效手段：

• 任务管理器：性能 → CPU → 右键图表 → 将图形更改为 → 逻辑处理器，确认分配给计算的 16 个核心是否全部打满。
• WSL 终端：直接运行 htop，观察 16 个 simpleFoam 进程的 CPU 时间分配与状态。

06实测数据与耗时

1. 网格几何与拓扑检查

网格生成完成后执行 reconstructParMesh -constant 合并，checkMesh -constant 输出的全局质量数据如下：

网格最大非正交度控制在 50.65°，平均值 7.78°，为后续压力泊松方程的快速收敛提供了较好的几何基础。

2. 求解阶段耗时

算例采用 SpalartAllmaras 湍流模型（SA-RANS），车轮区域配置 MRF 旋转坐标系。16 进程并行稳态迭代的单步耗时表现：

计算稳定后，常规迭代单步耗时稳定在 5.7 ~ 5.8 秒。当达到保存步触发写盘时，因 550 万网格在 16 个分区目录下的密集 I/O 操作，耗时会短暂增加到约 10.5 秒。

07排错检查清单

遇到并行与求解异常时，建议按依赖关系自底向上排查，避免在错误的层级调整参数：

1. 宿主机与虚拟网络 (WSL2 网络模式、VPN 代理规则)
   └── 现象：mpirun 无报错挂起，CPU 0%
2. MPI 运行时 (Open MPI 协议与通信组件配置)
   └── 现象：跨进程套接字不可达，提示网络超时
3. 算例历史状态 (constant/polyMesh 纯净度、processor 目录残留)
   └── 现象：hexRef8 细化断裂，拓扑层级跳跃报错
4. 定解条件与矩阵适定性 (边界类型匹配、pRefPoint 空间位置)
   └── 现象：求解器报 reference cell 缺失或压力发散
5. 物理模型与离散格式 (fvSchemes, fvSolution 松弛因子)
   └── 现象：残差震荡或数值溢出 (FOAM Floating Point Exception)