光热电站储热容量优化：从调度经济性到联合建模实践

光热电站前期设计阶段，储热容量是最难拍板的一个参数。我现在还记着几年前做项目对接时，对方拿着设计院给的“按汽轮机额定功率配置6小时储热”建议，问我们能不能直接照这个走。我当时就问了一句：你们上网电价曲线什么形状？配了储热之后是白天停机晚上发电，还是白天边发边储？对方愣了一下，然后我们花了两周把容量配置问题和调度问题捆在一起重新建模，结果最优容量比6小时少了1.5小时，但项目IRR反而提升了。这件事给我的教训是：光热电站的储热容量优化，本质上不是算“热容量”的数学题，而是算“调度经济性”的博弈题。这篇内容就围绕这个主题展开，说一下我在做光热电站储热容量优化配置代码时用到的方法、踩过的坑，以及可以直接复用的建模思路。

1. 为什么储热容量是“算”出来的，不是“拍”出来的

1.1 光热电站的储热到底在扮演什么角色

光热电站和光伏最大的区别，就是它能用熔盐或者其他介质把太阳能以热能形式存下来，而不是直接变成电。一个典型的光热电站包括集热场、换热系统、储热系统、汽轮发电机组和辅助系统。白天集热场吸收太阳辐射加热导热油或熔盐，一部分热能直接送去发电，另一部分存进储热罐；到了晚上或者多云时段，再从储热罐放出热量维持发电。

这个概念说出来大家都懂，但真正做项目时，储热容量的影响远比“晚上能多发几个小时”要大。储热容量改变了电站一天之内的可调度范围，也改变了它参与电网调峰、跟踪负荷的能力。换句话说，储热容量决定了光热电站是“靠天吃饭”的电源，还是能主动选择发电时段的电源。

用一个生活化类比：储热罐像一个“热力充电宝”。充电宝容量大小直接决定你能把多少能量搬到晚上用。买小了，晚高峰发不了多久，白天的热量可能被弃掉；买大了，罐子和配套换热器投资沉在里面，一年可能只用满几次。更关键的是，充电宝容量还会影响你的使用习惯——容量大的时候你会喜欢早上充满、晚上慢慢放，容量小的时候你只敢在电价最高那几个小时放，运行逻辑完全不同。所以在代码里把储热容量当作一个独立常数塞进去跑调度，本身就是错的。

1.2 调度经济性：储热容量设计的“裁判”

调度经济性这个说法，听起来有点绕，但落到项目上就是一句话：在给定的电价机制和并网要求下，光热电站通过调整自身发电时段、出力大小和启动停机策略，能获得的最大净收益是多少。储热容量不是越大越好，也不是越小越好，而是要让投资成本增量与运行收益增量之间取得平衡。

很多人做容量优化时，第一反应是最大化年发电量。这在固定上网电价、没有任何峰谷差异的模型里成立，但现实中的电价曲线往往有峰谷平之分，有些地方还要求光热电站参与早晚高峰调节。如果只追求发电量，储热容量可能会配得很大，但多出来的电量都落在平价甚至谷价时段，收益上不去，投资却实打实花出去了。反过来，如果储热容量配得太小，高峰时段能转移过来的电量有限，电站只能低价卖电，收益又少一块。

从代码角度看，调度经济性体现在目标函数的运行收益项里，但这项值不是独立存在的，它依赖于储热容量给调度模型提供的“自由度”。容量变量通过约束条件改变了可行域的形状，进而改变了最优运行策略。这就是为什么我们在代码里要把容量变量和运行变量放在同一个优化问题里求解，而不是先定容量再算调度。

1.3 容量决策与运行决策必须联立求解

把容量优化和调度优化拆成两层的做法，在工程上很常见：外层枚举或者启发式搜索容量，内层对每个容量做一次全周期调度优化。听起来逻辑通顺，但实际跑起来问题很多。外层容量稍微变一点，内层最优调度的“策略形状”就会变，收益曲线往往不是凸的，甚至会有几个局部最优峰。你用断点枚举或者简单的智能算法去搜，很容易卡在局部最优里。

