企业官网建设流程全解析

Aspen HYSYS 二次开发系列教程（5）：流股与操作对象的属性读写——值-单位两级结构与未证实属性自查

版本声明块

• 软件：aspenONE V15（基线，同第 1 篇）；文档现实：Customization Guide V7.3（2011-03）为公开手册基线
• 语言/环境：Python(pywin32)/VBA；未证实属性名一律标注"未证实"并给 dir() 自查步骤（铁律 7）
• 本文目标：把.Temperature.Value这类模式讲透——为什么是两级结构、单位从哪来

一句话结论：HYSYS COM 属性普遍是"对象→值"两级结构（如stream.Temperature.Value）——第一级是物理量对象（带单位口径），第二级才是数值；直接对stream.Temperature取数会拿到对象而非数字；凡不在本机 dir() 清单内的属性名一律视为"未证实"不得写入脚本（铁律 7）。

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

1. 为什么.Temperature.Value是两级结构而不是一个字段？这带来什么好处与坑？
2. 流股属性与操作对象（单元）属性的差异是什么——哪些属性只在单元上有？
3. 组成（composition）读写在 COM 里是什么形态——按组分名还是按索引？
4. 未证实属性名的"事实纪律"怎么执行——dir() 之外还有什么自查手段？
5. 属性写入后什么时候生效——写完立刻读回和 Run 之后读回的差别是什么？

一、机制解析

1.1 两级结构的语义（价值锚点：这是脚本里最高频的 TypeError 来源）

stream.Temperature ← 物理量对象（含单位口径、可能含趋势/历史） .Value ← 当前数值（按 unit set 口径——第 7 篇）

好处：同一物理量在 GUI、报表与脚本间保持单位口径一致；坑：把stream.Temperature当数字用会拿到对象（打印看似正常、参与运算即错）。判定标准（练习用）：对同一流股分别打印Temperature与Temperature.Value，前者应显示对象形态、后者是纯数值——能写出这个差异即达标。

1.2 流股 vs 单元的属性域对照表

经验法则：读"解"之前必须确认本次 Run 成功——输入属性与结果属性的生命周期不同（第 6 篇断言层在此复用）。

1.3 组成读写形态

组成通常按组分名或组分集合访问（具体接口形态以本机 dir() 为准，不凭记忆定案——这是"未证实"纪律的典型区）。判定标准：能列出该流股的组分清单并逐组分取值；任一组分名不在清单内即触发标注。

1.4 写入生效时机

写完立刻读回只验证"写入成功"，不验证"影响了解"——两者的区别就是第 6 篇存在的原因。

二、完整代码与逐行剖析

2.1 属性读写最小完整脚本（复制即跑）

importwin32com.client app=win32com.client.Dispatch("HYSYS.Application")# 位数一致（铁律 3）sim=app.ActiveDocument# 单窗口场景（第 2 篇）stream=sim.Flowsheet.MaterialStreamFlowsheetStreams.Item("Feed")# 名称契约（第 19 篇）# ——两级结构演示（1.1 判定线）——print("对象形态:",stream.Temperature)# 物理量对象print("数值:",stream.Temperature.Value)# 纯数值（unit set 口径——第 7 篇）stream.Temperature.Value=25# ℃（按当前 unit set；写的是"输入"）# ——dir() 自查（铁律 7 的可执行形态）——props=[pforpindir(stream)]assert"Temperature"inpropsand"Pressure"inprops,"属性不在本机支持清单——不得照搬旧文档"print("该流股支持的关键属性:",sorted(props)[:20])# ——写入后读回只证明写入成功（1.4）——print("write-back check:",stream.Temperature.Value)

逐行要点：assert把铁律 7 变成脚本守卫——凡断言失败的属性名不得进入生产脚本；本脚本未触发求解，因此不读任何结果属性。

2.2 VBA 对照（官方一手路线）

Sub ReadProps() Dim app As Object, sim As Object, feed As Object Set app = GetObject(, "HYSYS.Application") ' 连接已运行实例（第 3 篇） Set sim = app.ActiveDocument Set feed = sim.Flowsheet.MaterialStreamFlowsheetStreams.Item("Feed") ' 名称以本机为准（铁律 7） feed.Temperature.Value = 25 feed.Pressure.Value = 101.3 Debug.Print feed.Temperature.Value, feed.Pressure.Value End Sub

三、常见报错与排查

1. TypeError/对象参与运算错—— 现象：stream.Temperature * 2失败或结果荒谬。根因：两级结构漏.Value（1.1）。解法：统一用.Value；打印对照确认对象形态。
2. 属性不存在（未证实名照搬）—— 现象：报 “Object doesn’t support this property”。根因：V7.3 手册时代的属性名在 V15 不存在（铁律 7）。解法：dir()/对象浏览器自查；把清单存档进可复现性三件套（第 19 篇）。
3. 读到旧值—— 现象：写入后读回正常、但"解"未变。根因：结果属性依赖 Run（1.4、铁律 6）。解法：Run 并检查状态后再读——第 6 篇断言层。
4. 组成按索引越界—— 现象：组分循环报错。根因：组分名/索引与 case 定义不一致（名称契约破坏）。解法：先列组分再访问；把组分清单写入文档（第 19 篇）。

四、动手练习

1. 两级结构判定线复现：按 2.1 打印对象形态与数值。判定标准：两者形态差异可描述；assert 守卫触发一次（故意用不存在属性名）并存档错误文本。
2. 输入/结果生命周期实验：写 Temperature=25，不 Run 直接读一个结果类属性（如相分率），再 Run 后重读。判定标准：能观察到"写入成功但解未变→Run 后变化"的两阶段；记录两次数值。
3. 思考题（无标准答案）：为什么"值-单位两级结构"对报表一致性重要？验证要点清单：① 写出 unit set 口径与 .Value 的关系（第 7 篇机制）；② 举一个脚本与报表差一个数量级的场景（量纲错位）；③ 给出可复现性三件套里应记录的单位信息项。

五、小结与下一篇预告

本篇确立两级属性结构与"未证实即标注"的事实纪律。下一篇进入 Run 与状态检查——把"执行了 Run"和"收敛了"分开（铁律 6），断言层在自动化脚本中的最小形态，这是全系列工程化篇的根。

本篇认知问题回显（FAQ）

Q1：HYSYS COM 里.Temperature.Value为什么是两级结构？

A：第一级 Temperature 是物理量对象（带单位口径），第二级 .Value 才是数值——直接对第一级参与运算会拿到对象导致 TypeError；两级结构保证 GUI、报表与脚本间单位口径一致。

Q2：流股属性和操作对象属性有什么区别？

A：T/P/流量/组成属流股域；设备参数（效率、几何、负荷）只在单元上；两者"解"都要 Run 成功后才有意义——输入属性写入即生效，结果属性依赖求解事件（铁律 6）。

Q3：未证实属性名的纪律怎么执行？

A：用本机 dir()（Python）或对象浏览器/CallByName（VBA）枚举该对象支持的属性——凡不在清单内的属性名一律标注"未证实"不得写入脚本；把清单存档进可复现性三件套。

Q4：写完属性立刻读回能证明什么、不能证明什么？

A：只能证明写入成功，不能证明影响了解——解要等求解事件（Run）且必须检查状态；结果属性在 Run 失败时保留旧值（铁律 6）。

Q5：组成读写在 COM 里是什么形态？怎么避免越界报错？

A：通常按组分名或组分集合访问（具体接口以本机 dir() 为准，不凭记忆定案）——先列该流股组分清单再逐组分取值；把组分清单写入可复现性文档（名称契约管理）。