冷热电多微网共享储能双层优化配置模型复现全解析

拿到这篇论文的标题时，我第一反应是：这又是一个读起来很顺、复现起来想摔键盘的双层优化模型。冷热电多微网、储能电站服务、双层配置，三个词拆开都懂，合在一起就是一个需要花几周时间从公式推导到代码落地的大工程。我花了将近三周时间把这个过程完整走了一遍，从最初的数学模型梳理，到上下层嵌套求解，再到最后从报错堆里debug出符合论文量级的结果。这篇文章就把这段代码复现之路的完整过程讲清楚。

如果现在的你正准备做类似的工作，或者正在被某个双层配置问题卡住，这篇内容应该能帮你省掉不少摸索的时间。我不会只贴最终代码，而是把每一步为什么这么写、哪些地方最容易翻车都尽量讲透。

1. 拿到论文别急着敲键盘：先把"双层配置"拆成物理系统加决策顺序

复现这类工作的第一步不是打开IDE，而是把论文里的系统图和数学模型揉碎了重新组装一遍。我见过不少同事一开始就对着公式抄代码，结果做着做着就发现变量对不上、约束少了耦合项，又得推倒重来。这套功夫省不掉。

1.1 冷热电多微网系统到底在干什么

所谓冷热电多微网，我的理解就是若干个微网区域各自包含电负荷、热负荷、冷负荷，同时由燃气轮机、燃气锅炉、吸收式制冷机、电制冷机这些设备来满足这些负荷。燃气轮机发电，余热通过余热锅炉回收成热能，热能又能驱动吸收式制冷机产出冷量，这个"以热定电"还是"以电定热"的调度逻辑就是你后续写约束的核心命题。

储能电站在这个结构里非常特殊。它不是一个微网自己的设备，而是作为公共服务设施，同时向多个微网提供储电、储热甚至储冷的容量服务。微网内部新能源出力大发的时候，可以把多余的电充给储能；负荷爬升的时候再从储能取电，避免从大电网高价购电。这种"共享储能"模式下，微网之间的用能行为会通过储能电站的容量约束耦合在一起，这是单微网模型完全不会遇到的逻辑难点。

我在复现时画了一张简化的能量流动图来帮自己理清物理关系：燃气轮机的燃料输入变成了电和烟气余热，余热一部分进余热锅炉供热水，一部分进吸收式制冷机供冷水；电网连接点可以买电和卖电；电储能、热储能、冷储能分别从对应母线上充能放能。这张图画清楚之后，后面写约束才不会漏。

1.2 上下层决策顺序：谁先拍板，谁后调度

"双层配置"这四个字的核心在于决策顺序，不是两个目标函数随便叠在一起就完了。我需要特别强调这一点，因为很多人复现双层模型时最容易犯的错，就是把上下层的目标硬塞进同一个优化模型里去求解。

上层做的是容量配置，回答的是"储能电站的额定功率和容量建多大、燃气轮机装几台、吸收式制冷机配置多少千瓦"这类规划层的问题。这些决策一锤定音，发生在微网实际运行之前。下层做的是运行调度，在给定上层的容量配置结果之后，针对每个典型日逐时段决策"燃气轮机发多少电、储能何时充电何时放电、吸收式制冷机承担多少冷负荷"。下层优化完成之后，会把最小运行成本返回给上层，上层根据运行成本加上投资成本去评估这一组容量方案是否划算。

本质上这是一个"先拍板、后调度、再评估"的三段式逻辑。我用一个更生活化的例子来解释：你要装修一套房子，上层就是决定空调买几匹、热水器买多大升数，这笔钱先花出去；下层就是确定每个月的电费燃气费怎么省着花。你不能直接用"总费用最小"把空调容量和每天开关空调的时间放在同一个方程里一次算完，因为每天怎么用空调是取决于空调装多大的。这就是双层问题的内在结构。

2. 从公式到约束：建模阶段最容易卡壳的三个地方

