最近在处理一个比较典型、但又有点小众的 CAE 问题。
项目中需要把供应商模流软件导出的数据继续用于结构分析。数据里不仅有材料相关信息,比如玻纤方向、方向模量等,也包含成型过程遗留下来的初始应力。
按理说,这类工作是有官方转换接口的。它可以把模流结果转换成后续结构分析软件可以识别的输入文件。
但真正用的时候才发现:这类转换通常需要额外寻找和购买插件。
这个接口本身很小众,很多公司在购买软件的时候,可能根本不会意识到后面还需要单独购买这样一个转换工具。于是问题就变成了:
如果没有官方接口,能不能根据帮助文档里的例子,自己实现一部分转换功能?
正好最近 AI 辅助写代码已经比较成熟,所以这次做了一个小实验:借助 AI,尝试自己写一个 Moldflow 数据转换脚本。
表面上看,这件事好像只是“格式转换”。
Moldflow 输出一个文件,结构分析软件需要另一个输入文件,把数据读进去就好了。
但实际做下来会发现,它不是简单地把 XML 里的数字复 制到求解文件里。里面至少有两个关键问题:
• 单元类型转换:Moldflow 的网格单元需要转换成后续分析希望使用的单元形式。
• 坐标系转换:Moldflow 输出的应力和玻纤方向在整体坐标系下,而初始应力需要进入局部材料坐标系。
第一个问题决定了网格能不能正确读入和计算。
第二个问题决定了导入后的初始场是否有物理意义。
所以这个脚本的核心并不是“把文件后缀换一下”,而是把 Moldflow 结果中的网格、纤维方向和初始应力,转换成后续结构分析真正能用的数据。
Moldflow 默认输出的实体单元可以理解为低阶四面体单元,例如 C3D4。而在后续分析中,我们希望使用高阶四面体单元,例如 C3D10。
C3D4 只有四个角点。
C3D10 除了四个角点以外,还需要六个边中点。
所以程序需要根据原来的四面体顶点,自动生成中间节点,并把这些节点写入新的网格。
这里有一个很容易忽略的细节:同一条边可能被多个单元共享。
如果每个单元都各自生成自己的中间节点,相邻单元之间就会出现节点不连续。正确做法是对边进行统一管理:同一对端点对应同一个中间节点。
此外,节点编号顺序也必须满足高阶四面体单元的要求。如果编号顺序不合适,单元雅可比可能为负,求解时会直接报错,或者得到不可用的网格。
这部分看起来像一个“网格小功能”,但它实际上是整个转换能不能跑起来的基础。
Moldflow 输出的 XML 文件中,应力和玻纤方向通常是按照整体坐标系定义的。也就是说,文件里的应力分量和方向向量,都是相对于全局坐标系描述的。
但在定义初始应力时,很多情况下需要的是局部材料坐标系下的应力。
尤其是含玻纤增强材料时,材料行为往往和纤维方向强相关。对于每个单元来说,纤维方向可以定义一个局部坐标系,初始应力也需要从全局坐标系转换到这个局部坐标系下。
可以简单理解为:
Moldflow 告诉我们:这个单元在全局 XYZ 方向下的应力是多少,以及纤维大致朝哪个方向。求解文件需要的是:沿着纤维方向、垂直纤维方向等局部材料方向下的初始应力是多少。
这一步的本质是张量坐标变换。

Moldflow 输出中每个单元在全局坐标系下的应力信息

求解文件中,初始应力需要进入纤维局部坐标系
这次脚本主要围绕两个目标展开。

脚本转换流程图
第一部分是网格转换:
• 读取 Moldflow 导出的节点和单元信息;
• 将低阶四面体单元转换成高阶四面体单元;
• 为每条边生成共享的中间节点;
• 按 C3D10 节点顺序重新组织单元;
• 检查并避免负雅可比一类的节点顺序问题。
第二部分是结果场转换:
• 读取 Moldflow XML 中的应力和纤维方向;
• 基于纤维方向构造局部材料坐标系;
• 将全局坐标系下的应力张量转换到局部坐标系;
• 按求解文件所需格式写入初始应力信息。
这里面 AI 主要帮忙处理的是代码实现、格式解析和反复调试。
真正需要 CAE 工程师判断的地方,仍然是工程含义本身:什么是正确的局部坐标系,为什么应力要做张量变换,单元节点顺序为什么会影响雅可比。
为了确认脚本不是“看起来能跑”,我参考了帮助文档中的示例结果进行对比。
对比内容主要包括两类:
• 脚本转换后生成的文件结果;
• 帮助文档中直接运行官方示例得到的结果。
从目前这个示例看,脚本生成的结果和帮助文件示例在主要数据结构和关键结果上可以对应起来。

脚本转换结果与帮助文档示例结果并列对比
这说明至少在这个示例范围内,自研脚本可以复现官方接口的一部分核心能力。
当然,这不等于它已经完全替代官方接口。官方接口可能还处理了更多边界情况,例如不同软件版本的数据格式、更多单元类型、更复杂的材料模型、壳单元或多层结构数据等。
但对于当前这个需求来说,已经验证了一个重要判断:
只要问题边界足够清楚,AI 辅助工程师写一个小众 CAE 数据转换工具,是有可能落地的。
这次比较有意思的一点是,AI 并不是替代 CAE 工程师去“理解物理”。
它真正有价值的地方,是帮助把工程师脑子里的转换逻辑快速变成代码。
比如这些工作:
• 解析 Moldflow 输出的 XML 文件;
• 组织求解文件格式;
• 生成高阶四面体中间节点;
• 检查和调整单元节点顺序;
• 编写坐标系转换和应力张量转换函数;
• 根据帮助文档示例反复调试输出结果。
这些工作如果完全手写,当然也能做,但会比较琐碎,而且容易在格式细节上耗费时间。
AI 的作用更像是一个代码助手。它可以快速生成初版程序,也可以根据报错和结果对比不断修改。
但它不能替代工程判断。
工程原理由人把关,重复性代码和格式转换由 AI 加速。 这可能是目前 AI 在 CAE 工作流里比较现实的位置。
过去遇到这种小众接口问题,通常有几种选择。
一种是购买官方插件。
一种是找供应商重新导出数据。
一种是手工处理,或者放弃部分数据,只做简化分析。
但现在多了一个新的选择:在理解数据结构和物理含义的前提下,借助 AI 快速搭建一个定制转换工具。
这并不是说以后所有商业接口都不需要买了。官方工具的稳定性、兼容性和技术支持仍然有价值。
但对于一些边界清楚、频率不高、却会卡住项目流程的小工具,自研脚本的性价比会变得越来越高。
尤其是在 CAE 工作中,很多真正耗时间的并不是求解器本身,而是前后处理、数据转换、文件清洗、结果对比和报告生成。
这些环节都有机会被 AI 辅助脚本重新组织一遍。
这次 Moldflow 数据转换实验,核心并不是“写了一个多复杂的软件”。
它更像是一个信号:
CAE 工程师未来可能不只是点软件菜单、调参数、看云图,也会越来越多地把自己的工程判断封装成脚本、工具和流程。
AI 在这里的价值,不是替代工程师,而是降低了把工程知识工具化的门槛。
当没有可用的官方转换插件、标准流程走不通,当项目里出现一个很具体但没人愿意长期维护的小问题时,工程师可以更快地做出一个“够用、可验证、可迭代”的工具。
这可能就是 AI 对 CAE 工作方式最现实的改变之一。
不是一键完成仿真,而是让工程师更容易把自己的经验,变成可以重复使用的工程流程。