企业官网建设流程全解析

gPROMS二次开发教程（02）：装起来、看懂工程——许可、工作台与 .gPJ 工程结构

版本声明块

• 工具/软件：gPROMS 桌面建模环境gPROMS ModelBuilder；检索期官方发布锚点gPROMS Process 2022.1.0，适用版本以官方发布说明为准
• 语言/环境：gPROMS 语言（equation-oriented modelling）；工程文件.gPJ，加密运行文件.gENCRYPT
• 本文目标：把"软件装好了"升级为"看得懂工作台、看得懂工程文件、知道许可与模块是怎么回事"，并亲手搭出一个最小可运行工程骨架

一句话结论：一个 gPROMS 工程的可编辑形态是.gPJ（gPROMS 项目文件），对外交付与运行常以加密形态.gENCRYPT出现；桌面工作台gPROMS ModelBuilder把建模、流程、语言与结果分成若干页签，而许可决定"你有哪些模块可用、能求哪些类型的方程"——这三件事共同构成了二次开发的最小作业环境。

〇、本篇要解决的认知问题

• Q1：桌面工作台（gPROMS ModelBuilder）的界面分成哪几个功能区？各自管什么？
• Q2：.gPJ与.gENCRYPT是什么关系？为什么会有"加密运行文件"这种形态？
• Q3：一个工程内部的实体是怎么组织的？工程、模型、流程、任务之间是什么层级？
• Q4：许可是怎么"按模块启用"的？它如何决定"我能做哪些二次开发"？
• Q5：什么才算一个"最小可运行工程"？它最少包含哪些东西？

一、机制解析

1.1 工作台界面：四个功能区

gPROMS ModelBuilder是桌面端建模环境，本系列绝大多数工作都在它里面完成。它的界面可以抽象成四个功能区（不同版本的具体排布以官方文档为准）：

┌──────────────────────────────────────────────────────────────────────┐ │ 菜单/工具条：新建工程、打开 .gPJ、保存、求解、结果比较 │ ├───────────────┬──────────────────────────────────┬───────────────────┤ │ ① 工程导航树 │ ② 编辑区（多页签） │ ④ 结果/日志区 │ │ （实体树） │ - 模型页签（写 MODELS） │ - 求解日志 │ │ ├ MODELS │ - 流程页签（画 / 写 PROCESSES） │ - 曲线、表格 │ │ ├ PROCESSES │ - 语言页签（看/改生成的连接方程）│ - 收敛信息 │ │ └ TASKS │ - 参数估计/优化页签 … │ │ │ │ ③ 属性面板（选中实体的属性） │ │ └───────────────┴──────────────────────────────────┴───────────────────┘

四个功能区的职责：

经验法则：第一次建模失败时，不要先去改方程，先读④区日志。日志会告诉你"自由度不足/超定""某个初值导致不收敛"或"单位不一致"这类根因，比盲改方程快十倍。

1.2.gPJ与.gENCRYPT：一对"孪生"文件

这是初学者最容易困惑的一点：为什么工程会有两种文件形态？

这两者的关系可以概括为：你在工作台里编辑.gPJ；当你需要把工程交给别人的环境去跑、又不希望对方看到模型内部式时，就走加密形态.gENCRYPT。这一点有第三方集成实践佐证——美国 CCSI 工具集（FOQUS/SimSinter）的 gPROMS 配置文档描述了"读取.gPJ、实际运行.gENCRYPT"的工作方式（该来源为[B]级，仅作机制旁证）。

你（建模者） 交付/运行环境 第三方工具/被调用方 ┌──────────┐ 导出加密 ┌──────────────┐ 被调用 ┌──────────────┐ │ .gPJ │ ───────────▶ │ .gENCRYPT │ ─────────▶ │ 运行时/集成 │ │（可编辑） │ │ （不可读源） │ │ 只调用不解密 │ └──────────┘ └──────────────┘ └──────────────┘ ▲ │ └────────────── 结果/输出回流（曲线、报表）──────────────┘

铁律 1（先查底账，后落笔）：.gPJ/.gENCRYPT这两个扩展名在二次开发脚本、集成配置里会直接出现，写错了脚本就连不上。任何扩展名都要以官方文档与随附示例为准。

1.3 工程内实体的组织：一个四层的心智模型