当我确认了系统的物理结构和决策顺序之后，就开始把论文里的数学模型转成代码可读的约束。这个阶段是复现过程中最需要耐心的一环，很多细节如果不处理到位，后续求解器会直接告诉你"infeasible"，或者更麻烦的是给出一个看起来合理实际上违反物理规律的解。

2.1 能量平衡约束：用"母线"模型替代直觉上的等式

电、热、冷三种能量各自要满足平衡约束，但是直接写"发电量等于用电量"这种直觉等式在冷热电联供系统里会出问题。我复现时采用的是"能量母线"的建模方式：把电母线、热母线、冷母线分别作为中间节点，所有供给侧变量加和等于所有需求侧变量加和。

以电母线为例：

code复制光伏出力 + 燃气轮机发电 + 储能放电 + 购电 = 电负荷 + 储能充电 + 电制冷机耗电 + 售电

热母线和冷母线同理：

code复制燃气轮机余热回收 + 燃气锅炉产热 + 蓄热槽放热 = 热负荷 + 蓄热槽充热
吸收式制冷机制冷 + 电制冷机制冷 + 蓄冷槽放冷 = 冷负荷 + 蓄冷槽充冷

这里就会出现一个非常重要的细节：燃气轮机的余热不是凭空产生的，它和燃气轮机的发电量之间存在热电比的关系。热电比大致是常数的时候，你可以用线性约束把发电量和产热挂钩。但有些论文会给可调热电比范围，这就多了一个决策变量。我先按照固定热电比的简化版本实现，等主流程跑通再扩展为可调热电比。

2.2 储能设备的SOC递推与"同充同放"问题

储能在优化模型里的建模是最容易导bug的地方。我习惯先写SOC递推方程再写功率边界约束，这两组没有搞定之前，别的约束都没意义。

电池储能的SOC方程很直观：

code复制SOC(t+1) = SOC(t) + (P_ch(t) * eta_ch - P_dis(t) / eta_dis) * dt / E_rated

这里dt是相邻时段的间隔（小时），E_rated是上层的决策变量，来自容量配置。最关键的坑在于，如果不加任何处理，求解器经常会让储能"一边充电一边放电"，这在实际物理过程中当然不可能发生。解决办法是把充电功率和放电功率表示成一对着二元变量控制的状态，或者用一组线性不等式让两者不同时为正。

我选择的是引入一个0-1变量，写成：

code复制P_ch(t) <= M * z(t)
P_dis(t) <= M * (1 - z(t))

实测下来的效果很稳定，虽然多了一个整数变量，但对Gurobi这类求解器来说根本不算压力。同样的逻辑适用于蓄热槽和蓄冷槽，只不过它们的"充放效率"通常只用一个系数，不像电池那样要考虑充电和放电两个方向的不同损耗。

还有一个24小时SOC回环约束要记得写。大多数微网优化采用的日运行模型要求储能设备在一个调度周期结束时的SOC回到初始值，这样才能保证每个典型日之间是独立可比的。这条约束我一开始漏掉了，结果算出来的最优方案是"第一天把电放光，第二天直接废掉"，这明显不符合调度逻辑。

2.3 目标函数的分层计量：投资成本与运行成本的记账方式

目标函数这部分相对直接，但也需要把口径想清楚。上层目标函数是把全寿命周期的投资成本折算到每年，加上年运行成本。我最初看到论文给的公式有点懵，后来梳理明白之后就很顺畅。

投资成本的等年值折算需要用到资本回收因子CRF：

code复制CRF = r * (1 + r)^n / ((1 + r)^n - 1)

其中r是贴现率，n是项目寿命期，储能电站一般取10到15年，燃气轮机等设备可以各取各的寿命。年化投资成本就是设备初投资乘以CRF。这里特别要注意，不同设备的寿命不一样，有的按10年折算有的按15年折算，混在一起算会出问题。

运行成本就清晰得多，是多个典型日场景的加权和：典型日加权系数乘以各时段的燃料成本加购电成本再减去售电收益。燃料成本等于燃气轮机耗气量乘气价，购电成本等于购电量乘分时电价。多微网场景下，每个微网的运行成本要分开算再汇总，因为各微网的负荷特性和设备配置可能完全不同。

