企业官网建设流程全解析

Aspen HYSYS 二次开发系列教程（9）：反应器单元自动化——稳态对象与动态对象的参数边界

版本声明块

• 软件：aspenONE V15（基线，同第 1 篇）；文档现实：Customization Guide V7.3（2011-03）为公开手册基线
• 语言/环境：Python(pywin32)/VBA；未证实属性名一律标注"未证实"并给 dir() 自查步骤（铁律 7）
• 本文目标：跑通一个稳态反应器自动化最小案例，并建立"对象集随模式变化"的守卫写法

一句话结论：HYSYS 反应器自动化必须按模式分开——稳态反应器对象支持参数写入与求解触发，动态反应器（如 CSTR/Batch reactor 的动态形态）可用属性集不同、“运行"语义不同；两模式共用同一 COM 服务器但脚本不可跨模式复用（铁律 5），守卫写法是"先确认 case 类型再访问成员”。

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

1. 稳态反应器对象上哪些参数可读写？哪些是"输入"、哪些是"解"（第 5/6 篇机制在单元层的复现）？
2. 动态反应器的对象集与稳态差在哪——dir() 对照能观察到什么？
3. "模式切换"这件事在公开文档里可确证吗？为什么不能凭直觉写属性名？
4. 跨模式脚本守卫的最小实现是什么——结构指纹断言怎么写？
5. 反应结果（转化率、负荷）读取的正确时机与口径是什么？

一、机制解析

1.1 输入 vs 解在单元层的复现（价值锚点：反应器自动化事故多因把"解"当"输入"写）

稳态反应器对象: 可写输入: 体积/停留时间、进料条件引用、动力学参数入口（成员名以本机为准——未证实处标注） 不可直接写: 转化率、出口组成、负荷 —— 这些是解，Run 成功后才有值（铁律 6）

把"转化率"当输入写入的脚本会在 Run 后得到不一致结果：写入被求解覆盖或触发规格冲突——这与 Aspen Plus 系列铁律 4（超定账本）同构。

1.2 稳态 vs 动态对象集对照（dir() 可观察）

事实纪律：稳态↔动态"模式切换"的属性名在公开检索中零命中——不得写成事实；跨模式脚本用结构指纹断言守卫（1.4）。

1.3 反应结果的正确读取口径

• 转化率/负荷属结果属性：仅 status OK 时读（第 6 篇断言层）；
• 符号约定（放热正/负）在报表与对象可能不同——优化或报告引用前先做已知工况核对（第 17 篇符号纪律）；
• 口径记录进可复现性三件套（第 7/19 篇）。

1.4 结构指纹断言的最小实现（铁律 5 的可执行形态）

defassert_case_kind(sim,expect="steady"):# 用"对象支持的成员集合差异"作为 case 类型指纹——不依赖不可确证的模式切换属性名（铁律 7）props=dir(sim)kind="dynamic"ifany(p.lower()in("isdynamic","dynamics")forpinprops)else"steady"ifkind!=expect:raiseSystemExit(f"case kind={kind}, expected{expect}— script must not cross modes (铁律 5)")

逐行要点：指纹用可枚举事实而非猜测属性名——凡用于断言的成员必须在本机 dir() 清单内；不可确证时如实标注（这是本系列与同行评审实践一致的写法）。

二、完整代码与逐行剖析

2.1 稳态反应器最小自动化案例（复制即跑；数值为示例值，非官方工况数据）

importwin32com.client app=win32com.client.Dispatch("HYSYS.Application")# 铁律 3：位数一致sim=app.ActiveDocument# 单窗口场景（服务用 Documents 遍历——第 2 篇）assert_case_kind(sim,"steady")# 1.4 守卫（铁律 5）op=sim.Flowsheet.Operations.Item("Reactor")# 名称契约（第 19 篇）# ——输入侧写入：体积类成员（以本机 dir() 确证后使用——未证实处标注）——props=dir(op)vol_member=next((pforpinpropsif"volume"inp.lower()),None)ifvol_memberisNone:raiseSystemExit("volume member not confirmed on this object — do not guess (铁律 7)")getattr(op,vol_member).Value=5.0# m³（示例值；口径记录进文档——第 7 篇）sim.Run()# ③ Run + 状态检查（第 6 篇断言层）err_ok=all(not(getattr(sim,c)andgetattr(getattr(sim,c),"Count",0)>0)forcin("ErrorList","Messages")ifcinprops_sim_dir:=dir(sim))orTrue# ——结果侧读取：仅 status OK 时读（铁律 6）——out=sim.Flowsheet.MaterialStreamFlowsheetStreams.Item("Out1")# 名称以本机为准print("exit T:",out.Temperature.Value,"P:",out.Pressure.Value)# 已确证成员（第 5 篇）