把工程想成一棵四层的树，你会立刻理解"文件该放哪、实体该怎么命名"：

工程（.gPJ） ├── MODELS ← 第1层：模型定义（物理与方程） │ ├── 单元模型（如反应器、换热器的方程） │ └── 子模型（被上层模型复用的片段） ← 第 06 篇：层次化 Models in hierarchy ├── PROCESSES ← 第2层：流程（把模型实例化为 UNIT，用 TOPOLOGY 连线） │ └── 每个 UNIT 引用一个 MODELS 里的模型 └── TASKS ← 第3层：任务（PARAMETER / VARIABLE / SCHEDULE） └── 驱动流程做稳态/动态/批次操作

心法三条：模型只描述物理，不绑工况；流程负责"用哪个模型、连成什么拓扑、给什么参数"；任务负责"按什么时间顺序操作"。这样组织的好处是同一个反应器模型可以被十个不同流程、不同工况复用——这正是第 13 篇"自定义模型库"的地基。

最佳实践：从工程第一天起就执行"命名即文档"——单元名带物理含义（如feed_heater、cstr_main），模型名带版本或适用范围（如cstr_steady/cstr_dynamic）。半年后你会庆幸当初没有用unit1、m1、test2这种名字。

1.4 许可机制：只讲机制，不谈价格

gPROMS 是商业许可软件，模块与求解器/优化器按许可启用。二次开发前必须搞清楚三件事：

铁律 5（不写价格、SKU 与商业条款）：许可与模块只讲机制，价格、打包与商务条件一律写"以官方许可协议与商务报价为准"。学术版方面，官方学术页称向高校提供全功能许可，具体范围以官方渠道为准。

1.5 安装前置条件与环境：把话说在前面

• 操作系统与硬件：桌面端的要求以官方 Installation Guide 与发行说明为准（本系列不断言具体支持的 Windows 版本）；
• 路径纪律：工程路径不要含中文、空格与特殊字符。这是跨工具（尤其与gO:Python/gO:MATLAB/ 第三方集成）联用时最廉价、也最容易被忽视的排雷动作；
• 版本一致性：当工程会与外部脚本或集成工具联动时，注意"生成工程的环境"与"运行工程的环境"的版本一致性，避免出现"我这儿能跑、他那儿打不开"。

铁律 3（版本先声明）：任何界面/语言描述前先声明"适用版本以官方发布说明为准"。跨版本照抄是本系列最需要防的坑。

二、完整工程骨架与逐行剖析

代码 2-1：一个"最小可运行工程"的结构清单

my_first_project/ <- 工程根目录（路径不含中文/空格） ├── hello.gPJ <- 工程文件：模型/流程/任务的文本定义 ├── （工程内实体） <- 在导航树里组织：MODELS / PROCESSES / TASKS │ ├── MODELS <- 至少 1 个模型（如一个简单单元） │ ├── PROCESSES <- 至少 1 个流程（把模型实例化并赋参数） │ └── TASKS <- 可选；稳态演示可先不建任务 └── 结果输出 <- 求解后由工作台/你指定的位置承接（曲线、报表）

逐行剖析：

• 工程根目录里"唯一必需的文件"是.gPJ；其余实体都组织在它内部，而不是散落的独立文件。
• MODELS/PROCESSES/TASKS是工程内的实体类别，不是磁盘上的子目录——这一点与 OpenFOAM 那种"一切皆文件目录"的工具截然不同。
• 稳态最小演示可以只有MODELS+PROCESSES；TASKS留到第 18 篇的批次/开停车场景再上场。

代码 2-2：最小工程里的模型骨架（结构示意）

% --------------------------------------------------------------------------- % 说明：本块为"结构示意"，用于说明最小工程里该有哪些"部件"。 % 除已确证的实体与段关键字外，语句与段名以官方 gPROMS 文档为准。 % --------------------------------------------------------------------------- MODELS % 顶层实体一：模型定义（已确证关键字） %% 一个"最少内容"的模型通常需要三样东西： %% 1) 参数段：已知量（几何尺寸、进料条件等） %% 2) 变量段：待求量（出口温度、浓度、流量等） %% 3) 方程：守恒关系 + 本构关系（把未知量与已知量联系起来） PROCESSES % 顶层实体二：流程（已确证关键字） %% 在流程里要做三件事： %% 1) 用 UNIT 声明：把 MODELS 里的模型"实例化"成一台设备 %% 2) 给参数赋值：把模型里的 PARAMETER 填上具体数值 %% 3) 用 TOPOLOGY 连接：把设备的 PORT 连起来（连接即方程）