3. 双层求解的路线选择：为什么最优解要"嵌套"而不是"一步到位"

建模做完之后，真正棘手的问题才开始：这个双层问题怎么解。我搜了一圈相关文献，方法五花八门，有通过KKT条件把下层问题转成上层约束的，有对偶变换的，也有用启发式算法在外部迭代的。最终我选择了后者，原因有两个：第一，下层是MILP问题，KKT条件处理整数变量非常麻烦；第二，我手上没有商业的MPEC求解器，而外层用群体智能算法是通用性最强、出结果最快的方式。

3.1 不能直接单层化的根本原因

如果下层问题是一个纯线性规划，你可以把下层用KKT条件等价替换，然后把双层问题变成一个带互补约束的单层问题。但实际的冷热电多微网下层调度里充满了二进制变量：设备启停标志、储能充放状态、购售电状态，这些都是整数。整数变量让KKT条件的适用性变得非常别扭，你转化完之后得到的是一个很难求解的数学规划问题，而且求解质量没有保证。

另一个思路是把下层目标函数替换到上层约束里，但这要求下层的对偶间隙为零，也就是必须满足强对偶条件。对纯线性问题可以这么干，但带整数变量之后强对偶不成立。所以我选择了外层启发式算法套内层MILP求解器的嵌套架构，这也是这类双层配置论文中最常见的代码实现路线。

3.2 外层粒子群优化，内层交给MILP求解器

我选择的外层算法是粒子群优化（PSO），原因特别务实：实现简单、参数少、对连续容量变量友好。储能额定功率、储能容量、燃气轮机台数等上层的决策变量就可以编码成粒子的位置向量。每个粒子都代表一组容量配置方案，评估这个粒子好坏的方式就是调用下层求解器。

整体的伪代码结构如下：

python复制for gen in range(max_gen):
    for each particle in pop:
        # 1. 解析粒子的位置向量 -> 容量配置参数
        storage_power, storage_capacity = decode(particle.position)

        # 2. 构建下层MILP模型，传入容量参数
        model = build_lower_model(storage_power, storage_capacity)

        # 3. 求解下层（Gurobi/CPLEX）
        status = model.optimize()

        # 4. 取下层最优运行成本，加投资成本，得到适应度
        run_cost = model.objVal
        fitness = annualized_invest_cost + run_cost
        particle.update_best(fitness)

    # 5. 更新全局最优，更新粒子的速度和位置
    update_velocity_and_position()

这个流程看上去很简单，但实现的时候有很多工程化的问题。比如每次迭代要对每个粒子都建一个下层模型并求解一次，如果你的粒子数是30、迭代次数是50，就意味着求解1500次MILP。如果下层模型规模很大，这个计算量会很惊人，我后面会在调试部分详细说这个问题。

3.3 上下层接口变量的传递设计

下层模型是上层的"适应度函数"，所以上下层变量名和参数名必须严格统一。我用一个字典来管理这些接口参数：

python复制config = {
    'E_bat_rated': particle[0],      # 电池额定容量
    'P_bat_rated': particle[1],      # 电池额定功率
    'P_gt_rated': particle[2],       # 燃气轮机额定功率
    'Q_ac_rated': particle[3],       # 吸收式制冷机额定冷量
}

每一个这样的配置字典都用来构建下层模型。这里有一个细节值得提醒：上层的容量配置值会直接出现在下层约束的边界条件里，如果粒子群在搜索过程中产生了一个不合理的值，比如储能功率为负，那么下层模型就会直接不可行。处理办法是在适应度函数里加一个可行性检查，碰到不可行方案就直接给一个很大的惩罚值，而不是让下层的求解器硬跑。

4. 代码落地：场景数据、矩阵化表达和求解器建模

到真正写代码的阶段，我需要处理的不只是数学公式的翻译，还有数据结构的组织、多场景的复用、以及与求解器交互的建模方式。这一节我把我实际用到的代码框架拆开来讲。

