企业官网建设流程全解析

燃烧后CO2捕集MEA吸收过程模拟教程（02）：软件与版本全景——Aspen Plus、Aspen HYSYS、DWSIM、COCO 的能力边界与选型

版本声明块

• 工具/软件：Aspen Plus、Aspen HYSYS（官方产品页均未公示数字版本号，写"以官方文档为准"）；DWSIM 桌面稳定分支 v9.0.5（2025-10-03，GitHub）；DWSIM 10 线 10.2.0 Release Candidate 10（2026-08-15，官网，抓取日期 2026-09-12）
• 语言/环境：Windows + Python 3.10+（代码 1 仅用标准库winreg；代码 2 纯标准库；代码 3 需 pywin32 与已安装的 DWSIM 桌面版）
• 本文目标：完成 MEA 吸收模拟的工具选型，并建立"版本号只能来自官方页"的引用纪律

一句话结论：在 MEA 吸收模拟上，速率基塔与电解质热力学"双支持"目前最成熟的是 Aspen Plus 与 Aspen HYSYS（官方把 RadFrac 平衡级 CO₂ 吸收塔转换为 Aspen Rate-Based Distillation 塔列为教学路径），而开源侧 DWSIM 具备DWSIM.Automation.Automation3与 CAPE-OPEN 能力、但其自动化属性包注册表中没有 eNRTL。

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

1. 主流过程模拟器在"MEA 吸收"这一件事上，能力边界究竟差在哪？
2. 为什么"速率基 + 电解质双支持"是最关键的分档标准，而不是界面或价格？
3. DWSIM 作为开源路线，版本号怎么写才不算造假，缺的关键部件是什么？
4. COCO/COFE 为什么做不了非平衡级，它自带的平衡级上限是多少？
5. 为什么 Aspen Plus、Aspen HYSYS、COCO、ProSimPlus、gPROMS、CHEMCAD 在本系列里一律不写数字版本号？

一、机制解析

1.1 能力边界总览：七款工具逐项对照

下表全部取自事实底账 §1，是所有后续选型讨论的基准。"版本号"列不写数字是刻意的引用红线，不是信息缺失。

（依据：[S1][S2][S3][S4][S5][S6][S8][S9][S10][S12][S13][S16]。）

1.2 分档逻辑：为什么"双支持"比"功能数量"更重要

MEA 吸收模拟有两个绕不开的技术门槛：

• 门槛一：电解质热力学。溶液里同时存在 MEA、MEAH⁺、MEACOO⁻、HCO₃⁻、CO₃²⁻、H⁺、OH⁻、H₂O、CO₂ 等物种（见第 01 篇），必须用能处理离子活度的模型才能算对 VLE 与负载。第 03 篇会说明 eNRTL、Kent-Eisenberg、Deshmukh-Mather 三者的适用边界。
• 门槛二：速率基传质。快速反应发生在液膜内，平衡级假设不足（见第 01 篇 1.5 节）。速率基塔需要用速率方程与传质系数计算界面传递 [C10]，并显式要求黏度、表面张力、导热系数、二元扩散系数等传递物性 [C1]。

只有两个门槛同时跨过的工具，才能"开箱"做 MEA 吸收塔的定量模拟。按此标准：Aspen Plus 与 Aspen HYSYS 属第一档（[S3][S4][S2]）；ProSimPlus 的 rate-based 是可选模块、CHEMCAD 官方明确支持胺基捕集但电解质细节未逐条公示，属"需要在使用前核实"的第二档；DWSIM 与 COCO/COFE 属需要自行补齐部件的第三档。

1.3 官方教学路径：平衡级 → 速率基

AspenTech 官方课程页明确包含两条能力训练：“Recognize the capabilities of Aspen Rate-Based Distillation for CO₂ removal modeling” 以及 “Convert an Aspen Plus RadFrac (equilibrium) CO₂ Absorber column to a column that uses Aspen Rate-Based Distillation” [S14][S15]。这给出了一个可以直接照搬的工程路径：

RadFrac（平衡级） → Aspen Rate-Based Distillation（速率基） · 变量少、易收敛 · 加传质/反应/物性子模型 · 作为初值来源 · 求解变量显著增多、收敛更难

