在阅读TRNSYS相关文献时,我发现一篇发表在Applied Energy期刊上名为《通过实时TRNSYS-Python耦合对带电池和热能存储的太阳能区域能源》的文章,该文章声称构建了一种“实时TRNSYS-Python耦合”的优化框架,可以实现“on-the-fly system reconfiguration”和“无缝、实时”的仿真与优化联动。然而,经过对其技术实现细节的审慎分析,我认为:该研究并未实现真正意义上的实时联合仿真,其核心仍是一个基于脚本调用的离线批量处理优化流程,证据如下:

1、未实现真正的实时耦合
首先,什么是“实时”?在我的定义中,实时是指在一个时间步内完成感知、决策、执行这一连续闭环,并能够根据新的感知参数动态调整执行策略,从而驱动下一轮决策,如此循环迭代。
Kotegov等人的在摘要、引言和结论中反复强调“real-time coupling”“seamless”“on-the-fly reconfiguration”,但若仔细阅读全文,便会发现:原文中的实时,是子进程等待执行的自动脚本。作者借助Python的subprocess库来启动TRNSYS可执行文件。而subprocess的工作方式是:Python修改TRNSYS生成的dck文件,启动一个独立的TRNSYS进程,等待该进程完全结束,然后再次读取输出文件。这是典型的离线批量处理模式,每一步都是从头开始的瞬态仿真,而非实时数据交换,本质上还是与Genopt优化方式相同的离线优化。原文的创新点之一是使用Feature Importance Scoring (FIS)来动态识别关键变量,从而实现“on-the-fly system reconfiguration”。然而,仔细阅读可以发现:FIS是在每一轮优化迭代结束后重新计算,并用于下一轮采样。这是一种迭代间自适应性,而非仿真运行过程中的动态调整。

而真正的实时联合仿真要求两个软件在同一个仿真时间推进过程中同步交换数据,意味着:在TRNSYS模拟到n个时间步时,Python控制脚本可以基于如电池SOC、储热温度等当前状态实时修改后续的控制逻辑或参数,并且不需要重启仿真。

而原文并未实现这一点。且所有控制策略(Mode 1-4)和组件参数在仿真开始前就已固化在TRNSYS生成的dck文件中,未提供任何证据表明其在 TRNSYS仿真进行中能够动态交互。
其次原文设定的时间分辨率为1小时,整个仿真时长为3年。一次单核仿真需要50–70秒CPU时间。即使采用并行化,每次评估仍是一次完整的、从零开始的瞬态仿真。这意味着一轮含数百次评估的优化可能需要数小时甚至数天。将这种时间尺度称为“实时”不仅不准确,而且具有误导性,真正的实时系统应该及时响应输入变化,而非在数小时后给出新的配置建议。
2、控制策略仍为静态响应
原文第3.2.1节描述的四种运行模式基于温度阈值切换,通过TRNSYS的Type 2b控制器实现,这里存在两个问题:

第一:这些逻辑是静态的、预先编译的。尽管原文使用了“advanced rule-based controller”这类措辞,但实际上并未引入任何基于Python的实时决策干预。如果Python在仿真过程中没有机会修改切换模式,那么这种“耦合”与传统的TRNSYS独立仿真没有任何本质区别,
第二:Type2b仅为一个温差控制器,难以实现原文对于四种控制逻辑的切换实现,Type2b的TRNSYS官方使用说明书如下图:


3、忽视现有TRNSYS-Python耦合的成果
原文在引言中声称:“A fully integrated TRNSYS-Python optimization workflow that enables on-the-fly system reconfiguration without retraining delays has yet to be developed.”

这一论断直接忽略了已有的大量工作。例如,TRNSYS官方提供的Type 163、Type169、Type3157均可以直接调用外部Python脚本,并且许多研究已实现真正的双向耦合。原文作者似乎将“subprocess + 文件读写”视为唯一路径,这是一种技术视野的局限。

4结论
原文在案例数据、经济环境分析、敏感性分析以及系统性能展示方面有一定的学术价值。该研究为Solar District Energy Systems提供了完整、可复现的优化框架,对相关领域的工程实践具有参考意义。然而,至少在“实时TRNSYS-Python耦合”这一核心宣称是不成立的。它误导读者相信该框架能够进行仿真中的实时交互与动态重配置,实际上只是一个自动化程度较高的离线批量处理优化流程。

往期文章,欢迎阅读