4.1 场景集与时间尺度的处理方式

全年8760小时的数据在整个双层配置里同时跑不现实，因为每个粒子都要做一次全年的逐小时调度。我采用的方案是聚合成典型日集——春夏秋冬各挑1到2个典型日，每个典型日赋予一个权重天数，最后运行成本就是各典型日运行成本的加权和。

典型日的选取方式我用了比较简单的K-means聚类，在全年风光出力和负荷数据上聚类，取每类的质心日作为典型日。这个方法不比启发式选取差，而且代码写起来简单：

python复制from sklearn.cluster import KMeans

# features 是全年每天的负荷+风光出力曲线拼在一起的特征
kmeans = KMeans(n_clusters=8, random_state=42)
labels = kmeans.fit_predict(features)

# 每个簇中离质心最近的样本就是典型日
typical_day_idx = []
for cluster_idx in range(8):
    # 找到该簇样本中离质心最近的一天
    ...

每个典型日内部再细分24个时段，这样下层模型的时间维度就是8个典型日乘以24小时。4个典型日的方案我试过，2个典型日的方案也试过，8个典型日在计算精度和耗时之间是个合理的折中。你要复现论文的时候，注意看看原论文是不是直接随机选了典型季节的某一天，如果是，直接抄它的选择方法更省事。

4.2 下层MILP模型在Gurobi中的组织方式

我选择用Python加Gurobi来建模下层。Gurobi对MILP的支持非常好，接口也直观。下层模型的核心是遍历所有典型日和所有时段来添加变量和约束。变量定义部分的典型写法如下：

python复制import gurobipy as gp
from gurobipy import GRB

m = gp.Model("lower_level")

# 索引
for d in range(n_days):
    for t in range(n_hours):
        # 购电功率，0到购电上限
        P_buy[d, t] = m.addVar(0, P_buy_max, name=f"P_buy_{d}_{t}")
        # 储能充放电功率
        P_ch[d, t] = m.addVar(0, P_bat_rated, name=f"P_ch_{d}_{t}")
        P_dis[d, t] = m.addVar(0, P_bat_rated, name=f"P_dis_{d}_{t}")
        # 充放状态 0-1变量
        u_ch[d, t] = m.addVar(vtype=GRB.BINARY, name=f"u_ch_{d}_{t}")
        u_dis[d, t] = m.addVar(vtype=GRB.BINARY, name=f"u_dis_{d}_{t}")

变量定义好以后就开始加约束。Gurobi支持使用Python的循环逐条加，也可以用addMConstr做批量矩阵化约束。对小规模模型直接循环加约束可读性更高。储能SOC递推约束和变量在上下限之间循环限制的写法如下：

python复制# SOC递推约束
for d in range(n_days):
    for t in range(n_hours - 1):
        m.addConstr(
            SOC[d, t + 1] == SOC[d, t]
            + (P_ch[d, t] * eta_ch - P_dis[d, t] / eta_dis) * dt / E_bat_rated,
            name=f"SOC_soc_{d}_{t}"
        )
    # 日首尾SOC回环
    m.addConstr(SOC[d, n_hours - 1] == SOC[d, 0], name=f"SOC_cycle_{d}")

# 禁止同时充放电
for d in range(n_days):
    for t in range(n_hours):
        m.addConstr(P_ch[d, t] <= P_bat_rated * u_ch[d, t])
        m.addConstr(P_dis[d, t] <= P_bat_rated * u_dis[d, t])
        m.addConstr(u_ch[d, t] + u_dis[d, t] <= 1)

这里有两点我需要特别指出。第一，SOC递推约束在P_ch和P_dis添加0-1变量后其实不一定还需要第三个约束来强制互斥，因为最优解天然会避免无意义的同充同放，但加上之后数值稳定性和求解速度更好，所以我保留了。第二，dt的单位一定要检查，如果负荷数据是小时级的，dt=1，如果是半小时级的就要写0.5，这个坑我踩过，后面详细说。