本系列把这条路径固化为第 08 篇的实操主线；不收敛时的诊断放在第 15 篇。官方技术 FAQ 还说明，第二代速率基方法把气液膜离散成小段，沿轴向分布计算，并在每个轴向"切片"内再对膜进行分布，膜可在气相、液相或两相离散，采用线性或对数间距——对快速反应更准，但计算量上升 [S4]。

1.4 开源路线：DWSIM 有什么、缺什么

DWSIM 的核心价值在于开源（GPL-3）与自动化接口。官方源码DWSIM.Automation/Automation.cs给出的事实是 [S16]：

• 命名空间DWSIM.Automation；类Automation（旧）、Automation2、Automation3（COM Guid62486815-2330-4CDE-8962-41F576B0C2B8，[ComVisible(true)]）；
• 方法LoadFlowsheet(filepath)、SaveFlowsheet(flowsheet, path, compressed)、SaveFlowsheet2(flowsheet, path)、CalculateFlowsheet(...)、CalculateFlowsheet2(...)、CalculateFlowsheet3(flowsheet, timeout_seconds)、CreateFlowsheet()、ReleaseResources()、GetMainWindow()；
• Automation3额外提供AvailablePropertyPackages、AvailableCompounds；
• 已注册属性包（部分）：PengRobinsonPropertyPackage、SRKPropertyPackage、NRTLPropertyPackage、UNIQUACPropertyPackage、UNIFACPropertyPackage、IdealElectrolytePropertyPackage、GERG2008PropertyPackage、PCSAFT2PropertyPackage、CAPEOPENPropertyPackage（组件名 “CAPE-OPEN”）。

关键缺口：这份注册表中没有 eNRTL 专用包。所以本系列一律禁止断言"DWSIM 支持 eNRTL"——正确写法是"DWSIM 现有属性包不含 eNRTL 专用实现，电解质体系需自行开发或通过 CAPE-OPEN 接入外部包"。此外 DWSIM 自动化 API 存在三代（Automation/Automation2/Automation3），其中Automation2的GetMainWindow()会抛NotImplementedException[S16]，选错类名会直接报错。

DWSIM 10 线新增了官方的DWSIM MCP Server（headless，以 MCP 协议暴露引擎，HTTP 或 stdio，默认端口 5901，提供 Docker/Debian/便携包）[S5]。这是 10.2.0 RC10 的新能力，不得当作所有 DWSIM 版本通用。

还有一条工程陷阱：DWSIM 核心为 GPL-3 开源，但 Patreon Edition 的额外组件"可自由测试，保存含这类组件的模拟文件需要有效会员" [S5]——自动化批量保存会踩这个坑。

1.5 COCO / COFE 的平衡级上限

COCO/COFE 是 CAPE-OPEN 稳态仿真环境，含 COFE 流程图、TEA 热力学、COUSCOUS 单元操作、CORN 反应包 [S8]。做非平衡级精馏必须用完整版 ChemSep；COCO 自带的 ChemSep-LITE 是平衡级，上限为 40 组分 / 300 级[S8]。做 MEA 吸收塔时，这个上限和"平衡级"属性都需要提前评估。另外，COCO 自带 OATS 工具，专门用于 32 位 in-proc 属性包在 64 位客户端中的代理运行与 CAPE-OPEN 通信日志排查 [S8]——位数不匹配是 CAPE-OPEN 集成最典型的故障源。

关于 CAPE-OPEN 本身：标准由CO-LaN管理，定义"允许 CAPE（计算机辅助过程工程）应用或组件互操作的规则与接口"，接口族包括 Object、Unit、Thermo、Numerical、ESO，并有新一代COBIA[S22]。官方列出的公开落地案例包含 BASF ProcessNet、Air Liquide、BP、TOTAL、Honeywell UniSim Design 的 CAPE-OPEN Unit Operation socket、VMGSim socket、SuperPro Designer socket、ChemSep 属性包、KBC Petro-SIM/Multiflash（2024 CAPE-OPEN Award）[S22]。引用标准一律使用https://www.colan.org/，不要使用抓取失败的www.cape-open.org。