举个例子，容量取5小时的时候，最优调度可能是中午边发边充，晚高峰满发；容量取6小时的时候，由于白天光场产热不够把罐子充满，最优调度变成了白天少发、集中储热，晚高峰继续满发。这两种模式的边际收益不一样，反映到目标函数上就是非线性跳跃。如果外层只按固定步长枚举，比如4、5、6、7小时，很可能漏掉5.5小时附近那个更优区间。

所以在代码实现上，我更倾向于把容量变量作为决策变量放进约束里，让求解器在全局可行域内同时搜索容量和运行策略。这样一来，储热容量不是“先定好再用”，而是“算出来的”，它与调度经济性形成了一个整体优化问题的两个侧面。这也是本文后续所有建模思路的出发点。

2. 优化建模：先把目标函数写对

2.1 目标函数：成本与收益之间的“平衡账”

储热容量优化配置的目标函数，往大了说是项目全生命周期净收益最大化，往小了说可以写成等年值成本最小化。我习惯用等年值形式，因为光热电站项目周期长，储热设备寿命和电站主体寿命不一定一致，直接用一次性投资对比收益很吃亏。

等年值化的核心是把投资成本折算到每一年，再和年度运行收益放在同一个时间刻度上比较。公式可以写成：

min C_CRF × c_tes × E_tes + c_om × E_tes + Σ_t ( c_buy_t × P_buy_t − p_sell_t × P_sell_t ) × Δt

其中 C_CRF 是资金回收系数，把一次性投资摊到项目寿命期内每一年的系数；c_tes 是储热系统的单位容量投资成本，注意这里要包含储热罐本体、换热器、熔盐泵以及对应的土建和安装费用；E_tes 是储热容量，单位一般是MWht；c_om 是储热系统的年运维成本系数；c_buy_t 和 p_sell_t 分别是第t个时段的购电价格和售电价格；P_buy_t 和 P_sell_t 是电站从电网购电和向电网售电的功率；Δt 是时间步长。

为什么要把购电项放进来？因为光热电站并非完全自给自足，阴天或者夜间启机阶段可能需要消耗厂用电，有时候为了维持储热罐温度也要用电加热。这部分费用虽然占比不大，但不放进目标函数里，优化器可能会产生“免费用电”的错觉，导致调度策略偏激。

资金回收系数本身有公式：

C_CRF = r × (1+r)^N / ((1+r)^N − 1)

其中 r 是折现率，N 是项目计算期。这个公式在可研阶段很常用，但在优化代码里很多人会漏掉它，直接把总投资放进目标函数和年度收益相加，结果储热容量被严重低估，因为一年收益根本摊不平一次性投资。我在第一版代码里就犯过这个错，后来把投资折算成等年值，最优容量一下子从3小时变成了5小时，差距非常大。

2.2 决策变量怎么选，决定了模型能不能解

在确定了目标函数以后，下一步是定义决策变量。很多人一开始会把变量定义得很全，结果模型规模爆炸，一个8760小时的年度调度根本算不动。我的经验是，变量要分两层：容量层和运行层。

容量层变量包括储热容量 E_tes、储热系统最大充热功率 P_ch_max、最大放热功率 P_dis_max。这三个变量看起来相关，但实际上是独立的。储热容量是能量上限，功率上限是换热能力上限。工程上常有人只优化容量，不优化功率，默认功率和容量成正比，结果优化出来的方案可能在夏天弃热、冬天放不出来，因为换热器面积不够。

运行层变量包括每个时段的集热场产热功率 Q_sf_t、储热系统充热功率 Q_ch_t、放热功率 Q_dis_t、弃热功率 Q_dump_t、汽轮发电机组电功率 P_tb_t、购电功率 P_buy_t、售电功率 P_sell_t，以及储热罐的荷电状态 SOC_t。如果是做机组组合级别的调度，还需要引入汽轮机组启停的0-1变量 u_t。

