10.2 自动化与脚本

10.2 自动化与脚本

后处理讲的是判断力，本节讲的是执行力：把验证过的流程交给机器，让工程师的时间花在判断上。Fluent 的自动化入口有两条主线——TUI 日志与执行脚本（journal）驱动求解器本体的批处理，以及平台侧的脚本接口（如 PyFluent）把 Fluent 嵌进更大的工作流。本节给出可落地的会话模板、参数扫描的组织方法与无人值守的值班纪律。

Journal：求解器的操作回放带

Fluent 图形界面里的每个操作几乎都对应一条 TUI 命令，把这些命令按顺序写进 journal 文件，就得到一条可重复执行的"操作回放带"。它的三个高价值场景：批量计算（同模型多工况，循环改边界条件、初始化、迭代、导出结果）、流程固化（第九章的监测定义、报告定义写进 journal，新项目开箱即带全套哨兵）、环境迁移（脚本在不同机器上产生完全一致的计算流程，验收单里"可复现"一栏的直接证据）。

录制 journal 的正确姿势是"先手动走一遍、再录制、后清洗"：图形界面开着 journal 录制完成一次完整流程，然后用文本编辑清洗掉探索期的废动作，加上注释与参数变量，存入项目模板库。下面是一条参数扫描 journal 的骨架（示意）：

; read base case and data
/file/read-case-data fan-base
; loop over operating points
/tui-define-macro sweep
  /define/boundary-conditions/zone-type outlet outflow
  /define/boundary-conditions/pressure-outlet outlet
    gauge-pressure  <<value>>
  /solve/initialize/hybrid-initialization
  /solve/iterate 800
  /report/fluxes/mass-flow yes
  /file/write-case-data fan-<<value>>
​

骨架的价值不在命令本身（版本与模型不同命令有差异），而在结构：读基准、改参数、初始化、迭代、核对通量、存盘、循环。每一步都对应第九章的一个验收动作——自动化脚本就是把验收纪律写进流程，而不是把流程跑得更快而已。

PyFluent 与平台级编排

当流程跨出求解器（网格生成、求解、后处理、报告生成要串联），平台侧脚本接口接手：用 Python 驱动 Fluent 启动、加载、执行 journal、回收结果，与几何批处理和报告工具拼成完整流水线。工程组织的典型形态是"三段式"：参数表（一个表格或配置文件定义所有工况）加调度脚本（读表、分发任务、监控状态）加结果聚合（自动汇总特征量表、生成报告初稿）。这让仿真组的服务能力从"排队等一位工程师"变成"流水线并行处理"，第十一章的集群资源管理正是在这条流水线的末端接手。

无人值守的值班纪律

夜间批量计算最怕两种事故：任务中途崩溃留下一堆半成品，以及"跑完了但结果全错"。值班纪律五条：其一，每个任务入口先跑第九章的三重签字检查，不达标自动标记失败而不是继续后续工况；其二，任务间用检查点接力（读写 data 文件），崩溃后从断点续跑而不是从头来；其三，磁盘水位监控——大规模批算最常见的死因是磁盘写满；其四，日志分级归档，stdout 与错误分开存；其五，晨检脚本汇总一夜任务的状态表，异常任务置顶。自动化不是按下回车去睡觉，而是把值守变成制度。

图 10-2：参数扫描无人值守流水线

案例：换热器折中曲线的一夜生成

背景。某板翅式换热器设计，需要在流量与翅片密度两个维度上各取四个水平做折中曲线（压降对换热量的权衡），手工逐个跑预估两周，工期只剩三天。

操作。把网格生成做成参数化模板（翅片密度作为参数驱动），求解流程固化为 journal（含第九章全套监测与通量检查判据），调度脚本按参数表生成十六个任务分发给八核工作站双路排队，晨检脚本汇总特征量表。

结果。首夜完成十一个任务，三个因网格生成参数冲突失败——晨检表置顶显示失败原因（两个翅片密度下最小间隙小于三倍网格尺寸），修正参数后第二夜补齐。第三天上午折中曲线与最优工作点已进入方案评审，全程人工干预合计约四小时。

解读。案例的真正产出不是十六个结果，而是一条可复用的产线：下个换热器项目只需换参数表。失败的三例也印证了值班纪律的价值——失败被自动识别、原因被记录、现场被保留，晨间的修复是定向的而不是考古式的。

变式。与优化算法对接时，调度脚本把特征量表回喂给优化器形成闭环，验收判据（GCI、通量平衡）必须前置进闭环，否则优化器会精准地收敛到错误的极值；多物理场耦合流程（结构与流体交替）用联合调度脚本管理数据交换与收敛判定。

脚本化问答与成熟度对照

journal 报错就停还是继续。批处理模式默认报错即停——这是特性不是缺陷：带病任务继续跑只会生产更多废结果。需要"尽力而为"的场景在调度层做异常分支，而不是在求解器层关掉保护。

脚本要不要写注释与版本号。脚本即代码，按代码管理：头部注释写明用途、适配版本、关键参数含义；改动存版本，回滚才有退路。模板库里的脚本没有注释，等于定时炸弹。

什么时候值得自动化。判断式：同一流程预计重复三次以上、单次耗时超过半小时、或出错代价高——三者任居其二就值得投入。自动化是有成本的工程，不是信仰。

脚本成熟度四级对照：

本节验收点

• 重复流程已 journal 化或脚本化，模板入库可复用。
• 自动化流程内嵌验收判据，失败自动识别且保留现场。
• 无人值守执行了五条值班纪律，晨检表成为每日例会素材。
• 脚本在另一台机器上复跑过一次，结果可复现性得到验证。