1.6 版本红线：为什么这七款工具都不写数字版本号

底账 §7-①⑦⑧ 已明确：Aspen Plus、Aspen HYSYS、COCO、ProSimPlus、gPROMS、CHEMCAD 的官网均未公示数字版本号。任何"V14""V15""aspenONE 某版"式的写法都属于编造。

唯一的例外是 DWSIM——它的版本号可写，但必须带抓取日期，因为其官网与搜索快照存在不一致（10.2.0 RC10 与 10.2.6 并存），且 v9.0.5 与 10.x 是双轨并行（R10 为 Avalonia 统一界面，架构与旧版差异大）[S5][S6]。本系列的统一写法是：v9.0.5（2025-10-03，GitHub）；10.2.0 RC10（2026-08-15，官网，抓取日期 2026-09-12）。

另外，gPROMS 一律不得断言其内置 MEA 捕集专用模板（底账 §7-⑧），COCO/TEA 的化合物数量也不得引用（官网同页自相矛盾，底账 §7-⑫）。

二、完整代码与逐行剖析

代码 1：本机 COM 自动化入口探测（结果仅对本机有效）

# 02_code1_com_progid_probe.py# 运行环境：Windows + Python 3.10+（仅标准库 winreg；pywin32 为可选依赖）# 用途：探测本机是否注册了 MEA 吸收模拟相关的 COM 自动化入口# 【重要】本脚本只报告“本机注册表 / COM 工厂里有没有这个东西”，# 不构成对任何软件能力或版本号的断言；可用与否必须由本机运行结果决定。# 底账 §6.1 已说明：COM 调用依赖本机安装的桌面版，# 无桌面安装的服务器 / 容器环境不可用。defprobe_registry_progid(prog_id:str)->str:"""检查 HKCR 下是否存在某个 ProgID 键（只读，不改动注册表）。"""try:importwinreg# Windows 专有标准库exceptImportError:return"非 Windows 环境，跳过"try:withwinreg.OpenKey(winreg.HKEY_CLASSES_ROOT,prog_id):return"已注册"exceptFileNotFoundError:return"未注册"exceptOSErrorasexc:# 权限不足等异常不应当让整个探测崩掉returnf"读取失败:{exc}"defprobe_com_guid(guid:str)->str:"""按 CLSID 尝试创建 COM 对象。 为什么用 Guid 而不是 ProgID：DWSIM 的自动化类在官方源码里给出的是 Guid（Automation3 = 62486815-2330-4CDE-8962-41F576B0C2B8）， 而 ProgID 写法未在官方文档中核实，这里避免写死未核实名称。"""try:importwin32com.client# 需要 pywin32exceptImportError:return"未安装 pywin32，跳过"try:win32com.client.Dispatch(f"{{{guid}}}")return"可创建"exceptExceptionasexc:# COM 注册 / 权限 / 依赖问题都会走到这里returnf"不可创建:{type(exc).__name__}"defmain()->None:print("===== 本机 COM 自动化入口探测（结果仅对本机有效）=====")# Aspen Plus：Apwn.Document 属“第三方可运行实现 + 官方示例佐证”的写法；# 带版本后缀的 ProgID（如 Apwn.Document.37.0）未获官方确认，本脚本不写死。print(f"Aspen Plus Apwn.Document :{probe_registry_progid('Apwn.Document')}")# DWSIM：官方源码 Automation.cs 给出的 Automation3 Guiddwsim_guid="62486815-2330-4CDE-8962-41F576B0C2B8"print(f"DWSIM Automation3 {{{dwsim_guid}}} :{probe_com_guid(dwsim_guid)}")# Aspen HYSYS：底账 §7-⑪ 明确其 COM ProgID 未核实，# 因此这里不写任何候选字符串，只提示读者自行查官方文档。print("Aspen HYSYS COM ProgID : 未核实，请以官方文档为准")print("\n判读：任何一项显示“未注册 / 不可创建”都不代表软件能力有问题，")print(" 只代表本机没有可用的 COM 入口——批量脚本必须在有桌面安装的机器上跑。")if__name__=="__main__":main()