这些变量之间不是孤立的，它们通过一系列约束耦合在一起。变量定义得越细，模型越贴近物理过程，但求解难度也会指数级上升。我的建议是，第一版模型先做“合并简化”：把集热场、蒸汽发生系统合并成一个产热单元，把汽轮机组简化为一个可变出力单元，先跑通，再逐步拆分。很多论文里的精度损失根本不在模型复杂度上，而在参数不准和数据颗粒度不匹配上。

2.3 关键约束：四条让你少熬夜的线

约束是储热容量优化模型里最考验细节的部分，写错一条，结果看起来合理，实际上物理上完全不可行。我梳理了四条最关键的约束链。

第一条是集热场产热约束。集热场每个时段能收集到的热功率取决于DNI、环境温度、风速以及镜场光学效率。严格说应该做一个分段线性函数，但为了在优化模型里不自找麻烦，我通常把每个时段的“可用产热功率”作为输入参数，让 Q_sf_t 不超过这个上限即可。优化器可以选择少集热，也就是通过调节导热油流量或者部分镜场散焦来实现弃热。

第二条是储热罐能量平衡约束。这是最核心的时序约束，公式为：

SOC_t = SOC_{t−1} + ( η_ch × Q_ch_t − Q_dis_t / η_dis − q_loss_t ) × Δt

其中 η_ch 和 η_dis 分别是充热和放热效率，q_loss_t 是储热罐散热损失。特别要注意的是首末SOC必须相等，否则相当于无限免费储能，优化器会把一整年的热量都堆到最后一个时段放出去，产生荒谬结果。这条约束我见过太多人漏掉，漏掉之后优化出来的“最优容量”通常偏大。

第三条是汽轮机组发电约束。包括出力上下限、爬坡约束、最小运行时间和最小停机时间。光热电站的汽轮机组特性有点像火电，但启动时间更短、变负荷速率更快。在年度优化模型里，为了降低求解难度，可以只保留出力上下限和简单爬坡约束，但最小运行时间不建议完全忽略，否则优化器会把机组切成频繁启停，完全不现实。

第四条是电功率平衡约束。电功率平衡指的是电站与电网的交互功率等于汽轮发电机组出力减去厂用电消耗。如果允许购电，那么售电功率减去购电功率等于净送出功率。这里需要引入一个0-1变量来防止同一时段既购电又售电，否则目标函数里购电和售电价格不同，优化器可能通过同时买卖来做套利，这个动作在物理上不值得鼓励，也会污染结果。

3. 容量优化和调度优化“叠”在一起，怎么拆

3.1 为什么不能先优化容量再优化调度

储热容量和调度策略天然存在耦合关系，但你写代码的时候不可能把容量连续变量和8760个小时的运行变量全塞进一个大MIP里直接求解，计算规模会超出现有求解器的处理能力。所以实际项目中一般会把问题拆成两层：外层处理容量变量，内层处理调度变量。

但拆不是简单拆。最常见的错误做法是外层枚举容量，内层逐点计算，然后取所有结果中的最优解。这个方法看起来直接，但存在几个问题：枚举步长难以选择，步长太细计算量爆炸，步长太粗容易漏掉最优区间；而如果外层用智能算法搜索，又面临收敛性和全局最优性无法保证的问题。

更深层的原因是，内层调度本身是一个带时序约束的优化问题，容量变量的改变会改变内层可行域的形状，从而导致内层目标函数关于外层变量出现非凸、不连续的性质。你无法保证外层搜索算法能找到全局最优。要解决这个问题，必须从数学建模的角度去做等价变换，而不是靠外层算法盲目搜索。

3.2 方法一：用KKT条件把内层调度问题“卷”进外层

如果你希望得到严格意义上的全局最优解，可以考虑把内层调度问题的最优性条件写进外层模型。当内层调度是一个线性规划问题时，它的KKT条件是必要且充分的。将这些条件加入外层模型，再加上互补松弛条件的线性化处理，就能把所有约束合并成一个大规模单层优化问题。

这个方法的优点很明确：可以调用成熟的混合整数线性规划求解器，一次求解得到容量和调度策略同时最优的解。代价是模型规模会肉眼可见地增长，尤其是互补松弛条件需要引入大量0-1变量和Big-M常数。如果Big-M取得太大，求解器数值稳定性会变差；取得太小，可能会错误削减可行域。

