OpenFOAM二次开发教程（20）：收官——构建 OpenFOAM 二次开发工具链（完整项目）

OpenFOAM二次开发教程20收官——构建 OpenFOAM 二次开发工具链完整项目版本与事实声明插件安装到用户目录的约定来自官方插件仓库示例./Allwmake -prefixuser→$FOAM_USER_APPBIN、$FOAM_USER_LIBBINMake/options中sinclude $(GENERAL_RULES)/module-path-user。blockMesh/checkMesh流程见官方 QuickstartpostProcess见官方文档站foamlib来自 PyPI非 OpenFOAM 官方发布物。本项目为教学示范工程所有类名、目录、脚本结构展示应该如何组织涉及的 OpenFOAM 类/接口细节必须来自你本机版本源码铁律 1本文不给出任何未经核验的成员清单。文中数值、几何与参数均为示例不代表任何标准规定。一句话结论一个可交付的 OpenFOAM 二次开发工具链应分为五层——源码/插件层自定义求解器、湍流模型库、边界条件、函数对象、fvModel统一编译到$FOAM_USER_APPBIN/$FOAM_USER_LIBBIN并在libs加载、工作流层网格流水线 DOE 状态机、回归层网格门禁 与官方基准对拍、交付层文档、清单、版本绑定、治理层铁律与实体命名一致性其中回归层是让整套工具链可被信任的唯一保证。〇、本篇要解决的认知问题Q1一个完整的二次开发工具链应该有哪几层为什么全是脚本不算工具链Q2插件层求解器 四类扩展如何统一组织、统一编译、统一加载Q3工作流层如何把第 18、19 篇的流水线与状态机接起来Q4回归层做什么为什么它是整套工具链的地基Q5怎么把工具链交付给别人并让对方敢用交付清单应该有什么一、机制解析1.1 五层架构为什么需要一个工具链而不是一堆脚本前 19 篇你已经攒下了一整套零件自定义求解器07、湍流模型库10、自定义边界11、函数对象12、fvModel13、并行流程14、性能经验15、Python 编排16、结果聚合17、网格流水线18、DOE 状态机19。但它们散落在各处无法交付。一堆脚本与工具链的差别在于维度一堆脚本工具链结构文件散落命名随意分层清晰职责单一编译各自wmake产物去向不一统一Allwmake产物统一落用户目录加载手工往libs里加统一清单 自动校验验证“我这边能跑”回归测试覆盖任何人可复现交付口口相传文档 清单 版本绑定┌───────────────────────────────────────────────────────────────┐ │ ⑤ 治理层铁律清单 / 实体命名一致性 / 变更记录 │ ├───────────────────────────────────────────────────────────────┤ │ ④ 交付层README / 交付清单 / 版本与平台绑定 / 用法示例 │ ├───────────────────────────────────────────────────────────────┤ │ ③ 回归层网格质量门禁 与官方基准对拍 关键量断言 │ ├───────────────────────────────────────────────────────────────┤ │ ② 工作流层网格流水线18 DOE 状态机19 结果聚合17 │ ├───────────────────────────────────────────────────────────────┤ │ ① 插件层自定义求解器(07) 湍流库(10) 边界(11) FO(12) fvModel(13) │ ├───────────────────────────────────────────────────────────────┤ │ ⓪ 基础OpenFOAM 源码/工具Doxygen 查证铁律 1 环境02 │ └───────────────────────────────────────────────────────────────┘为什么这样分层它对应三类使用者——算法工程师改 ①自动化工程师改 ②质量工程师看 ③交付对象读 ④。分层让每类人只关心自己那一层这是工具链可维护的根本。1.2 插件层的统一组织三个统一插件层要把第 7、10、11、12、13 篇的五类扩展装在一起。关键在三个统一统一一统一目录结构devkit/plugins/ ├── solvers/myScalarTransportFoam/ # 第 07 篇 ├── turbulence/myKOmegaSST/ # 第 10 篇 ├── boundaries/myRampedInlet/ # 第 11 篇 ├── functionObjects/myStatFO/ # 第 12 篇 └── fvModels/myHeatSource/ # 第 13 篇统一二统一产物落位——全部进用户目录铁律 4类型产物声明落位求解器可执行EXE $(FOAM_USER_APPBIN)/名字$FOAM_USER_APPBIN库湍流/边界/FO/fvModelLIB $(FOAM_USER_LIBBIN)/lib名字$FOAM_USER_LIBBIN统一三统一加载清单——所有库集中在controlDict的libs铁律 5libs ( libmyKOmegaSST.so libmyRampedInlet.so libmyStatFO.so libmyHeatSource.so );最佳实践把这份清单做成模板文件 校验脚本检查清单中的库是否真的存在于$FOAM_USER_LIBBIN。库名写错是最常见的事故脚本一查就现形。1.3 工作流层把流水线与状态机串起来工作流层是第 18、19 篇的合流。核心是一条幂等的、可续跑的、留痕的执行链DOE 样本第 19 篇 │ ┌────▼─────────────────────────────────────────┐ │ 每个样本独立目录 状态账本 │ │ ├─ 克隆模板算例 │ │ ├─ 改参回读校验第 04/16/19 篇 │ │ ├─ 网格流水线第 18 篇 质量门禁 │ │ ├─ 并行/串行运行第 14 篇 │ │ ├─ 收敛判定第 19 篇 │ │ └─ 状态落盘pending/running/converged/failed│ └────┬─────────────────────────────────────────┘ │ 聚合第 17 篇→ 报表含剔除披露第 19 篇三条贯穿始终的纪律幂等可安全重跑、留痕每步日志落盘、可复现参数快照 固定随机种子 版本绑定。1.4 回归层整套工具链的地基为什么回归层最重要二次开发最危险的失败模式是**“静默错误”**——算完了、没报错、结果错了。回归层就是专门对抗它的。回归测试的四个层次层次测什么方法判据L1 编译回归所有插件能否编译Allwmake退出码 0 产物存在L2 网格回归网格是否合格checkMesh第 18 篇Mesh OK 关键指标阈值L3 对拍回归未做实质改动时行为是否与基准一致与官方模型/基准算例同设置对拍第 09、10 篇监测量相对差异在容差内L4 数值断言物理量是否在合理范围与解析解、文献值或既有结果比较相对误差阈值L3 最有价值每改一次代码都应能回答与改之前、与官方实现比差多少、为什么。铁律 7 的最终形态任何提交都必须通过 L1~L3L4 视项目要求而定。这就是把改完必验从习惯升级为制度。1.5 交付层与治理层让别人敢用交付清单建议包含README一句话定位、五层结构图、安装步骤、快速上手示例版本与平台绑定OpenFOAM 版本线与WM_OPTIONS平台——扩展库与二者强绑定第 02、10 篇插件清单 libs片段每个插件的类型名type与对应库名改动清单相对官方实现改了什么、为什么第 10 篇回归测试说明与最近一次结果让使用者能自己复跑验证已知限制哪些场景与版本未验证诚实边界比夸大能力更能赢得信任。治理层两个检查实体命名一致性全项目对类名、命令名、字典键的写法统一且与官方一致第 01~19 篇贯穿铁律清单把全系列 8 条铁律作为项目的代码评审检查表逐条对照。二、完整代码与逐行剖析代码 2-1openfoam_devkit目录结构完整项目骨架openfoam_devkit/ ├── README.md # 交付层定位/结构/安装/快速上手 ├── version.lock # 版本与平台绑定版本线 WM_OPTIONS ├── CHANGELOG.md # 治理层变更记录 ├── docs/ │ ├── 铁律清单.md # 治理层评审检查表 │ ├── 实体命名规范.md # 治理层类名/命令/键名统一写法 │ └── 改动清单.md # 每个插件的改动与理由 ├── plugins/ # ① 插件层 │ ├── Allwmake # 一键编译全部插件统一落用户目录 │ ├── solvers/myScalarTransportFoam/{*.C,createFields.H,Make/{files,options}} │ ├── turbulence/myKOmegaSST/{*.H,*.C,Make/{files,options}} │ ├── boundaries/myRampedInlet/{*.H,*.C,Make/{files,options}} │ ├── functionObjects/myStatFO/{*.H,*.C,Make/{files,options}} │ └── fvModels/myHeatSource/{*.H,*.C,Make/{files,options}} ├── templates/ │ └── case_template/ # ② 工作流层用的模板算例0/ constant/ system/ │ └── system/ │ ├── controlDict # 含 libs 清单统一加载 │ ├── fvSchemes │ ├── fvSolution │ └── functions # 或写在 controlDict 的 functions 块第 12 篇 ├── workflow/ # ② 工作流层 │ ├── design.json # 契约表变量/目标/判据第 19 篇 │ ├── make_blockmesh.py # 参数化网格第 18 篇 │ ├── mesh_pipeline.sh # 网格流水线 质量门禁第 18 篇 │ ├── doe_design.py # 抽样 状态账本第 19 篇 │ ├── doe_run.py # 状态机执行器第 19 篇 │ ├── aggregate.py # 结果聚合第 17 篇 │ └── report.py # 报表含剔除披露第 19 篇 ├── tests/ # ③ 回归层 │ ├── l1_build.sh # 编译回归 │ ├── l2_mesh.sh # 网格回归门禁 │ ├── l3_crosscheck.sh # 对拍回归vs 官方基准 │ ├── l4_assert.py # 数值断言 │ └── baseline/ # 基准结果快照只读供对比 └── ci/ └── run_all.sh # 一键跑 L1~L3供 CI 调用逐行剖析结构层面的设计说明version.lock单列版本与平台绑定必须显式化。扩展库与 OpenFOAM 版本、WM_OPTIONS平台强绑定第 02、10 篇把这两个信息写进一个文件并在 README 里引用能避免在另一台机器上编译不了这类最常见的问题。plugins/Allwmake一键编译官方插件仓库的习惯做法./Allwmake -prefixuser。统一入口是工具链的标志。templates/case_template/system/controlDict里含libs清单模板把统一加载固化铁律 5使用者不会忘。tests/baseline/只读基准快照对拍需要基准这个锚点。把基准结果存进仓库只读才能回答这次改动让结果变了多少。ci/run_all.sh单入口CI 只需调用一个脚本降低集成成本。docs/铁律清单.md与实体命名规范.md把全系列的治理纪律文档化、可评审化——这是从个人经验走向团队资产的关键。代码 2-2plugins/Allwmake统一编译产物统一落位#!/bin/sh# plugins/Allwmake —— 一键编译 devkit 全部插件# 约定所有产物落 $FOAM_USER_APPBIN / $FOAM_USER_LIBBIN铁律 4# 用法sh Allwmake 编译全部# sh Allwmake -prefixuser官方插件仓库的等价做法set-euROOT$(cd $(dirname$0)pwd) fail0 build_one () { #$1目录$2类型说明仅用于日志 d$1; kind$2 [ -d $d ] || { echo [SKIP]$d不存在; return 0; } echo 编译[$kind]$d ( cd $d wmake ) || { echo [FAIL]$d; fail1; } } # ---- 求解器可执行文件EXE $(FOAM_USER_APPBIN)/...---- for d in $ROOT/solvers/*/; do [ -d $d ] build_one $d solver done # ---- 库tur/boundary/FO/fvModelLIB $(FOAM_USER_LIBBIN)/...---- # 说明这些目录的 Make/files 使用 LIB 声明因此用 wmake libso。 for grp in turbulence boundaries functionObjects fvModels; do for d in $ROOT/$grp/*/; do [ -d $d ] || continue echo 编译[$grp]$d ( cd $d wmake libso ) || { echo [FAIL]$d; fail1; } done done echo echo 产物核对铁律4 echo FOAM_USER_APPBIN${FOAM_USER_APPBIN:-未设置} echo FOAM_USER_LIBBIN${FOAM_USER_LIBBIN:-未设置} ls -1 ${FOAM_USER_APPBIN:-/nonexistent} 2/dev/null | grep -i my | sed s/^/ app: / || true ls -1 ${FOAM_USER_LIBBIN:-/nonexistent} 2/dev/null | grep -i my | sed s/^/ lib: / || true [ $fail -eq 0 ] echo [OK]全部插件编译通过。 || { echo [FAIL]存在编译失败项。;exit1;}逐行剖析求解器用wmake、库用wmake libso对应两类Make变量组EXE_*与LIB_*第 02、10 篇的坑在这里被统一处理。逐目录编译并累计失败标志fail编译到第一个失败就退出会让人反复跑很多遍一次跑完并汇总更有用。但最终仍以非零退出码结束供 CI 判定。末尾列出用户目录里的my*产物产物去哪了必须可见铁律 4 的自动化核对。变量为空时用未设置//nonexistent兜底环境没 source 时给出可读提示而非莫名报错第 02 篇的风格。代码 2-3ci/run_all.sh回归门禁L1~L3#!/bin/sh# ci/run_all.sh —— 回归门禁编译 → 网格 → 对拍供 CI 调用# 用法sh ci/run_all.sh 基准算例路径 官方type 自定义typeset-euROOT$(cd $(dirname$0)/..pwd) BASE_CASE${1:?用法:sh ci/run_all.sh 基准算例 官方type 自定义type} OFFICIAL_TYPE${2:?缺少官方类型名如 kOmegaSST} CUSTOM_TYPE${3:?缺少自定义类型名如 myKOmegaSST} echo ############ L1 编译回归 ############sh$ROOT/plugins/Allwmake||{echoL1 FAIL;exit1;}echoL1 PASSecho############ L2 网格回归质量门禁############tmp$(mktemp-d)cp-r$BASE_CASE$tmp/case(cd$tmp/casesh$ROOT/workflow/mesh_pipeline.sh./dev/null21)\||{echoL2 FAIL网格或质量门禁未通过见$tmp/case/log.checkMesh;exit1;}echoL2 PASSecho############ L3 对拍回归vs 官方基准############# 思路第 09、10 篇同一算例、同一套 fvSchemes/fvSolution# 分别用官方 type 与自定义 type 运行比较一个可观测量的相对差异。run_with_type(){tname$1;tag$2d$tmp/case_$tagcp-r$BASE_CASE$d# 切换模型类型字典路径按你的版本探测第 10、19 篇同款写法forfin$d/constant/momentumTransport$d/constant/turbulenceProperties;do[-f$f]{foamDictionary-entryRAS.type-set$tname$f||true;break;}done(cd$dblockMesh/dev/null21simpleFoamlog.solver21)||true# 抽取一个可观测量示例日志中的某个残差/迭代行数实际项目建议用 probes 输出第 12 篇grep-ESolving for Ux$d/log.solver|tail-n1|seds/^/ /||true}run_with_type$OFFICIAL_TYPEofficialrun_with_type$CUSTOM_TYPEcustomechoL3 提示请比较上面两组可观测量。若自定义模型为‘无实质改动的复制’echo 两者相对差异应在约定容差内工程常取 1%~5%按问题自定echo 超出容差必须能由改动解释否则视为回归失败第 10 篇。echoecho[OK] 回归门禁执行完毕L1/L2 为硬门禁L3 需人工核对容差。rm-rf$tmp逐行剖析L1 直接调用plugins/Allwmake回归层与插件层通过统一入口耦合而不是复制编译逻辑。L2 在临时目录里复制基准算例再跑网格门禁不污染任何既有算例第 03、18 篇纪律失败时给出log.checkMesh路径便于定位。L3 用同一算例 两种type做对拍这是第 09、10 篇对拍纪律的 CI 化。切换类型时探测字典文件名momentumTransport或turbulenceProperties——不同版本存在差异探测比硬编码稳第 10 篇同款处理。可观测量这里用日志行示例并明确建议实际项目改用probes输出做数值比较第 12、17 篇——示例给方法生产给标准。mktemp -d 结尾rm -rf临时工作区保证 CI 可重复运行且不留垃圾。L3 标注为需人工核对容差诚实地承认自动对拍需要正确配置容差与可观测量而不是假装能一键判定一切。代码 2-4version.lock与交付清单模板# version.lock —— 版本与平台绑定扩展库与二者强绑定见第 02、10 篇 # 请如实填写本文件是能不能在你机器上编译的第一依据。 openfoam_distribution OpenFOAM Foundation 版 # 或 OpenCFD/ESI 版 openfoam_version 如 14 或 v2606 wm_options 如 linux64GccDPInt32Opt compiler 如 gcc mpi 如 openmpi 或 system python 如 3.11 foamlib_version 以 PyPI 当前版为准 verified_on YYYY-MM-DD# README 交付清单模板 ## 1. 这个工具链是什么 一句话定位 五层结构图见正文 §一.1。 ## 2. 运行前提 - OpenFOAM 版本线与版本号见 version.lock - WM_OPTIONS 平台见 version.lock扩展库与平台强绑定换平台须重编 - Python 与依赖见 version.lock ## 3. 安装 sh plugins/Allwmake # 编译全部插件产物落 $FOAM_USER_APPBIN/$FOAM_USER_LIBBIN 在模板算例 controlDict 的 libs 中确认已列出全部库 ## 4. 快速上手 python workflow/doe_design.py workflow/design.json python workflow/doe_run.py workflow/design.json --max 4 python workflow/aggregate.py python workflow/report.py ## 5. 回归验证请自行复跑 sh ci/run_all.sh 基准算例 官方type 自定义type ## 6. 插件清单类型名 ↔ 库名 | 插件 | type字典中填写 | 库/可执行 | |---|---|---| | 湍流模型 | myKOmegaSST | libmyKOmegaSST.so | | 边界条件 | myRampedInlet | libmyRampedInlet.so | | 函数对象 | myStatFO | libmyStatFO.so | | fvModel | myHeatSource | libmyHeatSource.so | | 求解器 | —直接执行 | $(FOAM_USER_APPBIN)/myScalarTransportFoam | ## 7. 改动清单 见 docs/改动清单.md每个插件相对官方实现改了什么、为什么。 ## 8. 已知限制 - 未在 某版本/某平台 验证 - 某功能 在 某场景 下未测试 - 并行场景需自行为自定义部件做并行安全核对第 14 篇。逐行剖析version.lock把版本绑定结构化、可机器读取问题排查的第一步就是打开它第 02 篇的WM_OPTIONS一致性。交付清单第 3 步强调确认libs中已列出全部库把铁律 5 写进安装说明——使用者最容易忘的就是这一步。第 5 步请自行复跑回归交付不是相信我而是你可以自己验证。这是工程交付与给个压缩包的本质区别。第 6 步用**“type ↔ 库名对照表**使用者照着填字典就不会写错类型名第 08、10、11、12、13 篇的工厂机制决定了类型名与库必须匹配”。第 8 步已知限制诚实边界本系列从第 01 篇就坚持的态度。说清哪里没验证过比宣称什么都能做更能赢得信任。三、常见报错与排查报错 3-1CI 里 L1 编译失败但本地能过。现象本地Allwmake成功CI 上失败。根因CI 的 OpenFOAM 版本线或WM_OPTIONS与本地不同扩展库与二者强绑定或 CI 未 source OpenFOAM 环境。解法把version.lock作为 CI 的环境要求CI 脚本中显式 source 对应版本的环境用第 02 篇的foam_doctor.sh在 CI 开头做环境体检。报错 3-2L2 网格门禁失败但看起来网格没问题。现象checkMesh未报Mesh OK或关键指标超阈值。根因基准算例本身在 CI 环境下的网格参数分辨率/加密与预期不一致或renumberMesh/topoSet步骤改变了网格状态。解法以log.checkMesh的具体诊断行为准第 18 篇确认 CI 使用的是同一个模板算例与同一份参数快照mesh_params.json。报错 3-3L3 对拍差异巨大但代码只是复制改名。现象自定义模型与官方模型结果差异远超容差。根因常见有三——字典type未真正切到自定义foamDictionary静默新增而非修改库未加载libs缺项此时通常会报Unknown type对拍流程里两次运行用了不同设置fvSchemes/fvSolution 不一致。解法回读校验字典值确认日志中出现模型选择记录把两次运行的配置文件做 diff确认设置一致第 10 篇的对拍纪律。报错 3-4别人拿到工具链后报未知类型你这边正常。现象交付后对方无法使用自定义插件。根因对方的controlDict没有列出你的库铁律 5或对方用了不同的版本/平台导致库不兼容。解法交付清单第 3 步强制确认libsversion.lock明确版本与平台README 里给出报未知类型时先查libs、再查版本的排查顺序。报错 3-5Allwmake部分成功部分失败产物不齐。现象有些插件产物存在、有些不存。根因某个插件的Make/options缺依赖库/头文件路径LIB_LIBS/LIB_INC不全或库误用了EXE_*变量组。解法对照官方同族实现的Make/options逐行补齐第 10 篇用Allwmake末尾的产物核对清单定位缺失项。四、动手练习练习 1搭建骨架按代码 2-1 建出openfoam_devkit目录结构并把你在前 19 篇里写过的至少两个插件例如自定义求解器 一个库放进去。判定目录结构与代码 2-1 一致version.lock已按你机器实际情况填写。练习 2一键编译用代码 2-2 的Allwmake编译全部插件。判定所有插件编译通过产物全部出现在$FOAM_USER_APPBIN/$FOAM_USER_LIBBIN铁律 4分别用lib与app前缀打印的产物清单与预期一致。练习 3回归门禁用代码 2-3 跑 L1~L3。判定L1、L2 为硬通过L3 能得到两组的可观测量并计算相对差异能说明为什么 L3 必须自己设定容差与可观测量。练习 4端到端跑通用workflow/跑一次小规模 DOE例如 4 组。判定state.json状态正确results_long.csv含参数列与目标列report.md含被剔除样本披露章节全过程可重跑且幂等重跑时已完成组被跳过。练习 5交付演练按代码 2-4 的模板写一份 README 与交付清单。判定包含版本绑定、type ↔ 库名对照表、改动清单、已知限制四项能让一个没用过这套工具链的同事照着文档跑通 L1~L2这是最硬的验收标准。五、小结与系列回顾本篇交付的是一套方法论而不是一份代码。五层架构插件层、工作流层、回归层、交付层、治理层要回答的是如何把 19 篇零散的技术能力变成可交付、可信任、可维护的工程产品。回顾整个系列你已经走完了一条完整的成长路径阶段篇目你获得了什么入门01–04认清身份与版本线、掌握环境与源码导航、编译出第一个求解器、理解字典与 case 结构核心05–08场与网格对象模型、fvMatrix装配、标量输运求解器、物性配置与扩展进阶09–13湍流模型继承链与自建模型库、自定义边界与函数对象、fvModels/fvConstraints运行期操纵方程高级14–15并行三步流程与并行安全写法、先测量后优化的性能方法论实战16–19Python 驱动批量算例、结果聚合、网格流水线化、带状态机的 DOE 实验生产线收官20组装成五层工具链并用回归层保证它可被信任最后请把这 8 条铁律带走它们是全系列用最多篇幅反复论证的红线先读源码再写代码类名/键名必须有出处版本先声明Foundation vXX 或 ESI vXXXX不混写两线不混写Foundation 与 OpenCFD/ESI 的编号与命令差异编译产物落用户目录$FOAM_USER_APPBIN/$FOAM_USER_LIBBIN自定义库必须显式加载libs否则报未知类型并行算例不手改processor*走decomposePar/reconstructPar/redistributePar改完必验网格门禁 与官方基准对拍 结果不变数值不臆造物理常数与经验系数必须有出处查不到就写以官方文档为准。本篇认知问题回显FAQQ1一个完整的二次开发工具链应该有哪几层A五层。插件层自定义求解器、湍流模型库、边界条件、函数对象、fvModel统一编译到 FOAM_USER_APPBIN 与 FOAM_USER_LIBBIN 并在 libs 加载工作流层网格流水线 DOE 状态机 结果聚合回归层网格质量门禁 与官方基准对拍 关键量断言交付层README、交付清单、版本与平台绑定、用法示例治理层铁律清单、实体命名一致性、变更记录。一堆脚本不算工具链二者的差别在结构、编译入口、加载校验、验证覆盖与交付资料五个维度。分层的意义在于对应三类使用者算法工程师改插件层、自动化工程师改工作流层、质量工程师看回归层与一类读者交付对象读交付层使每类人只关心自己那一层。Q2插件层如何统一组织、编译与加载A靠三个统一。统一目录结构plugins 下按 solvers、turbulence、boundaries、functionObjects、fvModels 分组每组一个插件一个目录。统一产物落位求解器用EXE $(FOAM_USER_APPBIN)/名字并以 wmake 编译库用LIB $(FOAM_USER_LIBBIN)/lib名字并以 wmake libso 编译全部落用户目录铁律 4避免升级丢失与污染安装。统一加载清单所有库集中在 controlDict 的 libs 中显式列出铁律 5否则运行期报 Unknown type最佳实践是把清单做成模板文件加一个校验脚本检查清单中的库是否真的存在于 FOAM_USER_LIBBIN。Q3工作流层如何把流水线与状态机接起来A形成一条幂等、可续跑、留痕的执行链DOE 样本驱动每个样本在独立目录中先后完成克隆模板算例、改参带回读校验、网格流水线与质量门禁、串行或并行运行、收敛判定、状态落盘pending/running/converged/failed最后聚合 postProcessing 数据并生成含剔除披露的报表。三条贯穿纪律是幂等可安全重跑、留痕每步日志落盘、可复现参数快照、固定随机种子、版本绑定。其中状态必须每步落盘而非最后统一写失败组要保留日志与目录以便诊断。Q4回归层做什么为什么最重要A回归层分为四层测试L1 编译回归Allwmake 能否编译全部插件判据是退出码与产物存在L2 网格回归checkMesh 是否报 Mesh OK 且关键指标在阈值内L3 对拍回归未做实质改动时与官方基准同设置运行并比较监测量相对差异须在容差内L4 数值断言与解析解、文献值或既有结果比较。它最重要的原因是二次开发最危险的失败模式是静默错误——算完了、没报错、结果错了而回归层正是专门对抗它的机制其中 L3 是二次开发特有的让你每次改代码都能回答与改之前、与官方实现相比差多少、为什么。铁律改完必验的最终形态就是任何提交都必须通过 L1~L3。Q5交付清单应该有什么怎么让别人敢用A交付清单至少包含八项一句话定位与五层结构图运行前提OpenFOAM 版本线与版本号、WM_OPTIONS 平台、Python 与依赖建议单列 version.lock安装步骤Allwmake 编译并确认 controlDict 的 libs 已列出全部库快速上手示例回归验证方法让使用者自行复跑 ci/run_all.sh插件清单type 与库名或可执行文件的对照表改动清单每个插件相对官方实现改了什么、为什么已知限制未验证的版本、平台与场景。让他人敢用的关键不是宣称能力多强而是可自行验证与诚实边界。此外必须做版本与平台绑定说明因为扩展库与 OpenFOAM 版本及 WM_OPTIONS 强绑定跨版本或跨平台使用会链接失败或报未知类型。