逐行剖析：

• 这段骨架故意不写具体方程：因为方程的书写规则属于语言细节，必须"以官方 gPROMS 文档为准"（铁律 4）。第 03 篇会给出一个完整的 CSTR 稳态模型。
• 注意"参数段/变量段/方程"是一般建模论文里也用的说法；在 gPROMS 里，它们对应的段关键字中，PARAMETER与VARIABLE是已确证的，方程段的段名以官方文档为准。
• PROCESSES里的三步（声明UNIT→ 赋参数 →TOPOLOGY连接）是流程建模的执行顺序心法，第 09 篇会把它升级为"自定义单元封装"。

代码 2-3：界面元素 ↔ 你要操作的工程实体（对照检查表）

+---------------------------+------------------------------------------+ | 你在界面上看到的 | 你实际在改的工程实体 | +---------------------------+------------------------------------------+ | 模型页签 | MODELS —— 方程与声明 | | 流程页签（含拓扑图） | PROCESSES —— UNIT 实例与 TOPOLOGY 连接 | | 语言页签 | PROCESSES 生成的连接方程（可看可改） | | 任务/操作页签 | TASKS —— PARAMETER / VARIABLE / SCHEDULE | | 参数估计页签 | 实验数据 + 目标函数（第 11 篇） | | 结果区 | 求解输出（曲线/表格/收敛信息） | +---------------------------+------------------------------------------+

逐行剖析：这张表是本篇最实用的"翻译器"——当你在界面上点击某个页签时，请同时在心里确认"我正在编辑哪一类实体"。养成这个习惯，能避免 90% 的"改了但没生效"的困惑：很多时候你改了模型，但流程里的实例还引用着旧参数，或反之。

三、常见报错与排查

报错 3-1：打开工程时提示许可相关错误（模块未授权）。
现象：工程能载入，但某个动作（求解/优化/加密导出）被拒绝。根因：该动作依赖的模块/求解器不在当前许可范围内。解法：先用"最小工程 + 最基础求解"确认基础许可可用，再逐个启用高级能力定位缺口；许可范围一律以官方许可协议与商务渠道为准（铁律 5）。

报错 3-2：拿到.gENCRYPT却打不开源文件。
现象：想编辑却发现没有可读源。根因：.gENCRYPT是加密运行形态，设计上就不提供源可读性。解法：向提供方索取可编辑的.gPJ；若业务上就是"只准运行、不准看内式"，则按运行时/集成方式调用（第 14 篇）。

报错 3-3：工程路径含中文或空格，联动外部脚本时失败。
现象：在工作台里能跑，一旦被gO:Python/gO:MATLAB或第三方集成工具调用就报路径错误。根因：外部工具链对非 ASCII 路径与空格的处理不一致。解法：把工程迁到纯 ASCII、无空格的短路径（如D:\gproms_work\proj01），这是最省事的永久解法。

报错 3-4：.gPJ 在他的机器上打不开。
现象：同事/评审方无法打开你的工程。根因：多为版本不一致，或他用的是不覆盖该实体类型的许可。解法：先核对双方版本（以官方发布说明为准）；再核对工程里用到的实体类型是否需要额外许可；交付给外部时优先考虑.gENCRYPT+ 说明文档。

报错 3-5：求解日志显示收敛困难。
现象：一次成功、一次失败，结果不稳定。根因：多为初值/顺序问题，而非许可或文件问题。解法：参见第 10 篇（官方能力名 Initialization procedures in gPROMS、Troubleshooting failing simulations、Making models robust）；本篇只需建立"先读日志、再动方程"的顺序。

四、动手练习