4.3 多微网边界的处理：共享储能耦合多个子系统的桥接

多微网和单微网最大的区别是约束里多了微网之间通过共享储能产生的耦合项。我在代码里没有把多微网的变量全部拉平到同一个大模型里去，否则维数爆炸。我的做法是每个微网生成自己的一套运行变量和本地约束，然后共享储能电站的容量和功率最终限制所有微网的充放电总加和。

以储电为例：

python复制# 每个微网i都有自己对共享储能的充放电功率
for i in range(n_microgrids):
    P_ch_from_mg[i] = m.addVars(n_days, n_hours, name=f"P_ch_mg{i}")
    P_dis_to_mg[i] = m.addVars(n_days, n_hours, name=f"P_dis_mg{i}")

# 关键耦合约束：所有微网同一时段对共享储能的充放电之和受限
for d in range(n_days):
    for t in range(n_hours):
        m.addConstr(
            sum(P_ch_from_mg[i][d, t] for i in range(n_microgrids)) <= P_bat_rated * u_ch[d, t]
        )
        m.addConstr(
            sum(P_dis_to_mg[i][d, t] for i in range(n_microgrids)) <= P_bat_rated * u_dis[d, t]
        )

共享储能电站自身的SOC只由总充放电功率决定，不用每个微网各自维护一个SOC。这样一个共享储能电站的分时容量分配就自然成为下层调度的决策内容。

5. 调试链路：从"求解失败"到"结果可信"的四步验证法

代码第一次能跑通的时候我心里其实没底。下层模型输出一个值，但是这个值对不对、物理上合不合理，都是未知数。我专门花了三天时间搭调试管线，把每一步的结果都拿出来和手算值、论文数值、能量守恒定律做对照。

5.1 先确定不可行问题出在哪一层

第一类报错是Model infeasible。这个报错出现的时候不要慌，也别去疯狂改约束，Gurobi提供IIS（Irreducible Inconsistent Subsystem）功能，能帮你找出导致不可行的最小约束集合：

python复制m.computeIIS()
m.write("model.ilp")

拿到model.ilp之后，逐条看里面的约束，90%的情况是某个容量配置参数导致的边界矛盾。我在调试时发现一个高频问题：上层粒子搜索时把储能额定容量设置成非常小的值，比如0.1kWh，但下层SOC递推约束里E_bat_rated出现在分母位置，导致数值异常。解决办法是在适应度函数里对容量过小的粒子直接判为不可行，不传给下层。

5.2 能量平衡校验：跑通不等于跑对

当模型能够稳定求解之后，就要做能量平衡测试。我在代码里加了一个后处理校验函数，把每个时段所有供给项和需求项各自求和，对比二者是否相等：

python复制for d in range(n_days):
    for t in range(n_hours):
        supply = (
            pv[d, t] + gt_power[d, t] + P_dis[d, t] + P_buy[d, t]
        )
        demand = (
            ele_load[d, t] + P_ch[d, t] + ec_power[d, t] + P_sell[d, t]
        )
        assert abs(supply - demand) < 1e-4, f"energy mismatch at {d}-{t}"

这条校验帮我抓到了大概三个隐蔽的约束缺失，其中印象最深的是一次热母线上的余热未经过余热锅炉而直接参与平衡。因为代码里写热平衡时引用了燃气轮机参数，但漏了余热回收效率系数，数值算下来始终有4%左右的偏差。检查到后来通过逐项打印才找到问题。

5.3 退化测试：把多微网退化成单微网来对照论文算例

验证模型结果正确性的一个很有效的手段是退化测试。把共享储能容量设得足够大，同时把所有微网的参数设成一致，这时多微网问题应该退化成若干个独立的单微网问题。把多个微网的独立单微网结果求和，和共享储能下的总成本对比。如果共享储能模式下总成本没有低于独立模式，那大概率是储能服务约束写得有问题。

