2. HyperMesh模型文件结构解析

在开始讨论版本管理之前,必须先回答一个基础问题:我们到底在管理什么?很多团队在实施版本管理时,把注意力放在“命名规则”和“文件夹结构”上,却忽略了 HyperMesh 模型本身是由多种文件共同构成的集合。如果连版本管理对象都没有界定清楚,后续的签入、签出、比对、回滚都会失去意义。本节从文件结构入手,逐层拆解 .hm、.h3d 以及各类关联文件,并说明它们之间的引用关系,帮助读者建立“版本管理对象”的完整认知。

一、.hm 文件:HyperMesh 的原生模型载体

.hm 是 HyperMesh 的原生二进制模型文件,也是绝大多数建模工作的主文件。它保存的内容非常广泛,包括几何(Geometry)、网格(Mesh)、单元与节点、材料与属性(Collectors)、载荷与边界条件(Loads/BCs)、工况(Load Steps)、以及用户自定义的集合、注释和视图状态。可以理解为:.hm 文件是“模型数据库”的完整快照。

正因为 .hm 保存的内容多,它的版本管理也最复杂。一次看似微小的操作——例如把某个 component 的单元类型从 CQUAD4 改为 CTRIA3,或者调整一个材料卡片中的弹性模量——都会改变 .hm 文件的内容。因此,.hm 文件是版本管理中最核心、最需要被追踪的对象。在实际项目中,建议将 .hm 文件视为“不可变快照”:每次提交版本时生成一个新文件或新版本号,而不是在原文件上反复覆盖。

需要注意的是,.hm 文件是二进制格式,无法直接用文本比对工具查看差异。这意味着版本管理不能依赖“看文件内容”,而必须依赖版本号、提交说明、时间戳以及配套的元数据记录。这一点直接决定了后续版本管理策略的设计方向。

二、.h3d 文件:面向结果与可视化的轻量化格式

.h3d 是 HyperMesh/HyperView 体系中的 HDF5 格式文件,常用于存储仿真结果、模型可视化数据以及轻量化的模型快照。与 .hm 不同,.h3d 更偏向“结果与展示”用途:它可以包含网格、结果云图、动画帧、以及部分模型信息,但通常不包含完整的建模操作历史。

在版本管理语境下,.h3d 的定位是派生产物。它往往由 .hm 模型经过求解或后处理生成,因此它的版本应当与源 .hm 版本建立对应关系。例如,当 .hm 模型从 V3 更新到 V4 后,对应的 .h3d 结果文件也应重新生成并标记为 V4,而不是继续沿用 V3 的结果。如果团队把 .h3d 当作独立对象管理,就容易出现“模型已更新、结果还是旧版”的错配问题。

三、关联文件:被引用但不显眼的对象

一个完整的 HyperMesh 模型往往不是孤立存在的。它可能引用以下类型的关联文件:

  • 几何文件:如 .step、.iges、.stl、.parasolid 等,作为建模的输入几何源。
  • 求解器输入文件:如 .fem、.rad、.inp、.bdf 等,由 HyperMesh 导出给 OptiStruct、RADIOSS、Abaqus、Nastran 等求解器。
  • 结果文件:如 .h3d、.op2、.rst、.odb 等,由求解器生成,供后处理使用。
  • 脚本与宏文件:如 .tcl、.py,用于自动化建模或批处理。
  • 配置文件:如 .hmx、.cfg,保存界面布局、快捷键、用户偏好等。

这些关联文件的特点是:它们通常不被直接打开编辑,但一旦缺失或版本不匹配,模型就无法正确重建或复现。例如,如果 .hm 中引用了某个 .step 几何,而该几何文件被替换成了新版本,那么即使 .hm 文件本身没有变化,模型的实际几何基础也已经改变。因此,关联文件必须与主模型一起纳入版本管理范围,至少要做到“版本对应关系可追溯”。

四、引用关系:理解版本传播链

把上述对象放在一起,就形成了一条清晰的引用链:几何文件 → .hm 模型 → 求解器输入文件 → 结果文件(.h3d 等)。这条链上的每一个环节都可能发生版本变化,而版本变化会沿着引用方向传播。理解这条链,是设计版本管理策略的关键。

HyperMesh 模型文件引用链与版本传播关系 几何文件 .step / .iges / .stl .hm 主模型 几何+网格+材料+载荷 +工况+集合+视图 求解器输入文件 .fem / .rad / .inp / .bdf 结果文件 .h3d / .op2 / .rst 引用 导出 求解生成 版本传播方向:上游变更 → 下游必须同步更新 几何 V2 → .hm V2 → 求解输入 V2 → 结果 V2(若任一环节未同步,则版本链断裂) 脚本与宏文件 .tcl / .py 影响建模过程可复现性 配置文件 .hmx / .cfg 影响界面与用户偏好 版本管理对象范围 .hm + .h3d + 关联文件 + 引用关系记录

图中展示了从几何文件到结果文件的完整引用链,以及版本传播的方向。需要特别强调的是:版本管理不是只管理 .hm 文件,而是管理整条引用链上的对象及其对应关系。如果只对 .hm 做版本控制,而忽略了几何文件、求解器输入文件和结果文件的版本对应,那么在需要复现某个历史状态时,就会出现“模型能打开、结果对不上”的尴尬局面。

五、版本管理对象的界定原则

基于以上分析,可以归纳出三条界定原则:

  1. 主模型优先:.hm 文件是版本管理的核心对象,每次有意义的建模变更都应产生新的版本记录。
  2. 派生对象跟随:.h3d、求解器输入文件等派生对象,其版本号应与源 .hm 版本建立映射关系,不独立编号。
  3. 引用关系可追溯:几何文件、脚本、配置文件等关联对象,至少应记录“哪个版本的 .hm 引用了哪个版本的关联文件”,形成可查询的引用台账。
在实际操作中,可以用一个简单的引用台账来记录版本对应关系。例如:模型名称 HM-Bracket,.hm 版本 V3,引用几何 Bracket.step V2,导出求解输入 Bracket_V3.fem,生成结果 Bracket_V3.h3d。这样即使半年后需要复现 V3 状态,也能快速定位到所有相关文件。

六、常见误区与注意事项

第一个常见误区是“只备份 .hm 文件”。很多工程师习惯把 .hm 复制到备份文件夹就算完成版本管理,但几何文件、脚本和求解器输入文件仍然散落在各处,导致复现困难。第二个误区是“用文件名代替版本号”,例如 model_final.hm、model_final_v2.hm、model_final_真正最终.hm,这种命名方式在多人协作中极易混乱。第三个误区是“忽略 .h3d 与 .hm 的对应关系”,把结果文件当作独立成果管理,造成模型与结果脱节。

.hm 文件是二进制格式,无法通过文本比对查看差异。因此,版本管理必须依赖提交说明、时间戳和元数据记录。建议每次提交版本时,用一句话说明“改了什么、为什么改”,例如“V3:将前防撞梁单元尺寸从 5mm 细化到 3mm,用于碰撞工况”。这条说明的价值远高于文件本身的大小或修改时间。

理解文件结构与引用关系,是后续制定版本命名规范、设计签入签出流程、搭建版本库目录结构的前提。只有先明确“管理对象是什么”,才能进一步回答“怎么管、谁来管、何时管”的问题。