在实际代码里，我会用这个方法来验证启发式方法得到的容量是否接近全局最优。具体做法是，先把内层调度简化成一个线性规划，用KKT条件合并求解一次，把最优容量作为基准；再用启发式嵌套方法跑多轮，如果两者差距在1%以内，就说明启发式方法在工程上是够用的。

3.3 方法二：启发式外层+内层优化调度

工程上接受度最高的还是启发式外层加内层调度优化的嵌套方法。外层用粒子群算法或者遗传算法搜索储热容量的候选值，内层用成熟的MILP求解器求解给定容量下的最优调度。外层每给一个容量，内层就跑一个完整的优化调度，把对应的年收益返回给外层作为适应度。

这个方法实现起来最稳，因为内层调度是一个标准优化问题，商业求解器处理得很好；外层算法的收敛性问题可以通过多次运行取最好结果来缓解。我通常会把外层粒子数设成20到30，迭代次数在30到50次之间，再加上一个局部精细搜索：先用大步长找优值附近，再在小范围内加密采样。

缺点也很明显：每一次内层调度计算都需要不短的时间，如果外层迭代次数多了，总计算时间会让人崩溃。所以在工程实践中，我会先做“典型日”优化而不是全年8760小时优化，用几个代表性日替代全年，把内层计算量降下来，等外层容量收敛后再用全年模型复核。这个“两阶段校验”思路几乎适用于所有时间跨度较长的储能容量优化问题。

3.4 方法三：多场景随机规划与Benders分解

再往前走一步，就是考虑不确定性。光照资源、电价、负荷都不是确定值，如果只用一个典型年数据，优化出的容量往往对极端天气或者电价波动很脆弱。于是就有了多场景随机规划：构造一组典型场景，每个场景有独立的调度变量，但容量变量是所有场景共享的。

这个问题天然适合用Benders分解：主问题是容量投资决策，子问题是各个场景下的运行调度问题。每次迭代，子问题返回一部分对容量的边际价值，主问题据此调整容量。这个方法的数学逻辑非常漂亮，计算效率也高，适合大规模场景集。

但Benders分解实现起来门槛不低，尤其要处理子问题不可行的情况，需要添加可行性割。对于光热电站储热容量优化来说，如果子问题总是能找到可行解，那么实现难度会小很多；但现实是极端场景下可能无法满足所有约束，这时候就需要加入松弛变量和惩罚项。我建议先从固定场景数的两阶段模型练手，跑熟了再扩展到Benders分解。

4. 代码实现中的关键细节与避坑经验

4.1 建模工具选型与数据准备

代码层面，我目前的标配是Python加Pyomo，求解器用Gurobi或者CBC。Pyomo的好处是建模语法清晰，方便把容量层和调度层分开写，调试时能直接输出每个约束的表达式；Gurobi的MIP求解速度在同类产品里属于第一梯队，工程上比较省心。如果公司没有Gurobi授权，用CBC也能跑小规模算例，但遇到8760小时模型会比较吃力。

数据准备是整个流程里最容易被低估的一环。在写代码之前，我会先把以下数据整理成标准表格：DNI和太阳位置逐时数据、环境温度、风速、汽轮机组热力特性参数（热耗率曲线、最大最小出力）、储热系统效率（充热效率、放热效率、热损系数）、分时电价曲线、厂用电率。时间分辨率建议先统一成1小时，因为多数电价和气象数据都是小时级，后续再加密到15分钟验证。

很多人不理解为什么热力特性参数这么重要。光热电站的汽轮机组热耗率不是常数，尤其在不同出力段差异很大。如果你在模型里用一个固定热电转换效率，调度策略会过于乐观：优化器会把机组压到很低的出力去赚高峰电价，但实际在这个出力点机组效率很差，收益根本没那么高。所以我至少会用两段线性函数来拟合热耗率曲线，哪怕增加一两个整数变量也值得。

4.2 约束线性化：那些让求解器崩溃的“小问题”

