两阶段鲁棒优化在微网容量配置中的应用：CCG算法解析与工程实践

简介本资源为面向电气工程与能源系统方向高年级本科生及研究生的毕业设计级算法实践包聚焦微电网多电源容量配置这一典型不确定性优化问题。针对风光出力与负荷波动带来的建模挑战资源完整提供基于min-max-min结构的两阶段鲁棒优化模型、列约束生成CCG求解框架及MATLAB实现代码并配套含276个历史运行数据表xls/csv、110个仿真结果矩阵mat、8个算法模块压缩包rar、5个核心文档docx/caj等共423个文件总容量89.47MB涵盖风电出力、负荷、温度、电价等多源时序数据及完整可运行代码体系。已有146人学习下载读者可直接复现论文《基于两阶段鲁棒优化算法的微网多电源容量配置》全部仿真实验获取含储能协调控制、不确定性调节参数设置、分时电价边界条件推导在内的全流程技术实现特别适合开展鲁棒优化建模、微电网规划或算法工程化验证的科研与课程设计工作。 搞微电网容量配置的人应该都体会过这种尴尬风光资源数据拿了一大堆算出来的配置方案一换典型日就翻车要么储能配多了浪费投资要么缺电率超标被业主追着改方案。我去年在知网下到这篇《基于两阶段鲁棒优化算法的微网多电源容量配置》时第一反应是终于有人把不确定性写进配置模型里了。这篇论文对应的源程序编号是39号资源作者在博客上有逐段解读代码和论文的对应关系做得比较清楚适合想从确定性配置转向鲁棒优化的研究者直接对照着看。这篇文章我不打算复述论文而是以拿到这套代码后怎么读懂它、怎么改它、怎么避坑为线索讲清楚三件事两阶段鲁棒模型到底在数学上做了什么、CCG算法从公式到代码是怎么落地的、以及你复现不同算例时最容易卡住的几个地方。如果你正在做微网规划、多能互补系统容量优化或者单纯想找一套能跑通的两阶段鲁棒程序作为模板这篇内容应该能帮你省下不少时间。1. 为什么容量配置必须换成两阶段鲁棒确定性模型失效的根源先聊一个所有做规划的人都会遇到的问题。传统的容量配置模型长这样给定一年的负荷曲线和风光出力曲线把风电、光伏、储能、燃气轮机的投资容量作为决策变量目标函数是整个寿命周期内的投资成本加运行成本最小。这个模型在数学上很规整求解也快但它有一个致命假设——明天风电出力是已知的。实际工程中风电出力和负荷预测误差动辄百分之二三十确定性模型给出的配置方案往往是在预测值恰好命中的虚拟世界里最优。你按这个方案建出来的微网一旦遇到连续阴天加高负荷储能容量可能不够用燃气轮机可能启动过慢最终结果就是切负荷。这也是为什么很多确定性规划做完之后还要专门做一次Monte Carlo校验一校验就露馅。两阶段鲁棒优化解决的就是这个问题。它的核心思路是把决策拆成两个阶段第一阶段here-and-now在不确定性尚未暴露时确定风、光、储、燃机的安装容量。这部分决策一旦做出短期内不能更改。第二阶段wait-and-see等不确定参数风光出力、负荷被揭示后在给定配置方案下做运行调度用最小运行成本去应对这个最坏情况。目标函数写成数学形式就是min_{x∈X} { c^T x max_{u∈U} min_{y∈Ω(x,u)} b^T y }外层min是投资决策内层的 max-min 表达的是在不确定集U中无论出现哪种风光出力场景微网都能通过最优调度把运行成本压到最低。换句话说这个模型不追求某一场景下的极致经济性而是追求所有可能场景下的可靠性底线。我拿到这篇论文的源程序时最先看的就是它代码里不确定集的定义部分。因为它直接决定了这个模型是真鲁棒还是象征性鲁棒。作者用的是盒式不确定集加预算约束也就是每个时段的风光出力都可以在预测值上下浮动一定比例但所有时段累加起来的偏离量不能超过一个预算值。这个设计的工程含义很明确完全允许每个时段都取最坏值会过于保守实际中风光出力不会每时每刻都在极端状态所以用预算参数控制整个调度周期内的总偏离程度。这套思路比随机规划好在哪随机规划需要给不确定性参数指定概率分布然后通过场景抽样把机会约束转化为确定性约束。概率分布本身哪里来靠历史数据拟合拟合错了模型就偏了。而且场景数量一多问题规模成倍上涨求解时间让人崩溃。鲁棒优化不需要精确的概率分布你只需要给出不确定参数的波动范围实用性要强得多这也是它最近几年在微电网领域被频繁采用的原因。2. 模型骨架拆解目标函数分段、约束分类与不确定集选择的门道把论文的数学模型剥开来看其实并不复杂核心就三块目标函数、运行约束、不确定集。但每一块都有很多细节容易被忽略我对照源代码逐一说明。2.1 目标函数投资成本和运行成本怎么拼到同一个式子里目标函数的第一阶段项是投资成本包含风电、光伏、储能的单位容量投资成本乘以各自的配置容量加上燃气轮机的单位台数成本乘以台数。第二阶段项是运行成本这一项在不同迭代轮次中会变化因为主问题里会不断加入新的最坏场景对应的运行变量集合。这里要注意一个容易犯糊涂的地方储能和燃气轮机的投资成本处理方式不同。储能是按功率和容量两个维度分别计价因为PCS变流器成本和电池本体成本是分开的而燃气轮机可能直接按台数算台数和容量是离散耦合的。在代码里这两个变量的类型也不同——储能容量是连续变量燃气轮机台数可能是整数变量。两阶段鲁棒模型第一阶段如果有整数变量CCG算法本身不受影响但对偶推导时要留意整数变量的存在会让第二阶段可行域的取值空间发生变化。运行成本主要包括燃气轮机的燃料成本、购电成本、弃风弃光惩罚成本、切负荷惩罚成本。这里有个技巧切负荷惩罚系数一定要设置得足够大。原作者在代码里把切负荷惩罚设为上千元每千瓦时目的就是让优化结果里尽量不出现切负荷情况。如果你自己改代码时把这个系数设小了模型会倾向于用切负荷来解决电力平衡配出来的方案会偏小这是初改者最容易踩的坑。2.2 约束条件二阶锥、线性化与对偶可处理性第二阶段运行约束是这套模型里最考功底的部分。基本约束包括功率平衡、储能充放电约束、储能SOC递推、燃气轮机出力上下限与爬坡约束、与外网交换功率约束、弃风弃光约束。其中储能SOC递推公式在鲁棒优化框架下比较特殊它含有状态变量SOC的时序递推导致后续时段的可行域会受前面时段决策的影响。处理方式一般有两种。一种是保留时序递推约束用大M法做对偶变换时把SOC变量也作为第二阶段变量一起处理另一种是把SOC递推消去转成功率累积约束降低子问题对偶变换时的复杂度。原程序采用的是保留递推的方式因为储能容量配置问题必须考虑SOC的时序约束否则SOC可能被模型钻空子——比如在两个连续时段内分别充电和放电但SOC状态完全对不上。另一个重点是约束的线性化处理。如果潮流计算采用DistFlow模型会出现电压幅值与功率的乘积项导致约束变成非凸。这篇论文的代码里用的是二阶锥松弛SOCP也就是把电压项的平方用一个新变量替换把非凸约束松弛成二阶锥约束。这一步在公式里只是一行替换但在代码里要小心二阶锥约束在Gurobi和Cplex中需要使用专门的二次约束接口而如果某些求解器不支持原生的二阶锥约束就需要用旋转锥近似或多面体逼近。原作者在博客里专门提到这一点我实际验证过用Gurobi直接写二阶锥约束就能跑通不用额外做割平面逼近。2.3 不确定集选择盒式、预算约束与避免双重极端不确定集是这套模型真正的灵魂。原文采用的是盒式加预算约束的不确定集数学上写作U { u_t : |u_t - u_t^bar| ≤ Δu_t, ∑|u_t - u_t^bar|/Δu_t ≤ Γ }这个形式大家都很熟悉但我需要提醒你的是预算参数Γ的取值不能拍脑袋。Γ决定了整个周期内偏离预测值的总预算Γ0退化为确定性模型Γ最大则退化为纯盒式不确定集每个时段都取边界最坏值。实际工程中Γ取T/3到T/2比较常见T是调度周期时段数。还有一个细节容易被忽略负荷和风电的不确定集是不是要分开建模。有些论文把风电出力和负荷放在同一个不确定集里这样会导致一个数学上的漏洞——当风电取最坏值低出力时负荷也取最坏值高峰负荷形成双重极端场景。这种场景在概率上几乎不可能发生但鲁棒优化不考虑概率它真的会按这个极端场景来设计系统导致配置结果过分保守。原程序的处理方式是分别对风电出力和负荷建立各自的不确定集并附加一个耦合约束两者偏离量之和不能超过某个上限。这样能有效规避双重极端带来的过度保守。我在复现别的论文时试过不加这个耦合约束的方案储能配置容量几乎翻了一倍投资成本暴增40%以上工程上根本无法接受。所以如果你要在自己的代码里修改不确定集记住这一点预算约束别只对单变量做要跨变量做总预算约束。3. CCG算法实现细节从论文公式到可执行程序的逐行对照两阶段鲁棒模型没法直接交给求解器求解核心原因是max-min结构没法直接线性化。目前最主流的解法是CCG列与约束生成也叫CCG算法。这篇论文的源代码用的就是CCG而且实现得比较规范适合作为学习模板。下面我按主问题-子问题-主循环三段来拆。3.1 为什么用CCG而不是Benders分解传统Benders分解处理两阶段鲁棒问题时是把子问题的可行域投影到主问题不断添加对偶割平面来逼近。但Benders对第二阶段问题的线性规划结构要求很高一旦第二阶段出现整数变量或非凸约束Benders的收敛性会变差。CCG的核心思想完全不同它不添加割平面而是直接在主问题中添加一组新的运行变量和约束对应子问题识别出的最坏场景。也就是说主问题的规模会随着迭代次数不断增大每次迭代都新增一个场景对应的完整运行约束块。这种方法的优点是收敛速度快尤其在第二阶段是线性规划时CCG往往只需要几次迭代就能达到最优解。从代码结构上看两者差异很明显。Benders的代码里主问题和子问题之间通过一个对偶乘子数组传递信息而CCG的代码里主问题需要动态构建约束矩阵每轮迭代就往模型里塞一个新的场景所以代码中会有一个循环内不断调用model.addVar和model.addConstr的过程。3.2 子问题里的max-min结构强对偶变换与M法处理双线性项CCG的第二步是给定第一阶段的投资决策x*求解第二阶段子问题max_{u∈U} min_{y∈Ω(x*,u)} b^T y这是个max-min双层问题。标准的做法是把内层min问题写成线性规划然后通过强对偶定理转成max问题与外层的max合并。合并之后目标函数变成对偶变量乘不确定参数的形式于是出现双线性项——对偶变量和不确定变量u的乘积。处理双线性项有两种主流思路。一种是利用u是0-1变量的特点直接线性化另一种是当u是连续变量时借助KKT条件或者大M法处理互补约束。对于连续型不确定变量常用的做法是用大M法来线性化变量乘积。这一步是整个代码中最容易出错的地方。我逐行看过原程序的处理方式作者把不确定变量u做了归一化处理将每个时段的实际出力表示为预测值加偏移量乘以波动幅度。这个偏移量在[-1,1]之间连续取值。然后对双线性项引入辅助变量z λ·u用大M法线性化。需要注意的是大M的取值不能随便给。给太小会切掉可行解给太大又会造成数值问题。原作者在代码里将M设置为运营成本系数的上限乘以总出力上限实际测试下来是比较稳妥的选择。3.3 主循环的上下界更新与收敛判据CCG主循环逻辑是初始化设置下界LB-∞上界UB∞迭代次数k0。求解主问题当前有k个已识别的场景得到最优解(x*, η*)设LB c^T x* η*。将x*代入子问题求解最坏场景u*和对应的运行成本f(x*)设UB c^T x* f(x*)。如果(UB-LB)/UB ≤ ε停止迭代否则把u*及其对应运行变量加入主问题kk1转步骤2。这套逻辑在代码里就是一层while循环但边界条件有个细节LB和UB的初始值设置反了会导致第一轮迭代直接进入死循环。我见过有人把LB初始化为正无穷UB初始化为负无穷循环条件判断一直满足程序跑了一天都没退出。此外收敛判据ε的取值也很关键。论文原文用的是相对误差1e-4我建议不要设得更小因为第二阶段是线性规划对偶变换后的数值误差本身就存在强行追求1e-6的精度只会让迭代次数暴涨最后得到的结果在工程上也不会有实质区别。4. 复现过程中最容易卡住的7个技术坑位源码能跑通不代表你能改得通。我在尝试修改这套代码适配不同算例的时候前前后后踩了不少坑下面按从易到难的顺序列出来供参考。4.1 典型日选择24小时还是8760小时原文算例用的是典型日24小时做规划但工程上更希望看到全年8760小时的运行模拟结果。这里有一个认知误区两阶段鲁棒优化中运行阶段不一定非要用8760小时全时段。实际上CCG算法每次迭代都会在子问题中求解一次全时段24小时或若干典型日的运行优化如果把T从24扩展到8760子问题的维度暴涨计算时间会呈指数恶化。一个折中的做法是先用多个典型日场景比如冬季典型日、夏季典型日、过渡季典型日做容量配置得到配置方案后再用8760小时的时序数据做全年运行校核看缺电率和弃风弃光率是否满足指标。这个方案在工程中可行性最高原程序的代码结构改造成多典型日也很方便——只需要把主问题中的运行约束块按照典型日索引复制几份即可。4.2 储能SOC初值处理储能SOC的初值设定会影响第一个时段的充放电决策。很多复现者把SOC初值设为0.5也就是半仓状态。但两阶段鲁棒的子问题会针对最坏场景做调度如果最坏场景要求储能连续放很多个小时SOC跑到下限后后续时段就无电可放这时候要么出现切负荷要么优化器给出一个很奇怪的调度方案。稳妥的做法是让SOC初值可调并在优化结束后检查SOC终值与初值是否一致。如果不同说明配置结果依赖初值假设工程上不够鲁棒。原文代码里SOC初值是一个可配置的参数默认设为0.2也就是20%的初始电量。我建议你根据实际场景改一改观察配置结果对初值的敏感度如果敏感度大说明储能容量配置偏紧。4.3 大M取值与尺度缩放前面提到子问题线性化需要大M这是整个程序中最容易引发数值问题的参数。我遇到过一次情况改动了成本系数单位从元/kWh改成万元/MWh之后大M没有同步调整导致子问题约束失效最坏场景找得不对主问题收敛到一个非常离谱的方案。这里分享一个通用的稳健设置方式遍历所有约束中涉及的变量功率、容量、成本系数计算出大M的理论上界然后统一乘以1.5的安全系数。同时建议所有发电功率、容量、成本统一用标幺值或者统一的单位MW/万元避免因为单位混用导致数值量级差太多。4.4 求解器选型与参数设置这套代码对求解器的依赖比较强。主问题是混合整数二阶锥规划MISOCP子问题是线性规划。Gurobi和Cplex都能处理但如果你用某些开源求解器二阶锥约束需要手动改写成线性约束否则无法求解。在实际测试中Gurobi 10.x版本跑这套代码非常顺畅。建议开启以下参数MIPGap设为1e-4主问题求解线程数设为物理核心数开启Presolve和CuttingPlanes的自动模式如果你的场景规模变大比如节点数增多或时段数增加主问题中变量数量会快速增长这时候可以考虑给主问题设置一个时间上限后续用已找到的可行解更新LB。不过要谨慎使用这个策略因为主问题解不好会导致UB长时间不下降最终需要的迭代次数反而更多。4.5 最坏场景识别后的场景冗余问题CCG算法在迭代过程中主问题会加入越来越多的历史最坏场景。随着迭代次数增加某些早期加入的场景可能会变得冗余——它们不再约束最优解。但在标准CCG中这些场景不会被移除。如果迭代次数不多通常小于10次这个问题不影响结果。但如果你给CCG设置了一个很紧的收敛容差迭代次数可能超过20次主问题规模就会非常大求解时间从秒级变分钟级甚至小时级。业内对这种场景有几种处理策略定期删除冗余场景、用更紧的收敛容差减少不必要的迭代、或者在子问题中加入热启动变量来加速收敛。原代码没做场景删减这无伤大雅因为论文的算例规模不大。但如果你要跑大规模算例建议在代码里加一个场景去冗余的模块每隔若干轮把主问题所有场景重新评估一遍如果某个场景对应的对偶乘子全部为0就把它从主问题中移除。4.6 收敛判据与计算结果的可视化验证很多复现者只盯着UB和LB的残差忽略了结果合理性验证。我通常会在CCG收敛之后把得到的容量配置方案放到确定性模型里跑一遍对比在预测场景下的运行成本再把方案放到一个独立生成的大量随机场景里做Monte Carlo模拟统计缺电率。这套验证流程虽然会增加一些工作量但能有效发现模型实现上的隐性错误。一个典型的隐性错误是储能系统的功率与容量约束单位不匹配。比如你把储能额定功率设为1MW、额定容量设为1MWh但在SOC递推约束中忽略了时间步长Δt导致SOC变化量和实际功率不一致。这类错误在CCG迭代中很难被察觉因为优化器会将错就错最终给出一套奇怪的配置方案。只有通过Monte Carlo验证才能暴露问题。4.7 从单一配置到群配置的扩展这套代码本身解决的是单微网容量配置。但实际工程中我们经常会面对一个园区里多个微网通过联络线互联的场景。群配置比单微网复杂得多每个微网有自己的电源和负荷微网之间可以交换功率还要考虑联络线的容量约束。扩展的方向很明确把第一阶段决策从单微网的电源容量扩展为每个微网的电源容量联络线容量第二阶段运行调度中增加微网间的功率平衡约束。CCG算法本身不需要改只需要在主问题和子问题的约束矩阵中增加联络线变量。改造难度不大但要注意子问题时序耦合——如果只给每个微网单独建模而不考虑联络线功率约束可能会出现两个微网同时在最坏时刻向对方卖电的逻辑错误。5. 博客解读与代码学习的配合使用方式最后聊聊怎么高效利用这份39号资源。这篇论文在知网可以下载源程序资源包里有完整的MATLAB代码作者博客有针对原理和代码的逐行分析。三个材料配合起来看效率会高很多。我的建议阅读顺序是先在知网下载论文把第二章的模型和第三章的算法流程通读一遍遇到看不懂的公式不要死磕先打开代码找到对应的实现段代码和公式对不上时再回来看博客里作者的解读。因为数学公式里的符号习惯每个课题组都不一样代码变量名才是最终解释权所在。来说说这套代码的实际运行情况。资源包里的主程序是在MATLAB R2021a环境下写的调用Gurobi求解器。如果你本机已有Gurobi许可证直接运行主脚本就能复现论文算例。运行时间方面原算例在普通PC上大约一两分钟就能收敛这个速度在学术研究里接受度很高。如果你要扩大算例规模我上面提到的几个优化点就要认真考虑了。不过也要提醒一点这套代码面向的是学术复现场景结构上牺牲了一些扩展性来换取可读性。如果你是第一次接触两阶段鲁棒优化建议先完整跑通原代码再逐步修改参数观察结果变化不要一上来就重写算法框架。先理解主问题如何累积场景、子问题如何通过对偶识别最坏场景再考虑业务扩展这样踩坑的概率会小很多。从我个人的体验来看这套代码是学习CCG算法非常好的起点。它的注释不算密集但变量命名清晰主循环和子问题函数的边界分明比很多论文的伪代码直观得多。你完全可以用它作为脚手架改成自己的微网模型、加入新的约束、甚至把单阶段随机规划也整合进来做对比实验。如果你决定深入搞两阶段鲁棒在微网配置里的应用下一组可以关注的议题是把风光的时空相关性信息融入不确定集、在子问题中用非预期约束处理多时段机组组合、以及把碳交易成本和需求侧响应纳入运行阶段目标函数。这些都是很自然的扩展方向论文和代码的基础框架已经为你铺好了路。本文还有配套的精品资源点击获取