ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

基于粒子群算法的地表水源热泵系统建模与逐时优化调度策略

基于粒子群算法的地表水源热泵系统建模与逐时优化调度策略 做了这么多年暖通空调和能源系统的建模优化我越来越觉得很多项目不是缺设备、缺数据而是缺一套能把什么时候开哪台机器、开到多少负载讲清楚的策略。地表水源热泵系统尤其典型——水源侧的温度一年四季在变建筑负荷逐时在变峰谷电价也在变可大多数项目的群控策略还停留在温度高了就加机温度低了就减机的阶段。这篇文章我想从基于粒子群算法的地表水源热泵系统建模与机组逐时优化调度策略这个课题出发把整个技术链路拆开揉碎讲一遍包括系统建模怎么搭、粒子群算法为什么适合这类问题、逐时优化调度模型的目标函数和约束怎么设计、以及实际落地时有哪些坑。无论你是做暖通优化的工程师、正在准备数学建模竞赛的学生还是刚接触能源系统智能调度的研究者这篇文章都能给你一条相对完整的参考路径。1. 水源热泵机组的逐时寻优不是锦上添花而是实打实的能耗漏洞1.1 从按需开启到提前寻优传统群控缺了哪一步绝大多数水源热泵机房的运行逻辑是这样的回水温度升高到某个阈值就再加开一台机组回水温度降下来就停掉一台。这套逻辑听起来合理但它有两个天然缺陷。第一个缺陷是滞后性。温度是热惯性的结果你今天下午三点温度超了实际可能是因为上午十点的负荷就已经上来了中间这段高COP运行区间被白白浪费。第二个缺陷是只看总量、不看分配。多台机组同时运行时总负荷如何分摊到各台机组直接决定系统整体能耗但传统群控通常默认平均分配或者让机组按固定顺序加载。可实际上不同机组的运行时长、换热器结垢程度、部分负荷率下的COP特性都不一样平均分配往往让整个机房的综合能效处于次优状态。逐时优化调度的思路则完全不同在知道未来24小时逐时冷热负荷、逐时地表水温度、逐时电价的前提下提前计算出每一时刻各台机组的启停状态和负载率让系统每一时刻都尽量运行在费用最低或能耗最低的工作点上。1.2 部分负荷率与分时电价两把撬动运行费用的杠杆理解这个课题必须先理解两个概念。一个是部分负荷率PLRPart Load Ratio。机组在额定工况下能效最高但实际运行中负荷很少恰好等于额定制冷量。大多数螺杆机和离心机的COP随部分负荷率呈一条先上升后下降的曲线通常在70%到90%区间附近达到峰值过低或过高的负载都会让COP明显下降。多台机组并联时同样的总负荷分配给1台、2台还是3台分配比例是30%:70%还是50%:50%整体COP可能相差5%到15%——这部分差距是纯利润损失。另一个是分时电价。现在很多省份工商业用户执行峰谷分时电价峰段和谷段电价差距能达到3到4倍。如果能在低谷时段提前蓄能、在高峰时段减少机组出力或者在峰段把负载率压到高效区间运行电费会显著下降。逐时优化调度的核心价值就是同时拿捏这两根杠杆在每一个时刻既决定开哪几台机组又决定每台机组干多少活。1.3 这个问题适合谁做、从哪入手如果你正在准备数学建模类竞赛这个题目其实是一个非常适合深挖的赛题方向——它把建筑负荷模拟、热泵热力学模型、优化算法、时间序列决策融合在一个框架里每一个环节都有明确的评价指标。如果你是在做实际项目那就需要从项目所在地区的气象参数、建筑使用特征、机组铭牌参数做起把建模和优化落在真实数据上。从零开始做的话我建议按这样的路径入手先建立建筑逐时负荷的简化仿真模型再建立源侧水温边界模型然后拟合机组COP特性曲线接着设计目标函数和约束最后才是粒子群算法的编码和调优。下面我按这条路径逐个展开。2. 建模的第一步把建筑负荷、源侧温度和机组性能绑进同一张网2.1 建筑动态冷热负荷优化调度的需求底座任何调度策略的前提都是知道末端到底需要多少冷量或热量。建筑逐时负荷是典型的动态过程受室外干球温度、太阳辐射、室内人员设备散热、围护结构蓄热等多因素耦合影响。对于优化调度研究负荷模型不需要做得像DeST或EnergyPlus一样精细到每个房间但至少要能反映逐时变化趋势。比较实用的简化做法是采用稳态热平衡加蓄热修正Q_load(t) U·A·[T_out(t) - T_in(t)] Q_solar(t) Q_internal(t) - C_building·dT_in/dt其中 U·A 是围护结构综合传热系数乘以面积Q_solar 是透过窗进入的太阳辐射热Q_internal 是照明、设备、人员产热最后一项体现建筑蓄热。逐时负荷的峰值、波动幅度以及峰值出现时刻的准确性直接影响后续机组调度结果。如果做实际项目最好用历史运行数据或典型年气象数据驱动这个模型先用一两个月的实测电耗或水流量数据做校准再用于全年逐时优化。2.2 源侧温度边界地表水不是恒温的地表水源热泵的地表水包括江水、湖水、河水、海水或水库水它的最大优势是水温比空气温度温和得多冬天水温通常在4到10摄氏度而空气可能降到零下夏天水温通常在22到28摄氏度而空气可能到35度以上。机组冷凝温度夏季或蒸发温度冬季越接近末端需求温度COP越高。但地表水温也是逐时变化的。浅层地表水受气温影响明显夏季白天水温可能比凌晨高好几度不同深度的水温也差异很大。建模时可以取气象站或实测的水温数据的逐时序列也可以用简化的水体热平衡模型估算。源侧水温每升高1摄氏度夏季工况机组COP大约能提升2%到4%这个敏感性千万别忽略。2.3 机组热力模型把COP拟合成工况的函数机组是系统的核心设备其性能特征决定了整个优化问题的心脏。比较可靠的工程化建模方式是把COP看作部分负荷率PLR和源侧进水温度T_ws、负荷侧出水温度T_ls的函数。常用的二次回归表达式如下COP(PLR, T_ws) a0 a1·PLR a2·PLR² a3·T_ws a4·PLR·T_ws其中系数a0到a4可以通过机组厂家样本数据拟合得到样本数据不足时可以参考ASHRAE标准工况数据。需要注意的是不同品牌、不同压缩机型式的COP特性差异很大做具体项目时最好用铭牌上多个工况点的数据拟合而不是照搬论文里的通用系数。机组的电功率P_comp则直接由制冷量Q和COP计算得到P_comp(t) Q_load(t) / COP(t)这里隐含的一个关键关系是当总冷负荷确定时任意时刻各台机组电功率之和就是系统主机部分的能耗而优化算法要做的就是通过分配PLR让这个和尽可能小。2.4 水泵与输配系统的耦合很多初做系统优化的人容易犯一个错误只优化主机不优化水泵。实际情况中冷却水泵和冷冻水泵的能耗可能占到系统总能耗的20%到30%。水泵的功率与流量的三次方成正比。当一台机组的负载率降低时理论上可以通过变频调速降低对应水路流量从而大幅降低水泵能耗。因此完整的优化模型应当把水泵纳入决策范围当调度方案决定某台机组低负载运行时同时决策对应水泵的频率或流量让主机与水泵的综合能耗最低。当然这会让优化问题的维度明显增加初学者可以分两步走——先做仅含主机的版本跑通后再加入水泵变频逻辑。2.5 模型验证的底线要求建模做得再花哨验证不做就是空中楼阁。最基础的验证指标有三个逐时负荷模拟值与实测值的均方根误差、典型日总冷量误差、峰值负荷出现时刻的偏差。我见过不少团队在负荷模拟上差了30%以上这种情况下无论粒子群算法多先进优化出来的最优策略也是错的。模型精度没校准到位之前不要急着跑算法这是这条链路里最容易被跳过、同时也是最致命的一步。3. 粒子群算法为什么能扛起调度优化这面旗3.1 PSO的核心逻辑一群鸟怎么找到全局最优粒子群算法Particle Swarm OptimizationPSO是Kennedy和Eberhart在1995年提出的一种群体智能优化算法灵感来自鸟群觅食行为。你想象一群鸟在一片区域里找食物每只鸟不知道食物在哪但知道当前位置离食物有多远并且能感知到群体里目前离食物最近的同伴在哪个方向。于是每只鸟的飞行方向都会受到自己历史最优位置和群体历史最优位置的双重影响在不断试探和向优秀个体靠拢的过程中整个鸟群最终会汇聚到食物——也就是全局最优点附近。把这个逻辑映射到优化问题上每个粒子代表一个候选解粒子的位置就是一组决策变量的取值适应度函数就是我们要最小化的目标函数。粒子每次迭代时按下式更新速度和位置v_i^{k1} w·v_i^k c1·r1·(pbest_i - x_i^k) c2·r2·(gbest - x_i^k)x_i^{k1} x_i^k v_i^{k1}其中 w 是惯性权重控制粒子保持原有运动趋势的程度c1 和 c2 是学习因子分别控制粒子向自身历史最优pbest和群体历史最优gbest学习的强度r1 和 r2 是[0,1]区间的随机数用于引入随机性。3.2 为什么这类调度问题让PSO很顺手机组逐时优化调度问题本质上是一个高维、多约束、非线性、混合整数的优化问题。高维来源于24小时乘以多台机组的决策变量规模多约束来源于负载率上下限、启停逻辑、供能平衡等限制非线性来源于COP曲线和电价结构的非线性混合整数则因为启停是0/1整数变量而负载率是连续变量。这类问题传统上用动态规划或混合整数线性规划求解但动态规划面临维度灾难——状态变量一多计算量成指数增长混合整数线性规划则要求目标函数和约束条件尽量线性化而COP的非线性特性往往需要分段线性近似精度和规模之间很难平衡。粒子群算法对这些问题非常宽容它能直接处理非线性目标函数对整数变量只需要做取整或者映射处理约束条件可以通过罚函数方式融入适应度计算。更重要的是PSO实现简单、收敛速度快对一个包含3到5台机组、24小时逐时决策的问题种群规模30到50个粒子迭代100到200次单次优化通常几秒到十几秒就能完成完全满足工程实时调度的要求。3.3 与遗传算法、动态规划放在一起看很多初学者会问为什么选粒子群不选遗传算法两者都是经典群体智能算法实际效果在不同问题上互有胜负但PSO在调度类问题上有几个明显优势一是参数少GA涉及选择、交叉、变异多个算子的概率设计而PSO核心参数就惯性权重和学习因子三个二是PSO有记忆机制——群体最优解始终保留当前代无论多差都不会丢失已经找到的好解三是实现代码量小一个完整的PSO核心循环通常不到50行这对后续调优和维护非常友好。当然PSO也有短板最典型的是容易早熟收敛——如果某个粒子过早找到一个局部较优点其他粒子会被快速吸引过去导致群体丧失探索能力。这个问题我在第5章会详细讲对策。总之在工程尺度上PSO的性价比非常适合机组调度这个场景。4. 逐时优化调度模型的完整搭建决策变量、目标函数与约束4.1 决策变量的设计方式假设系统有N台机组调度周期取典型日24小时、逐时决策那么决策变量由两部分组成机组启停状态u_i(t) ∈ {0, 1}i1,2,...,Nt1,2,...,24机组负载率PLR_i(t) ∈ [PLR_min, PLR_max]粒子群算法本身是针对连续变量设计的对于0/1启停变量常见做法是在粒子編码时用连续值表示解码时通过Sigmoid函数或阈值判断映射到{0,1}。实际操作中更简单的办法是把启停状态也编码为[0,1]区间的连续变量解码时大于0.5视为开机小于0.5视为停机。但这样会带来一个隐患——同一台机组在相邻时段可能出现频繁启停切换为了解决这个问题需要在约束条件里加入最小连续运行/停机时间限制或者对启停切换施加罚函数。一个典型粒子的编码结构可以表示为一个2×N×24维的实数向量前 N×24 维是启停状态候选值后 N×24 维是负载率候选值。以3台机组为例决策变量维度是3×243×24144维。这个维度用PSO处理没压力但写代码时务必注意维度索引别搞混建议把位置向量拆成A段启停和B段负载率分别解码调试效率更高。4.2 目标函数从单一能耗到综合费用的递进最常用的优化目标是系统日运行费用最低。考虑分时电价并计及主机和水泵能耗目标函数可以写成min F Σ_{t1}^{24} Σ_{i1}^{N} [ u_i(t)·(P_comp,i(t) P_pump,i(t))·Δt ]·c_price(t)其中 P_comp,i(t) Q_i(t) / COP_i(PLR_i(t), T_ws(t))表示第i台机组t时刻的电功率P_pump,i(t) 是相应水泵的电功率c_price(t) 是t时刻的电价。如果项目方更关心节能而不是省钱可以把目标函数改成总能耗最低即去掉电价项只对电功率求和。如果项目涉及双碳指标还可以把碳排放系数乘进去变成碳排放最低。从工程角度来说运行费用最低通常是甲方最认可的指标因为它直接体现在电费账单上。也有研究采用多目标优化同时考虑费用和碳排放这时可以考虑加权和法或NSGA-II算法但复杂度会上升初期建议先把单目标做透。4.3 约束条件的工程化处理约束条件是优化模型里最容易写漏、也最容易让算法失效的部分。机组逐时调度模型至少需要包含以下四类约束第一供能平衡约束。任意时刻所有开机机组的制冷量之和必须等于建筑逐时冷负荷即 Σ Q_i(t) Q_load(t)。这是调度问题的硬性前提。第二单台机组负载率约束。PLR_min ≤ PLR_i(t) ≤ PLR_max。离心式压缩机通常有最低负载率要求大约30%到40%低于这个值会出现喘振风险螺杆机稍低但也不建议低于20%。如果粒子解码出来的负载率低于下限可以用罚函数大幅增加适应度值逼迫算法避开不可行解。第三机组启停逻辑约束。包括最小连续运行时间和最小连续停机时间防止机组频繁启停损坏压缩机。例如设定单台机组开机后至少连续运行2小时停机后至少2小时内不能再开机。这类时序约束处理起来比较麻烦常见的工程方案是在目标函数中加入启停次数惩罚项每发生一次启停切换增加一个费用项。第四电力需求约束可选。某些项目所在地对用户最大需量有考核如果优化后系统峰值功率超过合同需量会面临高额罚款。这种情况下需要增加系统总功率峰值约束或者把需量费用纳入目标函数。4.4 仿真对比实验的设计模型搭好之后设计对比实验非常关键否则无法证明优化策略真的有效。我建议至少做以下几组对照策略名称说明预期效果传统温度启停策略按回水温度阈值加减机负载率平均分配基线方案固定分组轮换策略按固定顺序轮换机组平均分配负载改善机组利用率等PLR逐时优化用PSO只优化启停台数负载率均分分析负载率优化的边际价值完整逐时优化用PSO同时优化启停状态和负载率论文/项目的最终方案用同一个负荷序列、同一个水温序列、同一条电价曲线去跑这四组对比统计全天总费用、全天总能耗、平均COP、启停切换次数这几个指标。实际做下来完整逐时优化相对于传统温度启停策略日运行费用通常能降低8%到15%这个幅度足以支撑一篇高质量论文或一个节能改造项目的可行性论证。5. PSO参数调优与代码实现从能跑到跑得好的关键细节5.1 参数选取经验值粒子群算法的参数看起来少但每一个都直接影响收敛性能。我给出了一套经过大量调度问题验证的推荐起点值工程上可以直接套用参数推荐取值说明种群规模 N_p30~50决策变量在100维量级时40左右够用迭代次数 T_max100~300配合收敛曲线观察不达标再增加惯性权重 w0.9 - 0.4 线性递减前段强全局探索后段强局部开发学习因子 c1, c22.0, 2.0 或 1.5, 1.5c1大则个体意识强c2大则群体收敛快速度上限 V_max取变量范围的10%~20%防止粒子飞出解空间约束罚因子10^6 量级用于不可行解的适应度惩罚惯性权重线性递减是我最推荐的做法它比固定权重在多种测试函数上都更稳健。如果你的问题比较平稳、没有太多局部陷阱也可以尝试固定 w0.7收敛会更快代价是可能错过更优解。5.2 边界约束处理与离散变量映射粒子在更新过程中很容易飞出变量边界处理方式有三种截断法越界就拉回边界、反射法越界按镜面反射回内部、惩罚法越界赋予极大适应度。我在机组调度里比较推荐截断法加速度钳制——越界的变量直接拉回边界对应速度置零这样既简单又能保证粒子始终在可行域附近探索。启停变量的映射可以用如下思路粒子在A段编码一个[0,1]的连续值解码时设阈值0.5大于0.5开机小于0.5停机。但为了减少频繁启停我建议在解码后加入一个最小启停时长修正器——例如连续检查3个时段如果某台机组只在中间一个时段开机前后都在停机状态就把它修正为全程停机。这个修正属于领域知识的嵌入能显著降低优化结果在工程上的不可行性。5.3 早熟收敛的识别与对策早熟收敛是PSO最经典的坑识别方法很直观看迭代过程中的gbest适应度曲线。如果适应度曲线在前20代就快速下降之后50代基本没有任何改进而最终结果又明显偏离预期大概率就是陷入局部最优了。我常用的对策有三个层次。第一是重启机制当gbest连续多次迭代没有更新时随机初始化一部分粒子的位置把它们重新撒到解空间里探索。第二是变异操作借鉴遗传算法的思路让某些粒子的速度或位置以极低概率比如1%发生随机扰动。第三是多种群并行把种群分成几个子群独立进化每隔一定代数交换一次gbest信息这样能有效避免整个种群被一个局部最优带偏。5.4 一个可复用的Python代码框架下面给出一份可直接跑通的PSO调度核心代码框架。这里省略了负荷预测和COP拟合的完整实现重点展示粒子群算法如何对接调度模型的几个关键环节。import numpy as np # ---------- 基础参数 ---------- N_UNITS 3 # 机组数量 HOURS 24 # 调度周期 POP_SIZE 40 # 种群规模 MAX_GEN 200 # 迭代代数 W_MAX, W_MIN 0.9, 0.4 C1, C2 2.0, 2.0 # 每台机组的额定制冷量kW Q_rated np.array([500, 500, 400]) # 负载率上下限 PLR_MIN 0.3 PLR_MAX 1.0 # 决策变量维度: 启停段 N_UNITS*HOURS 负载率段 N_UNITS*HOURS DIM N_UNITS * HOURS * 2 def decode(x): 将粒子位置解码为启停状态和负载率 u x[:N_UNITS * HOURS] plr_raw x[N_UNITS * HOURS:] u_bin (u 0.5).astype(int) plr np.clip(plr_raw, PLR_MIN, PLR_MAX) return u_bin, plr def fitness(x, q_load, c_price): 目标函数日运行费用最小化违反约束加罚函数 u_bin, plr decode(x) u_bin u_bin.reshape(N_UNITS, HOURS) plr plr.reshape(N_UNITS, HOURS) total_cost 0.0 penalty 0.0 for t in range(HOURS): q_total 0.0 for i in range(N_UNITS): q_i u_bin[i, t] * Q_rated[i] * plr[i, t] q_total q_i # 简化COP模型取PLR影响的近似曲线 cop_i 4.5 2.0 * plr[i, t] - 1.5 * plr[i, t] ** 2 total_cost u_bin[i, t] * (q_i / cop_i) * c_price[t] # 供能平衡约束偏差按罚函数放大 penalty 1e6 * (q_total - q_load[t]) ** 2 # 启停切换惩罚每次切换加固定费用 switch_cnt np.sum(np.abs(np.diff(u_bin, axis1))) total_cost switch_cnt * 20.0 return total_cost penalty # ---------- PSO主循环 ---------- def pso_optimize(q_load, c_price): x np.random.uniform(0, 1, (POP_SIZE, DIM)) v np.random.uniform(-0.1, 0.1, (POP_SIZE, DIM)) pbest_x x.copy() pbest_f np.array([fitness(xi, q_load, c_price) for xi in x]) gbest_idx np.argmin(pbest_f) gbest_x pbest_x[gbest_idx].copy() gbest_f pbest_f[gbest_idx] for gen in range(MAX_GEN): w W_MAX - (W_MAX - W_MIN) * gen / MAX_GEN r1, r2 np.random.rand(POP_SIZE, DIM), np.random.rand(POP_SIZE, DIM) v w * v C1 * r1 * (pbest_x - x) C2 * r2 * (gbest_x - x) v np.clip(v, -0.2, 0.2) x x v x np.clip(x, 0, 1) f_cur np.array([fitness(xi, q_load, c_price) for xi in x]) better f_cur pbest_f pbest_x[better] x[better] pbest_f[better] f_cur[better] if f_cur.min() gbest_f: gbest_idx np.argmin(f_cur) gbest_x x[gbest_idx].copy() gbest_f f_cur[gbest_idx] return gbest_x, gbest_f # 调用示例q_load和c_price需提前准备 # q_load np.random.uniform(300, 900, HOURS) # c_price np.array([0.6]*8 [1.2]*8 [0.3]*8) # 峰平谷示意 # best_x, best_cost pso_optimize(q_load, c_price)这份代码把核心循环控制在六十行以内但已经包含了罚函数、启停切换惩罚、速度钳制等关键工程细节。实际使用中你需要把COP拟合系数、源侧水温、水泵功率模型替换成自己的工程数据然后把q_load换成真实的逐时负荷序列。6. 落地要面对的现实问题负荷预测、启停约束与群控对接6.1 负荷预测误差带来的连锁反应逐时优化调度的前提是预知未来负荷但实际工程里负荷预测必然有误差。误差来源包括天气预报不确定性、人员活动随机性、突发事件等。负荷预测误差对优化结果的影响是非线性的——误差较小时系统会牺牲少量经济性误差大到一定程度时优化方案可能会给出一个比简单策略更差的结果。应对方式有两个主流思路。一是采用滚动优化rolling horizon每15分钟到1小时滚动重新优化一次用最新实测数据更新未来负荷预测让决策始终基于最新信息。二是采用鲁棒优化或场景法考虑负荷预测的多种可能场景优化一个在所有场景下都表现不差的方案。工程落地时滚动优化几乎是必选项它成本低、见效快而且天然适配现代楼宇自控系统。6.2 机组启停频率与设备寿命的现实约束粒子群算法如果没有显式限制很有可能给出这台机组每小时启停一次的方案因为从数学上看频繁切换可以更精细地匹配负荷。但对压缩机来说频繁启停会加速电机绕组热循环疲劳、增加启动电流冲击长期运行会显著缩短设备寿命。机器厂家通常不会给你一个明确的每日最大启停次数指标但工程经验上单台机组每天启停次数控制在3到4次以内是比较合理的。实现方式有两个层次一是在目标函数里加启停次数惩罚项前面代码里已经演示了二是解码后加最小运行/停机时长修正。我建议两者同时用第一层保证算法方向正确第二层保证最终方案在设备层面可执行。6.3 从离线优化到在线群控的衔接很多研究做到仿真结果最优就停了但工程落地的最后一公里恰恰是最难的。把离线优化结果变成在线群控指令通常需要打通以下链路从BMS或能源管理平台读取实时负荷、源侧水温、机组运行状态按滚动优化周期调用PSO计算出未来数小时的最优调度方案把方案转换成机组控制器能识别的启停指令和负载率设定值下发到群控柜或直接通过Modbus/BACnet协议写入机组控制器监控执行结果如果机组实际响应与设定值偏差过大触发保护逻辑或重新优化这里有一个实际的工程细节很多老款机组并不支持外部直接写入负载率设定值或者写入响应很慢。遇到这种情况退而求其次的做法是只下发启停台数启停时间表负载率由机组自带控制器根据回水温度自行调节。虽然损失了一部分优化空间但稳定性和兼容性大幅提升甲方更容易接受。6.4 把研究成果装进工程交付物最后聊一点实际项目里很现实的事情无论论文还是工程项目交付物不能只是一堆优化结果曲线。我建议在报告或论文里至少包含三样东西一是调度结果对比表把传统策略、等PLR优化、完整优化三套方案的日费用、日能耗、平均COP、启停次数放在一张表里一目了然。二是典型日调度甘特图横轴是24小时纵轴是机组编号不同颜色表示不同负载率区间让读者一眼看懂优化策略与负荷匹配的逻辑。三是敏感性与鲁棒性分析至少讨论负荷预测误差在±10%、±20%时优化方案的经济性退化幅度。这三样东西既是高质量论文的骨架也是打动甲方和评审专家的核心证据。根据我做类似课题的经验整个建模-优化-验证-落地链条里最容易翻车的不是粒子群算法本身而是源侧水温数据的真实性和负荷预测的精度。算法再先进喂进去的数据不准出来的所谓最优调度就是精致的错误。如果你打算在这个方向上深入我建议花最多的时间打磨负荷预测和水温边界这两个基础环节它们决定你的天花板。最后再分享一个小技巧做不同季节典型日的优化时别只挑最热或最冷的一天。过渡季节的部分负荷工况才是检验优化策略真实水平的试金石——因为那时候负荷波动大、机组频繁在低负载区运行传统策略的浪费最明显优化策略的优势也最容易体现出来。先把过渡季节做漂亮再回头优化极值日整个成果的说服力会上升一个台阶。
返回列表