再来扯国产CFD软件

聊这个话题压力挺大。记得以前聊过这话题，每次都有人在后台骂，我实在搞不清楚问题出在哪里，就算说得不对，那也可以摆道理摆数据来辩嘛，完全没有必要张口就喷。

注：本文纯属说梦话。你可以看，但不要试图喊醒我。

”

说实话我并不看好目前所谓的国产自主知识产权的CFD开发。一大部分这些搞CFD开发的，趁着最近几年国家加大工业软件开发投入的东风，一些已经做好外壳准备薅羊毛，另一些则在准备制作外壳的路上。当然不排除少数勤勤恳恳的开发者，这些人才是国产CFD的希望。

我一直认为套壳并不是一件丢人的事情。目前有很多开源的CFD求解器，用来应付大多数工程应用并没有多大的问题，所欠缺的只是工程应用环境对软件的调校，以及用户操作效率方面的提升。基于开源求解器，针对特定行业深度开发前后处理器，也是不错的做法。不过只开发前后处理器似乎很难薅到羊毛。

影响一款CFD软件的工程应用普及度的因素中，求解器的功能性能和可靠性当然占一部分，但其实对于应用人员来说，前后处理的便捷程度所占的比例似乎更大。不是有人统计过吗，在CFD应用过程中，前后处理时间占了八成以上。当求解器没有做到一骑独尘（事实上这年头想做到一骑独尘是不可能的，除非你有革命性的算法，比如当年从结构网格求解器切换到非结构网格求解器），是很难在工程应用中依靠求解器左右市场份额的，左右市场份额的通常是前后处理与该行业的契合程度。

除了软件本身，软件文档在很大程度上决定了软件的普及程度。反观目前国内那些自主开发的CFD软件，有几个是文档齐全的？文档是软件的说明书，容不得半点差错。理论文档、用户操作文档以及案例文档，都是软件很重要的宣传工具。近年来试用了不少国产CFD软件，大多文档残缺，有个别的软件文档中还有错误（某国产CFD软件的理论文档中，连NS公式都抄错！），这让人家怎么敢用呢？前后处理有BUG问题不大也容易修复，但如果求解器有明显BUG，用户多半直接会对求解器的可靠性丧失信心，而这种软件可靠性信心的建立是极为困难的。你写了几大本的验证文档，也难以建立起这种信心，但只要一个小bug就可以将这种信心毁于一旦。

说到文档，那就不能不提软件的验证了。试问这些国产CFD软件做过验证么？如果做过，为什么没见过验证文档呢？（反正这几年测试使用了不下十款国产CFD软件，从没见过什么验证文档）。验证文档是建立用户信心的最有力的工具，这玩意儿都没有，让别人怎么放心使用你的软件，万一算出个1+1=3怎么办。

懒得去提自己开发求解器了，国产CFD求解器，10年以内不会有成熟的商业可用的产品出来，我说的是那种真正从底层造轮子的求解器，不是在开源的基础上缝缝补补又不遵守人家的协议而将其据为己有的那种求解器，当然我并不反对在开源的基础上做一些缝补工作，但好歹要遵守规则吧。

再聊聊围绕开源求解器开发前后处理工具。这是一个不错的选择，首先开源求解器只是没有版权，但代码是可控的，也方便功能增添和修改。前后处理影响工作效率，基于行业深度开发前后处理，将开源求解器包装成专业软件，要比开发那种通用CFD软件更有生存空间，实际上各行业也很缺这种专业软件。

但了解前后开发的人也都知道，前后处理的开发难度一点儿也不必求解器开发低，前处理几何和网格以及大量求解参数的输入，后处理数据的可视化，想要开发一个让使用者操作舒心的前后处理器也挺不容易的。目前很多国产CFD求解器前后处理大量的使用开源库，当然也没什么大的问题，但是开源的前后处理库效率基本都不高，大模型弄进去卡得要死要活的 ，还有就是操作起来也非常僵硬，当然这些可以慢慢改进。要说的是，很多国产CFD软件自己前后处理功能不行，还不愿意提供通用接口导入其他软件输出的格式，如果能够提供接口，事实上也是给自己留了一条路嘛。也许他们觉得自己开发的前后处理器，如果用户不用岂不是很丢脸，但是我想说的是，给用户多一点选择，也是给自己多一条后路。

国产CFD软件其实最缺的是商业模式，按常规软件的那种卖软件的模式很难活下去，那些老牌的商业CFD软件不会给你生存空间。也许软件上云提供服务是一种比较好的模式，这也说不好，也许未来随着网络和计算机技术的发展，会有更好的商业模式诞生。

扯多了，期待在中国足球站在世界之巅的时候，也能够看到国产CFD软件傲视群雄。以上内容纯属扯蛋，各位道友笑笑就好，非喜勿喷！