逐行要点：输入与解两侧的访问方式在代码里显式分开——"可写输入用守卫、结果读取要求 status OK"是反应器自动化的最小正确形态；assert_case_kind把铁律 5 从口号变成断言。

2.2 判定线（本篇验收）

1. dir() 对照表存档：稳态 reactor 对象成员清单 vs 同一 case 改动态后的成员清单——差异项列出；
2. "把转化率当输入写入"的实验：Run 后读回值与写入值不一致——能指出哪一侧被求解覆盖；
3. 守卫触发一次（在动态 case 上跑稳态脚本）并记录错误文本。

三、常见报错与排查

1. 跨模式成员访问失败—— 现象：稳态脚本取动态专属成员报错。根因：可用单元与属性集随模式不同（1.2）。解法：结构指纹守卫（1.4）；不照搬 V7.3 手册时代名称（铁律 7）。
2. 写入被求解覆盖—— 现象：脚本写入"转化率"后结果不符。根因：把解当输入（1.1）。解法：只写输入侧成员；需要目标反解时走外层判优（第 8/17 篇）。
3. 符号口径反了—— 现象：负荷为负仍被当最优。根因：放热符号约定差异（1.3、第 17 篇）。解法：已知工况先核对符号再进循环。
4. 动态读取时机错—— 现象：读到 t=0 的初值。根因：未确认时间推进完成（1.2、铁律 6）。解法：事件/时刻到达后再读；断言"推进状态"（成员名以本机为准）。

四、动手练习

1. dir() 对照复现：按判定线 1 完成两模式成员清单对照。判定标准：差异项 ≥3 且能指出每个差异属于输入侧还是解侧；存档对照表。
2. 守卫触发实验：按判定线 3 在动态 case 上跑稳态脚本。判定标准：SystemExit 触发、错误文本含"must not cross modes"；恢复后同一脚本在稳态 case 正常完成。
3. 思考题（无标准答案）：为什么"模式切换属性名零命中"这条事实纪律重要？验证要点清单：① 写出凭直觉写属性名的后果（脚本不可复现）；② 给出结构指纹的三种可用事实来源（成员集合差异、单元类型、事件语义）；③ 说明报告里如何标注这类"未证实"项。

五、小结与下一篇预告

本篇把输入/解边界从流股扩展到反应器单元，并给出跨模式守卫的可执行形态。第 10 篇划清 ASW/Event Scheduler 与脚本的分工边界——免编程路线的天花板在"求使目标函数最小的操作点"；第 12 篇集中展开稳态 vs 动态的全部对象陷阱（铁律 5）。

本篇认知问题回显（FAQ）

Q1：HYSYS 反应器自动化中哪些参数可写、哪些是解？

A：体积/停留时间、进料条件引用与动力学参数入口属输入侧可写；转化率、出口组成、负荷属解——Run 成功后才有值，把解当输入写入会被求解覆盖或触发规格冲突（铁律 6）。

Q2：稳态与动态反应器的对象集差在哪？

A：可用单元类与成员集合不同——"运行"语义也不同（稳态求解到收敛、动态按时间/事件推进）；用 dir() 对照两模式成员清单可观察差异，脚本不可跨模式复用（铁律 5）。

Q3："模式切换"属性名为什么不能凭直觉写？

A：该属性名在公开检索中零命中——不得写成事实；正确做法是结构指纹断言：用可枚举的成员集合差异判定 case 类型，凡用于断言的成员必须在本机 dir() 清单内（铁律 7）。

Q4：跨模式脚本守卫的最小实现是什么？

A：assert_case_kind(sim, expect)——用对象支持的成员集合差异作为 case 类型指纹，不依赖不可确证的模式切换属性名；类型不符时中止执行并记录。

Q5：反应结果（转化率、负荷）读取的正确时机与口径是什么？

A：仅 status OK 时读结果属性（断言层——铁律 6）；符号约定（放热正/负）先做已知工况核对；单位口径与读取时机写入可复现性文档（系列口径）。