反直觉点：探测脚本最容易被人当成"能力检测"来用。它不是。它只能回答"本机有没有装"，回答不了"这个版本能不能做速率基吸收"。能力边界必须回官方产品页与官方文档确认，这也是本篇 1.6 节坚持"不写数字版本号"的原因。

代码 2：把能力边界落成可筛选的数据结构

# 02_code2_capability_matrix.py# 运行环境：Python 3.10+（仅标准库）# 用途：把底账 §1 的“能力边界”落成可筛选的数据结构，避免凭记忆选型# 【重要】本表内容全部取自事实底账 §1；“版本号”列不写数字是刻意的引用红线。# 字段说明：rate_based / electrolyte 两列都以“人工标签｜说明”的形式书写，# 标签只取五个值：内置 / 可选模块 / 外部依赖 / 无 / 未核实。# 之所以不用关键词自动推断，是因为“rate-based 是内置还是可选模块”这种区别# 靠字符串匹配一定会出错，选型结论必须由人工判读给出。fromcollectionsimportnamedtuple Tool=namedtuple("Tool","name vendor rate_based electrolyte automation version_note")TOOLS=[Tool("Aspen Plus","AspenTech","内置｜Aspen Rate-Based Distillation（文献通行称 RateSep）","内置｜电解质物性（含 eNRTL 与 MEA 专用物性 insert）","Happ ActiveX interface（官方文档在《Aspen Plus User Guide》第 38 章）","官方页未公示，以官方文档为准"),Tool("Aspen HYSYS","AspenTech","内置｜官方标准应用 Acid Gas Removal Optimization，含 rate-based models","内置｜支持电解质物性","ProgID 未核实，以官方文档为准","官方页未公示，以官方文档为准"),Tool("DWSIM","Daniel Wagner（开源 GPL-3）","无｜未见现成的速率基 CO2 吸收塔","无｜属性包含 NRTL/UNIQUAC/UNIFAC/IdealElectrolyte/CAPE-OPEN，无 eNRTL 专用包","DWSIM.Automation.Automation3","v9.0.5（2025-10-03, GitHub）/ 10.2.0 RC10（2026-08-15, 抓取日期 2026-09-12）"),Tool("COCO / COFE","amsterCHEM 主导（开源）","外部依赖｜非平衡级需完整版 ChemSep；自带 ChemSep-LITE 为平衡级（上限 40 组分 / 300 级）","无｜电解质能力有限（基于 ChemSep 库）","CAPE-OPEN（供外部求解器接入）","官网未公示统一版本号"),Tool("ProSimPlus","Fives ProSim","可选模块｜非平衡级（rate-based）多级分离器为可选项","内置｜官方称热力学包覆盖 electrolyte 体系（含 Simulis Thermodynamics）","CAPE-OPEN 热力学与单元操作接口、VBScript","官网未公示数字版本号"),Tool("gPROMS / gPROMS Process","Siemens","未核实｜面向高保真动态建模与数字孪生，未检索到官方胺法捕集专用模板","未核实｜未在官方页面逐条公示","以官方文档为准","官网未公示数字版本号"),Tool("CHEMCAD","Datacor","未核实｜官方明确列出 Carbon Capture：模拟胺基 CO2 吸收","未核实｜电解质模型细节未在官网逐条列出","VBA、Excel wrapper、MATLAB/Simulink、作为其他应用的计算引擎","官网未公示数字版本号"),]deffilter_tools(need_rate_based:bool,need_electrolyte:bool):"""按“双支持”门槛筛选：只认人工标签“内置”，不认描述里的关键词。 “可选模块 / 外部依赖 / 无 / 未核实”一律视为不满足门槛。"""fortinTOOLS:rb=t.rate_based.startswith("内置")el=t.electrolyte.startswith("内置")if(rbornotneed_rate_based)and(elornotneed_electrolyte):yieldtdefmain()->None:print("===== 全部候选工具 =====")fortinTOOLS:print(f"\n[{t.name}] 厂商：{t.vendor}")print(f" 速率基 ：{t.rate_based}")print(f" 电解质 ：{t.electrolyte}")print(f" 自动化 ：{t.automation}")print(f" 版本号口径：{t.version_note}")print("\n===== 同时“内置速率基 + 内置电解质”的工具 =====")fortinfilter_tools(need_rate_based=True,need_electrolyte=True):print(f" -{t.name}")if__name__=="__main__":main()