储热容量优化模型里最常见的非线性有两个：一个是充放热功率不能同时为正，另一个是容量变量与调度变量之间的乘积项。

充放热功率互斥问题相对好解决，引入一个0-1变量，让充热功率和放热功率共用同一个上限约束即可。但这里有一个很容易犯的错：如果储热容量变量 E_tes 本身是待优化变量，那么充放热功率上限应当是容量乘以一个比例系数，或者是一个独立决策变量。如果你直接把功率上限写成固定常数，容量优化结果就没有意义了，因为功率瓶颈会先于容量瓶颈出现。

容量变量与调度变量相乘的问题更麻烦。比如充热功率上限如果是容量乘以一个固定比值，就会出现 Q_ch_t ≤ α × E_tes 这种包含乘积的约束。这时候需要做双线性化处理：把 E_tes 离散成有限个备选值，为每个备选值引入0-1变量，这样每个调度变量和0-1变量的乘积可以用标准线性化方法展开。这种“离散化容量候选”的方式，既是数学上可行的手段，也更贴近工程实际——因为储热罐容量本来就不是连续可选的。

Big-M的选择是个技术活。我见过很多代码直接用同一个很大的M，比如1e9，结果求解器一会儿说不可行一会儿说最优，完全无法复现。正确做法是给每条约束单独计算物理上合理的M值。例如充热功率上限不可能超过集热场最大产热功率，放热功率不可能超过汽轮机组最大热耗对应的热量，储热容量也不应该超过连续阴雨天恢复所需的极值。用物理上界做M，数值稳定性和求解速度都会有明显改善。

4.3 求解性能优化：从“跑不动”到“秒出解”

优化模型建完之后，第一次跑8760小时模型大概率会让你怀疑人生。我在一个50MW光热电站算例上，直接把全部约束和整数变量都建进去，Gurobi跑了两个小时还没收敛。后来做了几件事，才把求解时间压到十分钟以内。

第一件事是热启动。先用一个经验容量固定下来，跑一次调度模型，把调度变量的解保存下来，作为完整优化模型的初始可行解。这样求解器一开始就有一个可行解，可以省去大量搜索可行域的时间。第二件事是设置合理的MIP gap。不需要追求严格的0.00%，一般设置在0.5%到1%之间即可，因为储热容量连续变量对收益的边际影响往往很小，0.5%的gap对最终容量结论影响不大。

第三件事是场景削减。全年8760小时直接跑不现实，可以按“典型日倍数”来缩减，比如选择春分、夏至、秋分、冬至四个典型日，乘以季节加权系数。这样模型时间步数从8760降到96或者192，内层调度速度提升很多。但要注意，典型日法会低估跨日连续阴雨对储热容量的需求，所以最终还是要用全年数据复核一次。

4.4 结果合理性检查清单

优化结果出来以后，第一件事不是画图，而是做合理性检查。我这里有一套固定清单，每次都会逐条过：储热罐SOC曲线是否始终落在0和1之间，有没有因为数值误差出现越界；全年累计充热量和放热量之差是否等于热损加弃热，能量守恒必须严格满足；最优容量是不是落在某个约束边界上，如果不是，很可能目标函数少算了一项成本；对电价曲线做±10%的扰动，最优容量不应出现剧烈跳变。

还有一个经常踩的坑是单位换算。E_tes 是MWht（兆瓦时热），但很多人会直接把它当MWh来用，导致汽轮机组发电时间算出两倍甚至三倍。正确做法是把储热容量转成“等效发电小时数”的时候，要除以汽轮机组额定热耗功率，而不是额定电功率。代码里最好统一使用热功率单位，所有电功率在目标函数里再通过效率折算，就能避免混乱。

5. 典型算例：从一组示例数据看优化效果

5.1 算例参数设置

为了把上面说的方法落到一个可感知的例子上，我虚构了一个50MW光热电站算例。参数不一定代表某个具体厂家，但量级和真实项目很接近。这样跑出来的趋势是有参考意义的。

DNI数据我取了一个中国北方光照较好地区的典型年逐时序列，年DNI超过2000 kWh/m²，这样光热电站的年利用小时数在2400小时左右，属于常见水平。

