1. 大型模型求解加速导论
当 Ansys Mechanical 模型规模从几十万自由度增长到数千万甚至上亿自由度时，求解时间往往从几分钟膨胀到数小时乃至数天。此时单纯“换一台更快的机器”通常收效有限，因为真正的瓶颈可能藏在网格规模、接触定义、求解器类型、磁盘 I/O 或内存带宽中的任意一环。本章的目标不是立刻调参，而是建立一套可复用的判断框架：先识别瓶颈，再定义加速目标，最后把硬件与软件手段组合成协同优化方案。
一、求解流程的四个阶段与瓶颈分布
Ansys Mechanical 的一次完整求解，可以拆成四个阶段：前处理与模型装配、方程组装、数值求解、结果写出与后处理。大型模型的耗时分布与中小模型差异极大，必须分阶段观察。
- 前处理与装配：读取网格、建立接触对、生成约束方程。接触对数量多时，这一阶段可能占用总时间的 10%～25%。
- 方程组装：形成刚度矩阵并施加边界条件。稀疏矩阵的非零元数量直接决定内存占用。
- 数值求解：直接求解器（Sparse）以分解为主，迭代求解器（PCG）以矩阵向量乘为主。这是通常占比最大的阶段。
- 结果写出：把位移、应力写入 .rst 文件。若每步都写大量结果，磁盘写入会成为隐藏瓶颈。
判断瓶颈最直接的方法是查看求解输出文件（solve.out）中的时间统计，以及 Solution Information 里的求解器日志。下面这张图给出了从模型输入到加速决策的完整判断链路，可作为后续所有优化工作的参照。
二、瓶颈识别的具体做法
不要凭感觉判断瓶颈。建议按以下顺序采集证据：
- 在 Solution 分支下插入 Solution Information，把
Display设为All，求解后查看各阶段耗时。 - 打开求解器输出文件
file.solve.out，搜索ELEMENT ASSEMBLY、SOLVE、WRITE等关键字对应的时间行。 - 用任务管理器或
nvidia-smi观察求解期间的内存占用、CPU 利用率与 GPU 利用率。若 CPU 长期低于 60%，说明存在 I/O 或串行等待。 - 记录 .rst 文件大小与写盘耗时。若单步结果文件超过 5 GB，应优先考虑减少输出项。
一个典型示例：某装配体模型约 1200 万节点，接触对 480 个。首次求解总耗时约 6.5 小时，其中装配 1.2 h、组装 0.4 h、求解 4.3 h、写出 0.6 h。求解阶段占比 66%，是首要优化对象；装配阶段占比 18%，也值得处理。这个分布说明：只增加 CPU 核数对装配阶段几乎无效，必须同时精简接触定义。
三、加速目标的量化定义
“让求解更快”不是目标。可执行的目标必须包含三个要素：当前基线、目标值、可接受的精度边界。例如：
| 指标 | 当前基线 | 目标值 | 约束条件 |
|---|---|---|---|
| 总求解时间 | 6.5 h | ≤ 2.0 h | 位移结果偏差 ≤ 2% |
| 峰值内存 | 186 GB | ≤ 256 GB | 不触发磁盘交换 |
| 接触对数量 | 480 | ≤ 200 | 接触压力分布趋势一致 |
| 结果文件大小 | 42 GB | ≤ 15 GB | 关键工况结果完整 |
注意精度边界必须事先约定。若为了加速把直接求解器换成迭代求解器，位移场可能出现 1%～3% 的差异，这在大变形或接触非线性问题中需要谨慎评估。
四、硬件与软件协同优化框架
硬件与软件不是独立的两条线，而是相互制约的。核心原则有三条：
- 内存优先于核数：直接求解器的内存需求约为矩阵非零元的数倍。内存不足时，系统会使用页面文件，速度可能下降 10 倍以上。经验上，内存容量应不低于预估峰值的 1.5 倍。
- 求解器类型决定硬件侧重：Sparse 直接求解器对内存带宽和主频敏感，核数超过一定数量后并行效率下降；PCG 迭代求解器更容易扩展到多核，但收敛性依赖预条件子质量。
- I/O 路径不能忽视：把求解暂存目录、结果目录放在 NVMe SSD 上，通常能缩短 10%～20% 的总时间，尤其是结果写出频繁的瞬态分析。
五、一个可复用的加速检查清单
在进入后续章节的具体技术之前，可以先按下面这份清单完成初步诊断。它不替代深入分析，但能快速排除明显问题。
大型模型求解加速初步检查清单
────────────────────────────────
[ ] 已记录四阶段耗时基线（装配/组装/求解/写出）
[ ] 已确认峰值内存是否超过物理内存
[ ] 已确认求解器类型（Sparse / PCG / 混合）
[ ] 已统计接触对数量与类型（绑定/摩擦/无摩擦）
[ ] 已检查结果输出频率与输出项数量
[ ] 已确认暂存盘与结果盘是否为 SSD
[ ] 已定义加速目标值与精度边界
[ ] 已准备缩小版模型用于快速验证