NASA拿它跟自家软件对打,开源CFD怎么成了刚需?

说个挺有意思的事，NASA 埃姆斯研究中心拿一个开源求解器，去跟自己用了很多年的主力代码对打。

它叫 PyFR，帝国理工和德州农工的人牵头，BSD 许可证，走通量重构高阶方法。精度能往上堆，从 CPU 到各家 GPU 都能跑。

对打的是 US3D，NASA 算再入舱流场的主力。比的是 Viking '75 再入舱尾迹，马赫数 0.2 到 1.2。

NASA 的论文措辞很实在：PyFR 是从底层就为 GPU 设计的，通量重构算法计算密集、模板紧凑、通信需求低。埃姆斯的 Bhaskaran 说得更直接——改变游戏规则的工具，原来几周甚至几个月的仿真，现在几小时。IBM Research Europe 也拿它当性能基准好些年。

所以“开源 CFD 能不能用于工程”这场争论，其实结束了。

省钱当然省。但那是顺带的。真正值钱的，是改得动。

看今年这几个版本。OpenFOAM 14（7 月 14 日）约 938 次提交，修掉 130 个问题，燃烧求解器 XiFluid 用 MULES 多相方法重写。OpenCFD 的 v2606 铺上 GPU 卸载基础设施，加了 GEKO 湍流模型和 Python 绑定。SU2 的 8.5.0 把 CUDA FGMRES 直解端到端搬上 GPU。

推着它们走的不是产品经理排期，是用户自己。

燃烧求解器重写这种事，放在商业软件里，要么不做，要么排到下下个版本。开源里没这层等待。谁着急谁动手。GPU 尤其明显。硬件半年一换，闭源得等厂商，开源能自己先跑起来。

还有一层：看得见。代码摆在那儿，湍流模型怎么写都能翻。说实话，这点被低估得挺厉害。

Nektar++ 今年 1 月在英国国家超算 ARCHER2 上，把不可压 N-S 求解器扩展到 65536 个 CPU。9 月 14 到 15 日，英国 CCP-WSI 在牛津办首届工程会议，议程里主角基本是开源：STFC 的 gpuFOAM、code_saturne 搭的 HPC 工业流程、曼彻斯特大学用 Kokkos 重构 DualSPHysics。

我觉得这才是关键。仿真能力整套建在别家授权上，等于把研发节奏交出去。开源的意义不是用不用得起，是离不离得开。

开源不是白捡的。没厂商兜底，出问题自己查。文档散，前后处理仍有差距。

可硬件在换、AI 正挤进来、物理模型越切越细。这时候，能自己改的东西，一定比等别人改的跑得快。

PyFR 那句“几小时对几周”，NASA 已经替它背书了。