判读：最后一段的输出只有 Aspen Plus 与 Aspen HYSYS 两款，这正是 1.2 节的分档结论。请注意filter_tools用的是人工标注字符串而非关键词推断——把"可选模块"误判成"内置"是选型阶段最常见的错误。

代码 3：DWSIM 自动化骨架（社区做法，非官方文档）

# 02_code3_dwsim_automation3_skeleton.py# 运行环境：Windows + Python 3.10+ + pywin32；需已安装 DWSIM 桌面版# 【社区做法，非官方文档】底账 §7-⑤：官方仓库存在 PythonLink / IronPython 控制台组件，# 但未检索到官方给出的 pythonnet + DWSIM.Automation 逐步示例，本片段只是调用骨架，# 属第三方示例，随作者更新可能失效，需在本机验证。# 【禁止写死】MaterialStream / Flowsheet 等具体类名与命名空间未核实，本脚本一律不写。# 方法与类名来自官方源码 DWSIM.Automation/Automation.cs（[S16]）。GUID_AUTOMATION3="{62486815-2330-4CDE-8962-41F576B0C2B8}"# 来自官方源码 [S16]defmain(flowsheet_path:str)->None:importwin32com.clientaswin32# 用官方源码给出的 CLSID 创建对象，而不是猜一个 ProgID；# 这是本脚本唯一“可回溯到证据”的入口写法。automation=win32.Dispatch(GUID_AUTOMATION3)flowsheet=Nonetry:# 选型阶段最有价值的一步：先看这个版本到底暴露了哪些属性包，# 再决定建模路线（若列表里没有 eNRTL，就不要指望它直接算 MEA 吸收）。try:pkgs=list(automation.AvailablePropertyPackages)print(f"可用属性包数量：{len(pkgs)}")print("示例：",pkgs[:5])exceptExceptionasexc:print(f"AvailablePropertyPackages 不可读（以所用版本为准）：{exc}")# 加载支持 .dwxmz / .dwxml / .xml 的流程文件flowsheet=automation.LoadFlowsheet(flowsheet_path)# 用带超时的重载，避免无界面环境下求解器无限等待automation.CalculateFlowsheet3(flowsheet,60)automation.SaveFlowsheet2(flowsheet,flowsheet_path)print("计算完成并已保存。")finally:# 无论成功失败都要释放引擎资源，否则下一次批量调用会残留进程automation.ReleaseResources()if__name__=="__main__":importsysiflen(sys.argv)<2:print("用法：python 02_code3_dwsim_automation3_skeleton.py <flowsheet.dwxmz>")else:main(sys.argv[1])

为什么必须写finally：DWSIM 的自动化是进程外 COM 调用，“算完不释放"会留下僵尸进程，下一次Dispatch可能拿到一个状态异常的实例。批量扫描工况时这个问题会被放大成"跑几十次之后集体超时”。

三、常见报错与排查

现象 1：win32com.client.gencache.EnsureDispatch("Apwn.Document")抛com_error。
根因：本机没有安装 Aspen Plus 桌面版，或 ProgID 未注册；Apwn.Document属于第三方可运行实现 + 官方示例佐证的写法，需在本机验证，带版本后缀的 ProgID 未经官方确认。解法：先跑代码 1 的注册表探测；确认已装桌面版后仍失败时，改用win32com.client.Dispatch（后期绑定）再试，最终以本机结果为准。

现象 2：脚本跑着跑着卡死，没有任何输出。
根因：收敛失败弹窗阻塞了进程。底账 §6.1 明确"弹窗会挂死自动化"。解法：在批量脚本里必须显式设置Application.SuppressDialogs = True；同时把Application.Visible = False（关界面可提速）。