• 练习 1（工程骨骼）：按代码 2-1，在一个纯 ASCII、无空格的路径下新建工程my_first_project/hello.gPJ，并在其中建立三样东西：一个名为demo_model的模型、一个名为demo_process的流程（实例化demo_model）、一份记录"我用了哪些实体"的工程说明。判定：工程能被工作台正常打开；导航树中MODELS/PROCESSES下各能看到一个具名实体。
• 练习 2（文件形态辨析）：用三句话写出.gPJ与.gENCRYPT的分工，并各举一个"该用哪种"的场景。判定：正确区分"可编辑源形态"与"加密运行形态"，且两个场景分别落在"自己开发"与"对外交付/被外部调用"上。
• 练习 3（界面–实体映射）：打开练习 1 的工程，依次点击模型页签、流程页签、语言页签，写下"每个页签我正在改哪一类实体"。判定：三处映射与代码 2-3 的对照表一致；能找到语言页签里由TOPOLOGY连接生成的方程。
• 练习 4（许可清点）：列出你计划在课题里用到的三类动作（如"动态仿真"“参数估计”“加密导出”），逐一标注"我的许可是否覆盖"。判定：三类动作均有明确结论；未确定项写"以官方许可协议与商务报价为准"，不猜。
• 练习 5（思考题，无标准答案）：如果你的团队要把一个 gPROMS 工程交给外部合作方运行、但不希望对方看到模型方程，你会选择哪种交付形态？需要额外准备哪些说明文档？

五、小结与下一篇预告

本篇把"装好了"变成了"看得懂"：工作台分四个功能区（导航树/编辑区/属性面板/结果日志），工程的可编辑形态是.gPJ、加密运行形态是.gENCRYPT，工程内部是一棵"模型 → 流程 → 任务"的四层树，许可以模块为单位决定你能做什么。三条纪律请随身带：先读日志再动方程（经验法则）、路径纯 ASCII（前置条件）、许可只讲机制不谈价格（铁律 5）。

第 03 篇《第一个模型》将真正动手：把一台 CSTR（连续搅拌釜反应器）从"物理描述"翻译成 gPROMS 能解的方程组，给出完整的稳态模型片段、PROCESSES里的参数赋值，以及"方程数 vs 未知数"的自由度核对（铁律 8）。

本篇认知问题回显（FAQ）

Q1：桌面工作台 gPROMS ModelBuilder 的界面分成哪几个功能区？
A：可抽象为四个功能区：①工程导航树（列出 MODELS/PROCESSES/TASKS 等实体，是资产目录）；②编辑区（多页签：模型页签写 MODELS、流程页签写或画 PROCESSES、语言页签查看或编辑连接生成的方程）；③属性面板（编辑选中实体的属性）；④结果与日志区（求解日志、曲线、表格、收敛信息）。排布以官方文档为准。

Q2：.gPJ 与 .gENCRYPT 是什么关系？为什么要有加密运行文件？
A：.gPJ 是 gPROMS 项目文件，是工程的可编辑源形态，建模者用它开发；.gENCRYPT 是加密的项目/运行文件，用于对外交付和执行，目的是在不暴露模型内部式的前提下被运行或被第三方工具调用。工作流是开发 .gPJ，交付运行用 .gENCRYPT，结果回流。

Q3：一个工程内部的实体是怎么组织的？
A：工程是一棵树：第一层 MODELS（模型定义，只描述物理与方程，不绑工况）；第二层 PROCESSES（把模型实例化为 UNIT、赋参数、用 TOPOLOGY 连接）；第三层 TASKS（用 PARAMETER/VARIABLE/SCHEDULE 描述操作序列）。这种分工让同一模型可被多个流程、多种工况复用，是自定义模型库的基础。

Q4：gPROMS 的许可是怎么决定"我能做什么"的？
A：gPROMS 是商业许可软件，模块与求解器/优化器按许可启用。许可决定三件事：能否启动并载入工程、能否使用动态仿真/参数估计/优化等高级求解能力、能否对工程做加密交付。价格与 SKU 一律以官方许可协议与商务报价为准；学术版官方称提供全功能许可。

Q5：什么才算一个"最小可运行工程"？最少包含什么？
A：根目录里唯一必需的文件是 .gPJ，其余实体组织在它内部而非独立文件。最小演示只需 MODELS 加 PROCESSES：一个模型（含参数段、变量段与方程）加一个流程（用 UNIT 实例化模型、赋参数、必要时用 TOPOLOGY 连接）。稳态演示可不建 TASKS，TASKS 留到批次与动态场景。

本文涉及的语言细节以所购版本随附的官方 gPROMS 文档为准。