5.2 优化结果与对比

用上面这套参数，通过单层容量调度联合优化模型求解，最优储热容量约为4.5小时，按汽轮机额定电功率50MW折算就是225MWht。作为对比，传统经验方案通常会定成6小时，也就是300MWht。这两个方案的年运行收益、储热系统投资和综合经济指标差异很值得看。

从这个对比能读出两层信息。第一层，零储热方案的发电量最低，但因为没有储热投资，年净收益反而不比6小时储热方案差多少。第二层，优化4.5小时方案虽然年发电量比6小时方案少了一点点，但由于投资成本小得多，年净收益反而最高，并且储热从0到4.5小时贡献的收益增量非常明显，说明这部分投资花得值；从4.5小时到6小时，收益增量只有很小，已经覆盖不了额外投资。

在调度经济性的视角下，这个结论非常典型：最优容量不是落在“把白天多余热量全搬走”的位置，而是落在“尽量把高峰时段的发电量填满，同时不追求填满所有时段”的位置。很多光伏背景的同事会觉得4.5小时太少，但光热电站在设计时本来就不是为了最大化发电量，而是最大化每一度电的市场价值。

5.3 灵敏度分析：什么参数最“左右”最优容量

容量优化做完以后，我习惯再跑几个敏感性算例，否则参数取错了结论会站不住。先看峰谷价差的影响。如果峰值电价从0.12美元提高到0.16美元，最优储热容量会从4.5小时上升到5.5小时左右，因为高峰时段利润变厚，有动力多存热量来覆盖更长的晚高峰。如果峰值电价降到0.10美元，最优容量会降到3小时以下，因为储热转移电量的盈利空间变小了。

再看储热单位成本的影响。当前假设是30美元/kWht，如果技术进步把成本压到20美元/kWht，最优容量会跳到6小时以上。这说明储热容量对单成本的弹性很强。反过来，如果项目地处偏远，储热罐运输和安装成本高到50美元/kWht，最优容量可能降到2到3小时。单位成本是比电价还敏感的参数，所以在可研阶段一定要向厂家仔细询价，不要在模型里拍脑袋写个经验值。

工程建议是：不要只拿一个电价曲线和一个DNI年序列来出报告。至少要做“中方案、乐观电价、悲观电价”三个场景，每个场景下再看最优容量的波动区间。如果波动区间跨度和整数档位重合，比如在5到6小时之间震荡，那就说明5.5小时是一个稳健选择；如果在2到7小时之间乱跳，则说明模型对某些外部条件过于敏感，需要回头检查边界条件或者补充更多典型年数据。

6. 写在实际项目之后的一些补充经验

最后我再分享一个真实调试代码时的细节。储热容量变量到底取连续还是离散，这个问题看起来不起眼，实际影响很大。很多算法上来就把容量定义成连续变量，结果输出4.37小时、5.82小时这种数字。工程上买储热罐通常按0.5小时间隔或者固定罐容系列来选，你直接四舍五入到4.5小时或者6小时，然后把这个离散值重新固定回模型运行一遍调度，看经济性损失是否小于1%。如果小于1%，说明最优区间是平的，选哪个都行；如果损失大于2%，就要怀疑模型里是不是漏掉了和容量高度相关的约束，比如最大充放热功率限制、热损系数、或者集热场与储热规模的匹配关系。

这个“圆整后重跑”的动作，我在每个项目里都会做。它相当于给优化结果做了一次鲁棒性测试，也特别适合在评审会上回答“你为什么选这个罐容”的问题。我当时做完50MW算例后，还顺手把储热罐SOC的年曲线导出来看了一眼，确认在最热的连续晴天和最冷的连续阴天里，SOC都没有贴到0或者1的边界长时间跑，这就说明容量既没有配富余太多，也没有卡着约束走得太紧张。对于光热电站这类长寿命基础设施项目，储热容量的优化结果不能只追求理论最优，还得留出一点工程余量，让系统在真实运行中能扛得住数据偏差和突发天气。