工业软件知识体系 / Industrial Software Knowledge System
工业软件不是一个框架或一门语言，而是领域模型、数值算法、交互可视化与大型软件工程的结合。本区围绕完整工程链组织：
它与通用信息系统的区别，首先体现在数据语义和正确性成本上。一个节点编号、材料单位或坐标系错误，可能让求解顺利完成却得到错误结论；几何、网格和结果数据往往规模巨大，生命周期又跨越导入、编辑、计算、保存和版本升级。因此架构必须同时服务物理含义、数值计算、交互效率和长期兼容。
需求与物理问题
↓
几何 / CAD / 数据交换
↓
前处理：清理、网格、材料、边界条件
↓
求解器：离散、组装、线性/非线性求解
↓
后处理：场数据、可视化、报告
↓
验证确认、自动化与平台集成1. 工业软件的四类约束
工业软件同时受领域、数值、数据和工程约束。
领域约束描述物理对象与业务流程。 例如船体、构件、材料、载荷、边界条件和工况都有明确含义。
数值约束来自离散、求解和误差控制。 计算完成不代表结果正确，收敛也不代表模型能够代表现实。
数据约束来自规模、单位、坐标系、拓扑、版本和长期兼容。 一个看似简单的节点编号错误，可能传播到载荷、结果和报告。
工程约束包括桌面交互、插件、任务、部署、许可证和跨平台支持。 系统需要在真实坏数据和失败环境中恢复，而不是只运行教学样例。
Domain correctness
+ Numerical correctness
+ Data integrity
+ Software reliability
= usable industrial capability任何一项缺失，软件都可能生成看似专业但不可使用的结果。
2. CAD、CAE、CAM 与 PLM 的边界
CAD 关注产品几何、拓扑、参数和设计意图。 CAE 关注物理模型、离散、求解和结果解释。
CAM 关注制造过程、刀具路径和工艺约束。 PLM 管理产品数据、版本、审批和全生命周期协作。
它们交换数据，但不应混成一个巨型对象模型。
PLM revision
-> CAD design geometry
-> CAE idealization and analysis model
-> CAM manufacturing definition
-> evidence and reports return to lifecycleCAD 中的圆角和小孔可能对制造重要，却对某次结构分析需要简化。 CAE 模型是基于目的的理想化，不是 CAD 文件的机械复制。
设计版本变化后，分析模型需要判断哪些映射仍然有效。 依赖名称或数组顺序关联几何实体，会在拓扑变化时产生静默错误。
3. 几何模型与拓扑
几何描述曲线和曲面的数学形状。 拓扑描述 Vertex、Edge、Face 和 Solid 的连接关系。
工业几何内核还需要处理：
- 容差；
- 缝合和修复；
- 布尔运算；
- 参数曲面；
- 非流形实体；
- 稳定选择；
- 导入格式差异；
- 特征历史。
相同位置的两个点不一定是同一个拓扑 Vertex。 几何接近也不自动代表拓扑已经连接。
导入模块需要区分语法错误、几何退化和拓扑不一致。 自动修复必须记录做了什么，不能悄悄改变设计尺寸。
4. 从几何到分析模型
分析前常进行理想化：
- 删除与目标物理无关的小特征；
- 将薄壁实体抽取为中面；
- 将细长构件转为梁；
- 建立接触和连接；
- 分配材料、Section 和方向；
- 定义载荷、约束与工况；
- 生成网格控制。
每个理想化都有适用假设。 软件应保存来源、参数和关联，使用户能够检查或重新生成。
Design Geometry rev 12
-> Idealization rules rev 3
-> Analysis Model rev 8
-> Mesh rev 15上游版本变化后，下游派生对象进入过期状态。 系统不能继续把旧结果展示为当前结果。
5. 网格不是一组坐标
网格包含节点、单元、拓扑邻接、集合、分区和从几何到离散实体的映射。
网格质量需要结合单元类型和求解目标解释。 长宽比、扭曲、Jacobian 和边界层指标没有脱离场景的统一阈值。
网格数据模型通常需要：
- 稳定实体 ID；
- 局部与全局编号；
- 节点到单元邻接；
- Face/Edge 边界；
- 材料和区域；
- Ghost/Halo 实体；
- 分区和所有权；
- 几何关联；
- 质量与诊断。
百万实体不适合每个对象都使用重量级 QObject。 核心数据通常采用紧凑数组和批量算法，界面层通过 Model 或适配器观察。
6. 求解器执行管线
Parse and migrate input
-> validate units, topology and references
-> create fields and DOFs
-> assemble operators and right-hand side
-> apply constraints
-> solve linear / nonlinear systems
-> update state and check convergence
-> write checkpoint and results
-> produce statistics and diagnostics高层 Driver 控制载荷步、时间步、非线性循环和失败恢复。 局部 Kernel 只计算单元、通量或算子作用，不决定整个任务何时结束。
求解器接口应区分结构分析、数值更新和求解调用。 直接法中的符号分解可以跨多个右端项复用，不能每次全部重建。
7. 长时间任务与文档版本
导入、网格、求解和结果处理都可能持续很久。 它们不能阻塞 GUI，也不能把过期结果写回新文档。
Document revision N
-> freeze immutable task input
-> run in worker or service
-> produce candidate result for revision N
-> compare current revision
same -> commit
different -> reject or explicit rebase任务状态至少包含排队、运行、取消中、成功、失败和已取消。 超时只说明调用者停止等待，不代表底层计算已经停止。
取消是协作协议。 求解器在安全点检查请求，保存或丢弃中间状态，释放资源并报告终态。
关闭文档时要停止新任务、取消活动任务、等待回调排空，再销毁模型和渲染资源。
8. 后处理与可视化
结果不是无语义浮点数组。 Field 至少需要位置、分量、精度、单位、时间步和所属模型版本。
Result Field
├─ location: Node / Element / Cell / Face
├─ components: scalar / vector / tensor
├─ unit and coordinate frame
├─ step / increment / time
├─ mesh revision
└─ storage layout可视化层把 Field 映射为颜色、变形、Glyph、切面或等值面。 颜色范围、插值和外推规则都会影响工程解释，需要明确展示。
GPU Buffer、纹理和 Pipeline 是派生缓存。 它们可以从 Document 和 Field 重建，不能成为结果真相来源。
9. 文件格式与版本迁移
工业工程文件可能需要维护十年以上。 格式设计必须考虑 Schema 版本、未知字段、原子保存和部分损坏诊断。
保存流程推荐：
serialize to temporary file
-> validate structure and checksum
-> flush data
-> atomic replace destination
-> mark exact document revision clean磁盘不足或进程崩溃时，旧文件应保持可用。 后台保存 revision 5 完成时，如果用户已编辑到 revision 6，不能清除 revision 6 的 dirty 状态。
读取旧版本时执行显式迁移。 无法理解的新字段应按格式策略保留或拒绝，不能静默丢失。
10. Verification 与 Validation
Verification 回答“方程和算法是否被正确实现”。 Validation 回答“模型是否足以代表真实问题”。
Verification 方法包括：
- 单元测试；
- 解析解；
- 制造解；
- 网格收敛；
- 守恒检查；
- 可信求解器对照；
- 串并行一致性；
- 重启与 Checkpoint 一致性。
Validation 需要实验、现场数据、适用域和不确定性说明。 求解收敛不能替代物理验证。
每份证据都应关联模型、网格、软件版本、参数和硬件环境。
11. 插件和平台扩展
格式、求解器、材料和后处理适合通过插件扩展。 但插件边界必须定义 ABI、所有权、错误、版本和卸载顺序。
领域数据由宿主拥有。 插件卸载后，工程不能残留指向插件代码或对象的悬空指针。
高风险求解器和第三方模块可以放在独立进程。 进程隔离增加 IPC 成本，却能隔离崩溃和依赖冲突。
12. 部署与可运维性
部署不仅复制可执行文件，还要验证：
- 运行库和第三方依赖；
- GPU 驱动与设备能力；
- 许可证服务；
- 文件权限与临时目录；
- 插件搜索路径；
- 字体、翻译和资源；
- 日志与崩溃转储；
- 自动更新与回滚；
- 旧工程兼容。
生产问题需要可诊断错误。 “求解失败”应进一步区分输入、许可证、资源、数值收敛和结果解析。
13. 工业软件的完成定义
一个功能只有同时满足以下条件才算完成：
- 领域语义明确；
- 正常与错误输入可诊断；
- 数据版本和所有权清晰；
- 长任务可观察、可取消；
- 保存、重开和迁移可验证；
- 数值证据满足要求；
- 大规模性能经过测量；
- 部署和回滚可重复；
- 自动测试守护关键行为；
- 文档说明适用边界和限制。
界面演示成功只是起点，不是工业能力的终点。
课程目录
| 模块 | 内容 | 学完应具备的能力 |
|---|---|---|
| 工业软件基础与架构 | CAD、CAE、前后处理、格式、技术栈、架构 | 建立工业软件全景并识别子系统边界 |
| 求解器工程 | FEA、CFD、数据结构、性能分析与优化 | 从数值流程推导可实现的软件架构 |
| 船舶 CAE | 流体、结构、流固耦合、并行与验证 | 理解 MarineFlow / SAM 类业务工作流 |
| SAM 平台与二次开发 | 插件、Python API、C++ SDK、网格、场景与部署 | 在既有工业平台上可靠扩展功能 |
| 架构与迁移案例 | 产品对比、迁移设计、技术决策与复盘 | 把通用知识应用到具体约束 |
与其他大区的边界
- C++、Qt、插件 ABI 的通用机制放在 C++ 大区。
- CPU、GPU、MPI、CUDA 和性能测量放在系统与高性能。
- Agent 接入、模型路由和 RAG 的通用方法放在 AI 大区。
- 本区只讲这些技术如何服务几何、网格、求解、可视化和工程流程。
推荐路线
应用与平台开发：基础与架构 → SAM 平台开发 → 案例。
求解器开发：基础与架构 → 求解器工程 → 系统与高性能 → 船舶 CAE。
技术负责人：完成全部模块，重点关注数据模型、模块边界、验证确认、兼容性和部署。
工程链中的关键边界
几何模型描述形状与拓扑，分析模型描述材料、载荷、约束和工况，网格则把连续问题离散成可计算实体。三者相关但不能混为一体：几何修改可能使网格失效，网格重划分又不应丢失高层工况语义。稳定标识、映射关系和版本号用于判断哪些派生数据仍然有效。
求解器边界通常以明确输入模型、执行配置和结果协议连接平台。前处理不应依赖某个求解器的内部对象，求解器也不应直接操作 GUI。长时间任务需要独立状态、进度、取消、Checkpoint 和失败诊断；结果只有在模型版本匹配且文件完整时才能提交给文档。
领域模型 revision N
-> 校验与离散
-> 求解任务(input revision N)
-> 临时结果与收敛证据
-> revision 仍匹配？
├─是：提交结果并生成可视化
└─否：标记过期，禁止覆盖新模型质量如何被证明
工业软件不能用“界面能打开”作为完成标准。几何和格式模块需要往返读写与退化数据测试，数值模块需要解析解、制造解、网格收敛和可信软件对照，性能优化必须保持数值容差，部署还要验证许可证、运行库、GPU 驱动和回滚路径。
Verification 检查“方程是否被正确实现”，Validation 检查“模型能否代表真实问题”。二者都需要可追溯输入、版本、参数和结果。案例或性能数字如果缺少这些条件，只能作为现象，不能升级为工程结论。
学完本区后，应能沿数据链解释每个模块的职责，识别派生数据何时失效，设计可取消和可诊断的求解流程，并用证据而不是演示判断工业功能是否可靠。
数据规模、兼容性与协作
工业模型常包含百万到亿级实体，不能把所有对象都设计成带虚函数和事件的细粒度 UI 对象。领域层保存紧凑数据与稳定 ID，索引和渲染表示按需构建；加载时先读取元数据和索引，让用户尽快看到轻量文档，再根据视口和任务优先级分块读取。所有缓存都要能从权威模型重建，并受统一内存预算控制。
文件兼容是长期产品能力。格式必须携带 Schema 版本，读取器负责迁移旧数据并对未知字段给出明确策略。写入应使用临时文件加原子替换，磁盘不足或进程崩溃时保留旧版本。公共插件接口、脚本命令和自动化流程同样需要版本协商；发布新功能时要考虑旧工程、旧插件和回滚版本能否继续工作。
多人协作还要求把隐式知识变成数据契约。单位不能只写在界面标签里，坐标系不能依赖调用者约定，求解结果必须关联输入 revision、求解器版本和参数。日志、运行摘要和模型清单共同构成问题复现所需的最小证据。
典型失败的定位顺序
模型打不开时，先区分文件损坏、Schema 不兼容、依赖插件缺失和数据语义校验失败；求解失败时，区分输入生成、许可证、资源、数值收敛和结果解析；显示异常时，区分领域数据、场映射、场景缓存和 GPU 资源。把所有问题都归为“求解器错误”或“显示错误”，会让模块边界失去诊断价值。
可靠平台需要让错误停在最接近原因的边界，并携带对象 ID、版本和上下文向上传递。用户可以看到可行动的说明，开发者则能通过关联标识追踪完整链路。这样的可诊断性与数值算法同样重要，因为工业项目的大部分成本发生在异常数据、版本组合和真实工作流，而不是理想示例。