现象 3：程序升级后，脚本的树路径全部失效。
根因：COM 脚本靠硬编码树路径取节点（如\Data\Streams\FEED\Input\TOTFLOW），而 AspenTech 官方承认版本迁移是需要官方介入的常规工程动作（System Management 专章讲仿真文件与用户子程序升级）。解法：把路径集中成常量表并加存在性检查，升级后先跑一遍路径探测；不要断言某条路径跨版本永久有效。

现象 4：调用 DWSIMAutomation2.GetMainWindow()抛NotImplementedException。
根因：Automation2未实现该方法（官方源码事实 [S16]）。解法：改用Automation3，并用其AvailablePropertyPackages/AvailableCompounds做前置能力检查。

现象 5：CAPE-OPEN 属性包在 64 位客户端里加载失败。
根因：位数不匹配——32 位 in-proc 属性包无法直接在 64 位客户端里运行。解法：使用 COCO 自带的 OATS 工具做代理运行，并用其 CAPE-OPEN 通信日志定位；引用标准入口统一用 https://www.colan.org/。

四、动手练习

练习 1（本机环境自检）：运行代码 1，记录Apwn.Document的注册状态与 DWSIM Guid 的创建结果。
成功判定：脚本能完整输出三行状态且不抛异常即算通过；无论结果是"已注册"还是"未注册"，都请在笔记中写明"该结论仅对本机有效，需在本机验证"。

练习 2（选型筛选）：运行代码 2，检查"内置速率基 + 内置电解质"的输出名单。
成功判定：输出应恰好包含 Aspen Plus 与 Aspen HYSYS 两项。若出现第三项，请回到TOOLS表检查你是否把"可选模块 / 需完整版 ChemSep"误标成了"内置"。

练习 3（缺口识别）：在代码 2 中为 DWSIM 增加一条打印，列出其缺失的关键能力。
成功判定：输出中应明确指出"无 eNRTL 专用包"与"未见现成速率基 CO₂ 吸收塔"两点，并写明结论：“DWSIM 的电解质与速率基能力需自行开发或通过 CAPE-OPEN 接入外部包。”

五、小结与下一篇预告

本篇完成了三件事：把七款工具在速率基与电解质两个维度上的能力边界摆清；给出"双支持"分档结论（第一档为 Aspen Plus 与 Aspen HYSYS）；建立了版本号引用纪律（六款不写数字、DWSIM 必须带抓取日期）。三段代码分别解决本机 COM 入口自检、能力矩阵筛选与 DWSIM 自动化骨架。

从下一篇开始进入"为什么同一批数据换一个热力学模型就给出不同答案"。第 03 篇会讲清 eNRTL、Kent-Eisenberg 与 Deshmukh-Mather 三者的假设、适用区间与规范引用（并纠正"eNRTL = Chen & Song 2004"这一错误命题）；第 04 篇则用 Aspen Plus 搭起本系列的第一个平衡级 MEA 吸收塔，并用Apwn.Document与Tree.FindNode把它脚本化。

本篇认知问题回显（FAQ）

Q1：MEA 吸收模拟中，哪些过程模拟器同时内置速率基塔与电解质热力学？

A：Aspen Plus 内置 Aspen Rate-Based Distillation 与电解质物性；Aspen HYSYS 官方把含 rate-based 模型的酸气脱除优化列为标准应用。

Q2：为什么"速率基 + 电解质双支持"是选型的最关键标准？

A：因为 MEA 吸收既有离子物种的活度问题，又有快速反应发生在液膜内的传质问题，两个门槛必须同时跨过才能定量模拟吸收塔。

Q3：DWSIM 的版本号该怎么写，它缺什么关键部件？

A：应写 v9.0.5（2025-10-03，GitHub）与 10.2.0 RC10（2026-08-15，抓取日期 2026-09-12）；其自动化属性包注册表中没有 eNRTL 专用实现。

Q4：COCO 自带的 ChemSep-LITE 是什么级别，上限多少？

A：ChemSep-LITE 是平衡级模型，上限为 40 组分、300 级；做非平衡级精馏需使用完整版 ChemSep。

Q5：为什么 Aspen Plus、COCO、gPROMS 等软件不能写具体版本号？

A：因为它们的官网均未公示数字版本号，写 V14、V15 之类的具体版本属于编造，只能写以官方文档为准。