我还做了一个更精细的验证：把储能容量设成0，此时整个系统应该退化成没有储能的冷热电联供系统。这个退化后的问题可以用等号约束直接验证手算，比如选一个没有任何储能的小时段，手动算一下电平衡和热平衡。

这种逐层退化验证的思路我建议每个复现者都保留，它比直接和论文大数值对比更能定位问题。

6. 复现之后的总结：参数换算、典型日选取和求解器调参的实战经验

到了这一节，代码已经能稳定跑出与论文数量级一致的结果了。但复现这个任务的价值不止于跑通，更重要的是过程中的参数细节、工程取舍以及那些能帮你自己后续做研究的经验沉淀。我按踩坑重要性排序讲几个最有普适性的经验。

6.1 单位换算：论文里最安静的"坑"

所有能源系统模型里，单位换算错误是最隐蔽的错误来源之一。我遇到过一个非常典型的情况：论文中储能容量单位是kWh，功率是kW，时间是小时，所有等式都很正常。但到了燃气轮机的效率参数，论文写的是每千瓦时发电消耗0.25立方米天然气，而气价的单位是元/立方米。这里你算出来的燃料成本单位是元，没问题。可如果参考文献里的效率是kJ/kW转换过来的，就需要做一次热值换算，差了4倍的情况非常常见。

我建议在代码里把所有单位转换写成命名常量，并且加清晰注释：

python复制# 天然气热值: 9.7 kWh/m3
GAS_LHV = 9.7  # kWh/m3
GAS_PRICE = 2.5  # 元/m3
GT_EFF = 0.35

# 燃气轮机燃料成本: 元/kWh
fuel_cost_per_kwh = GAS_PRICE / (GAS_LHV * GT_EFF)

这种方式既便于检查，也便于后续修改参数做灵敏度分析。

6.2 典型日数量对配置结果的影响不能拍脑袋定

我刚开始图省事用两个典型日，结果算出来的储能容量配置比论文小很多。后来增加到八个典型日，配置结果和论文基本吻合。原因很简单：两个典型日无法充分体现夏季午间光伏大发需要充电、晚间负荷高峰需要放电的完整过程，储能容量自然被低估。如果你做类似复现，可以先跑4个典型日和8个典型日对比，观察配置结果的变化幅度，变化小于5%的时候再固定下来。

6.3 求解器参数设置的影响：MIP Gap不能无脑设为0

下层模型是一个MILP，如果每次求解都要求MIP Gap为0，整个双层求解的速度会慢到让人崩溃。我的实测数据是：粒子数30、迭代数50、8典型日24小时的下层模型，Gap设为1e-4时单次求解约3秒；Gap设为1e-2时单次求解约0.6秒。外层PSO本身就不需要下层解到全局最优，配置路径上选出来的方案在不同粒子之间的差异远大于一个1%的MIP Gap误差。所以我把下层的MIP Gap设置成了0.01，整体迭代时间从半小时降到了六七分钟。

python复制m.Params.MIPGap = 0.01
m.Params.TimeLimit = 30  # 单次求解的保险丝

6.4 这份代码后续还能怎么扩展

复现完成只是第一步。我在这个基础上已经做过的扩展包括：把固定热电比改成可调热电比区间，增加了需求响应（可转移负荷）的建模，还把粒子群换成了遗传算法做对比实验。共享储能这个方向再往下走，还可以加储能租赁定价机制，让下层在决策充放电功率时考虑储能服务的实时价格，这会让上层决策和下层调度之间形成更强的经济互动关系。这些方向如果你之后要做自己的创新点，都有很大的挖掘空间。

最后再分享一个个人经验：代码复现这类工作，最忌讳的就是上来就抄公式然后期待一次跑通。把模型拆细、把约束分批加、每一步都用极端参数验证物理可行性，才是真正稳的路径。我之前调试热平衡偏差那几天，最后发现是余热回收效率漏了一个系数，当时真想摔电脑，但冷静下来靠的就是逐项打印对比这种"笨方法"。这种排查经验说不上高明，但在复现这种复杂多层优化问题上，它就是最快能让你从"报错堆里爬出来"的方式。