简介电力系统调度中风光出力和负荷预测总存在偏差确定性优化模型往往因缺少安全裕度而在实际运行中失衡。随机优化依赖场景分布却难保极端工况下的可靠性。鲁棒优化通过不确定集刻画参数波动范围以适度保守换取强鲁棒性而两阶段结构正好匹配微电网“先定启停、后调功率”的时序决策特征成为经济调度的主流建模方法。基于盒式或预算不确定集构建min-max-min目标利用列约束生成CCG算法迭代识别最恶劣场景并更新主问题可在可接受的计算代价内获得稳健调度方案。本文面向有一定运筹学基础的读者从模型结构、CCG求解原理到完整源码逐层拆解详解KKT转换、big-M取值、子问题非凸处理等关键工程细节并给出常见问题速查与调参经验帮助读者快速复现并灵活扩展两阶段鲁棒优化在微电网经济调度中的应用。 两阶段鲁棒优化在微电网经济调度里的地位不用我多说了。做这个方向的研究生、工程师基本都绕不开它但网上能找到的资料要么是论文里的数学推导堆得看不懂要么就是代码残缺不全、注释几乎没有复现起来极其痛苦。这个项目就是冲着这个问题去的完整源码、项目说明、超详细注释目标是让一个有一定运筹学基础的人拿到手就能把两阶段鲁棒优化跑起来并且能看懂每一行代码在干什么。我自己当时复现这个模型的时候前前后后折腾了两周踩了无数坑从不确定集建模到CCG算法的收敛判据每一步都有一堆隐性陷阱。所以这份源码里不仅把模型和算法写清楚了还把所有我踩过的坑、查过的资料、调过的参数都融进了注释里。这篇文章就带你从头到尾拆一遍这个项目的核心内容包括模型为什么这么建、CCG算法是怎么迭代的、代码里各个模块分别干什么以及复现过程中最常遇到的那些坑怎么绕过去。1. 微电网经济调度为什么最终选了“两阶段鲁棒优化”先搞清楚一个最基本的问题微电网经济调度到底在做什么以及为什么确定性模型不够用随机优化也有局限最后大家普遍转向两阶段鲁棒优化。这个决策本身有很强的逻辑链条不是拍脑袋选的。1.1 确定性调度模型的局限传统的微电网经济调度本质上是求解一个混合整数线性规划问题给定光伏、风电、负荷的预测值决策各台机组什么时刻启停、出多少功率同时还要满足功率平衡、爬坡约束、储能SOC限制等一大堆约束条件目标是让总运行成本最低。这是最经典的确定性优化框架数学模型清晰求解也快gurobi或者cplex几秒钟就能出结果。但问题在于这个框架假设所有输入都是准确的。实际运行中光伏出力受天气影响波动剧烈负荷预测也永远有偏差。你按预测值做的调度计划真到了实际运行那一刻很可能出现功率不平衡要不就是弃了大量风光要不就是切了负荷。而且确定性模型没有给“预测误差”留任何安全裕度系统运行在边界上稍微有点风吹草动就得重新调度。我在复现初期先跑了一个确定性版本当baseline结果风光的实际出力偏离预测值超过20%的时候系统的功率不平衡量直接飙升储能被逼到极限机组爬坡也跟不上。这个现象很直观地说明了为什么确定性模型在微电网这种高不确定性场景下不够用。1.2 随机优化与鲁棒优化的取舍既然预测有误差一个自然的想法是把误差建模成随机变量用随机优化的思路处理。常见做法是生成大量场景每个场景代表一种可能的风光出力组合然后优化所有场景下的期望成本。这就是经典的随机规划Stochastic Programming用场景集来逼近概率分布数学上成熟理论也漂亮。但随机优化有一个绕不开的问题场景怎么生成场景少了分布逼近不准确结果偏乐观场景多了问题规模指数级膨胀求解时间难以接受。而且随机优化给的是“期望意义下的最优”它不保证最坏情况下的安全。你用10万个场景训练出来的调度计划可能依然在某个极端天气下失稳。鲁棒优化的思路完全不同它不关心概率分布只关心不确定变量可能变化的范围。在这个范围内它寻找的是“即使最恶劣的情况发生调度方案依然可行且成本可控”的最优解。代价是结果偏保守但换来的是极强的鲁棒性。对于微电网这种对可靠性要求高、规模又不太大的系统鲁棒优化的保守性是可以接受的。1.3 两阶段鲁棒优化到底解决了什么问题很多刚接触这个方向的人会问为什么非得是“两阶段”原因在于微电网的调度决策天然分成两个时间尺度。第一阶段是“日前调度”day-ahead你需要提前一天决定机组的启停状态0-1变量必须提前定和电网的购售电计划。这些决策是“现在就要敲定”的等实际风光出力出来后没法反悔。第二阶段是“实时调整”real-time dispatch在已知实际风光出力后合理安排各机组出力、储能充放电、负荷削减量在不违背第一阶段决策的前提下让系统重新达到功率平衡。这种“先定离散决策、后调连续功率”的结构决定了模型必须分两阶段第一阶段做启停决策第二阶段做经济调度。两阶段鲁棒优化就是在这种结构下加入“最恶劣场景”的考量第一阶段决策要在所有可能的风光场景下都可调整、可平衡而第二阶段针对某个具体场景做最优响应。最终优化的目标是最恶劣场景下的总成本最小化这就是min-max-min三层的核心结构。一句话总结两阶段鲁棒优化把“预测不准”当作敌人来对抗通过CCG算法逐步找到让调度员最头疼的那个场景然后优化出应对它的最优策略。这种思想在整个电力系统领域都是通用的你掌握了这个模型后续做虚拟电厂、多微网协调调度都会轻松很多。2. 模型是怎么搭起来的不确定集、目标函数与约束解析理论学习归理论落到代码层面模型每个部分的建模方式都有讲究尤其是不确定集的构造、目标函数的min-max-min结构、以及第二阶段约束里那些容易出错的地方。这一节把这些内容挨个拆开讲。2.1 盒式不确定集用最少的参数模拟最恶劣场景两阶段鲁棒优化的第一步是定义不确定变量的取值范围。最常见也最好用的是盒式不确定集Box Uncertainty Set[ U { \xi \in R^N : \xi_i^{min} \le \xi_i \le \xi_i^{max}, i1,...,N } ]每个不确定参数光伏出力、风电出力、负荷在自己的上下界之间波动不考虑参数之间的相关性不考虑概率分布只考虑边界。这种不确定集的优点是建模简单代码里只需要给出每个预测值对应的上下界偏移比例。比如光伏预测出力是100kW允许偏差±20%那不确定集就是这个100kW为中心的[80kW, 120kW]区间。但单纯的盒式不确定集太“悲观”了因为它允许所有不确定参数同时达到最恶劣值。实际场景中光伏和风电同时达到最大偏差的概率极低。所以工程上更常用的是预算不确定集Budgeted Uncertainty Set[ U { \xi : \xi_i \hat{\xi}_i \Delta \xi_i^ z_i^ \Delta \xi_i^- z_i^-, \sum (z_i^ z_i^-) \le \Gamma } ]这里的思想是引入一个“预算”Γ限制所有不确定参数中最多只有Γ个可以偏离预测值剩下的都保持在预测值。Γ的取值通常取N的1/3到1/2这样既保留了鲁棒性又不至于保守到离谱。这个“预算”是鲁棒优化的精华所在它让你在“过度保守”和“不够鲁棒”之间有了一个旋钮。2.2 两阶段目标函数与min-max-min结构目标函数是整个模型的核心也是一个让很多新手头疼的三层嵌套结构。我直接把它剥开来看外层是min决策变量是第一阶段变量x机组启停、购售电标志位等这部分对应的是“日前决策的成本”包括机组启动成本、停机成本等。中层是max决策变量是不确定场景ξ风光出力、负荷它要找的是“让总成本最大的那个场景”。这一层就是鲁棒优化的灵魂所在调度员做决策时大自然和你对着干专挑你最难受的场景来。内层是min决策变量是第二阶段变量y机组出力、储能充放电、切负荷量等对应给定场景ξ后调度员的最优实时调整成本。整个目标函数可以写成[ \min_x (c^T x \max_{\xi \in U} \min_{y \in F(x,\xi)} d^T y) ]其中F(x, ξ)表示给定第一阶段决策x和不确定参数ξ后第二阶段变量y的可行域。用一句大白话解释这个三层结构我先把机组的启停计划定下来然后想象一个最坏的风光场景在这个场景下我再做出最优的实时出力调整让整个系统的运行成本尽可能低。由于处于“最恶劣场景”假设下真实运行的场景大概率不会比这更差所以第一阶段决策的安全裕度是足够的。在代码里内层的min直接求解会遇到困难因为它是嵌套在max里面的。目前最主流的处理办法是利用强对偶定理或者KKT条件把内层min转化为约束条件然后把max-min问题合并成一个单层的max问题。这个转化是代码实现里最核心也最容易出错的地方后面第3节会详细讲。2.3 约束条件的三个关键环节两阶段鲁棒优化模型的约束条件数量多、关系复杂但可以归类为三个部分等式约束功率平衡约束是最基本的等式约束在每个时刻都要满足系统的发电、储能放电、购电、弃电等于负荷、储能充电、售电、切负荷之和。这个约束在第二阶段中受不确定场景影响承担着“兜底”的作用。不等式约束机组出力上下限、爬坡速率约束、储能充放电功率和SOC上下限、联络线传输功率上限等。这些约束里含有第二阶段决策变量所以必须在第二阶段可行域中体现并且确保在最恶劣场景下仍然可行。整数约束机组启停状态、启停动作标志位等0-1变量。这些变量属于第一阶段决策不随场景变化是整个模型的难点所在因为混合整数规划本身求解难度就比连续优化高很多。在代码实现里这三类约束要分清楚哪些进主问题MP哪些进子问题SP哪些既在主问题又在子问题中。我见过很多初学者把约束位置放错导致主问题或子问题不可行。比如功率平衡约束是第二阶段的核心约束它必须放在子问题SP里不能放进主问题MP因为主问题里没有不确定变量把这个约束硬放进去会直接导致模型错误。2.4 引入0-1变量的原因细看代码会发现机组启停、购售电状态都用了0-1变量。很多第一次接触这个模型的人不理解为什么不能用连续变量来近似这些状态原因在于即使启停状态只是“开”和“关”两个选择它背后的物理含义也完全不同。机组开启之后无论出力多少都存在一个最小技术出力下限可能占额定出力的30%~50%。这个“最小出力”约束只有用0-1变量才能准确表达状态为0时出力必须为0状态为1时出力必须在[最小出力, 最大出力]区间内。这个逻辑用线性约束表达就是标准的“大M法”约束。购售电状态也是同理微电网和主网之间的联络线功率常见约束是“同一时刻要么买电要么卖电不能既买又卖”。这是个典型的互斥逻辑只能用0-1变量表达。有些简化模型会忽略这个约束但在实际工程中这个逻辑不能省因为同时买卖电力不仅不合理还会让优化结果出现无意义的套利行为。0-1变量的引入会让模型从LP变成MILP求解难度显著增加但这是必须付出的代价。CCG算法的每一轮迭代都要求解一个MILP主问题子问题虽然不含整数变量但在做KKT转换后也会变成一个带互补约束的数学规划问题需要线性化处理。3. 求解算法与代码实现CCG是怎么一步步迭代的模型建好之后最核心的问题就是怎么求解。两阶段鲁棒优化直接求解几乎不可能业界通用做法是用列约束生成算法Column and Constraint GenerationCCG或Benders分解。这个项目用的是CCG因为它在处理含0-1变量的问题上比Benders更稳定、收敛更快。这一节先讲CCG的原理再讲代码里主问题MP和子问题SP的构建方式最后给核心代码片段。3.1 为什么不用Benders而用CCG两阶段鲁棒优化的经典求解方法有两个Benders分解和CCG。Benders分解的思路是把子问题的最优值函数用一组割平面来逼近每轮迭代往主问题里加一条Benders割。CCG的思路则更直接每轮迭代枚举出一个新的最恶劣场景把该场景对应的第二阶段变量和约束直接加入主问题。这两种方法的收敛性差异在问题规模较大的时候非常明显。CCG的收敛速度通常更快尤其在第二阶段包含大量连续变量的情况下因为它直接列举场景而不是渐进逼近割平面的质量更高。代码里另一个细节CCG每轮迭代后要更新上界UB和下界LB。UB是当前主问题解带入子问题得到的最优值LB是主问题自身的目标值。当两者的gap小于设定阈值时收敛输出最优解。这个gap阈值通常设为1e-4到1e-6不同算例可能需要微调我见过有些场景gap取1e-6时迭代次数暴增到几百轮改成1e-4后十几轮就收敛了但解的目标值差异只在小数点后两位完全不影響工程决策。3.2 主问题MP的数学形式与代码实现主问题MP在第k轮迭代时包含所有已识别出的最恶劣场景ξ_1…ξ_k每个场景都有对应的第二阶段决策变量(y_1…y_k)目标函数是[ \min c^T x \alpha ]其中α是第二阶段成本的辅助变量满足 [ \alpha \ge d^T y_j, \quad j 1,...,k ]约束条件包含第一阶段的所有约束以及每个场景j对应的第二阶段约束。随着迭代轮数增加主问题的规模会线性增长因为场景数在增加所以到后期求解速度会变慢这是CCG的固有特点。在代码里主问题的gurobi实现大致长这样def build_master_problem(scenarios): m gp.Model(Master) # 第一阶段变量 x_start m.addVars(T, G, vtypeGRB.BINARY, namestart) x_shut m.addVars(T, G, vtypeGRB.BINARY, nameshut) x_onoff m.addVars(T, G, vtypeGRB.BINARY, nameonoff) # 辅助变量alpha alpha m.addVar(lb0, namealpha) # 每个场景对应的第二阶段变量 y {} for k, xi in enumerate(scenarios): y[k] m.addVars(T, G, namefy_{k}, lb0) # 添加该场景对应的功率平衡、爬坡等约束 m.addConstrs(...) # 目标函数 m.setObjective(cost_start cost_shut alpha, GRB.MINIMIZE) return m这里最关键的点是每个场景都生成一套独立的第二阶段变量并且共享同一套第一阶段变量x。这种“变量复制”思路保证了每个场景下的约束都是独立的不会相互干扰。场景多了以后内存会涨得很快但如果算例规模适中完全在可控范围内。3.3 子问题SP的KKT转换与强对偶子问题SP是CCG算法里最难实现的部分。给定第一阶段决策x子问题要求解的是[ \max_{\xi \in U} \min_{y \in F(x,\xi)} d^T y ]这是一个max-min问题没法直接丢给求解器。常见的处理思路是先固定x对内层min问题写出KKT条件或拉格朗日对偶然后用强对偶定理把内层min转化为max问题的约束。具体到代码里最常用的方式是先把内层min写成标准LP形式这里要求第二阶段变量y全是连续变量然后通过KKT条件把互补松弛约束线性化引入big-M参数将非线性项转为线性约束。最终SP变成一个带线性互补约束的max问题可以直接用gurobi求解。这个KKT转换过程我在注释里写得很详细这里简单提一下要点def build_subproblem(x_fixed): m gp.Model(Sub) # 不确定变量 xi在不确定集内 xi m.addVars(...) m.addConstrs(xi[i] xi_hat[i] delta[i] for i in ...) m.addConstrs(xi[i] xi_hat[i] - delta[i] for i in ...) # 第二阶段变量 y y m.addVars(...) # 原内层min问题的拉格朗日乘子 lambda_eq m.addVars(...) lambda_ineq m.addVars(..., lb0) # 强对偶条件内层min目标 对偶目标 m.addConstr(primal_obj dual_obj) # 互补松弛条件线性化用big-M法 m.addConstr(lambda_ineq[j] M * z[j]) m.addConstr((constraint_slack[j]) M * (1 - z[j])) v m.addVar(lb-GRB.INFINITY) m.setObjective(dual_obj, GRB.MAXIMIZE) # 外层max return m互补松弛的线性化是整个代码里最微妙的地方。它把“要么乘子为0要么约束取等号”这种非线性逻辑拆成了两个线性约束加上一个0-1辅助变量z。这个z的引入让子问题从LP变成了MILP求解时间变长但这是保证KKT条件被严格满足的必要代价。3.4 代码结构整体介绍整个项目的目录结构非常清晰拿到手之后能很快找到需要的文件microgrid_robust_optimization/ ├── main.py # 主程序CCG算法主循环 ├── models/ │ ├── network.py # 微电网网络拓扑与参数配置 │ ├── uncertainties.py # 不确定集定义与合作参数 │ ├── master_problem.py # 主问题MP构建 │ └── subproblem.py # 子问题SP构建 ├── solvers/ │ ├── ccg.py # CCG求解器封装 │ └── helpers.py # 对偶转换、KKT条件辅助函数 ├── results/ │ └── output.xlsx # 优化结果导出 ├── README.md # 项目说明文档 └── requirements.txt # 依赖库版本main.py里的主循环是理解整个算法流程的关键代码注释里已经把每一步对应到CCG算法的哪个环节都标出来了。建议拿到代码先跑一遍main.py对着输出日志看主循环里UB和LB的更新过程比看任何理论推导都直观。4. 实操中的坑和调参经验从迭代不收敛到模型验证模型和代码都已经就绪但真正跑起来的时候总会有那么几个问题卡住你大半天。这一节专门讲我在复现过程中真实遇到过的问题和解决方案希望帮你把这条路走顺一些。4.1 子问题非凸的两个坑子问题SP在KKT转换后理论上是一个数学规划问题但实际求解时有两个隐藏的非凸来源如果不处理会直接导致求解器报错或结果错误。第一个坑第二阶段变量必须全部连续。如果模型里第二阶段出现了0-1变量比如有些文献会把储能的充放电状态放在第二阶段KKT条件就不再适用因为强对偶定理不保证在混合整数问题中成立。解决思路是检查模型定义确保所有第二阶段决策变量都是连续的。如果你确实需要在第二阶段表达互斥逻辑通常是重新审视建模看能不能把离散决策转移到第一阶段。第二个坑互补松弛条件线性化后引入了辅助二进制变量z导致子问题本身变成了MILP。当变量规模较大时这个MILP求解很慢。一个常见的优化手段是把互补松弛条件中某一侧的big-M值尽量取小这样能加速分支定界。但M又必须足够大不能把最优解切掉这个平衡需要根据具体的量纲来调。我在注释里给出了默认的M10000但你跑自己的数据时一定要根据机组出力量纲重新评估。4.2 big-M取值对收敛性的影响big-M是互补松弛线性化和机组出力上下限约束里都会用到的参数。取值过小会切掉可行域导致模型得到次优解甚至不可行取值过大会让MILP的线性松弛质量变差求解器需要探索更多分支节点迭代速度大幅下降。我自己调参时发现big-M取值的合理范围一般在变量可能最大值的10倍到1000倍之间。比如机组最大出力是1000kW那big-M取10000左右比较合理太大比如1e8会让gurobi在求解子问题时卡到天荒地老。判断big-M是否合适的技巧把M缩小到当前值的一半重新跑一遍如果目标值变了说明M可能把最优解切掉了如果目标值不变说明M足够大可以尝试再缩小一些以提高求解速度。4.3 迭代不收敛的排查方法CCG算法不收敛或者收敛极慢是实际运行中最让人头疼的问题。我总结了几种常见情况的排查思路UB和LB一直不靠近中间差值振荡不下降。这通常是子问题SP求解出现问题比如KKT转换后的模型没有正确表达max结构或者互补松弛条件线性化有误。建议先检查SP单独求解时是否返回了正确的目标值用一个固定的x带入验证。LB增长缓慢收敛gap始终在0.1以上。这说明主问题添加的割平面力度不够可能是场景集合没有覆盖到真正的“最恶劣场景”。检查不确定集的边界设置是否合理预算Γ的值是否过小导致中层的max没有探索到足够恶劣的场景。每轮迭代子问题都能找到新场景但主问题加完约束后目标值几乎不变。这种情况下大概率是主问题模型有冗余约束或者目标函数中第一阶段成本占比过高第二阶段成本的变化对总成本的影响被稀释了。还有个小技巧把gap阈值先调到1e-2跑一遍观察迭代过程确认算法整体趋势是对的再逐步收紧阈值。不要一上来就用1e-6不然出了问题你都不知道是数值问题还是模型问题。4.4 模型正确性验证的三板斧做完一个优化模型怎么证明结果是可信的这里分享我常用的三个验证方法简单有效。第一板斧退化验证。把不确定集的范围全部设为0也就是预测值等于实际值退化成确定性模型跑一遍鲁棒优化看结果是否和直接求解确定性模型的结果一致。如果不一致说明模型哪里有问题这是最简单也最快的验证手段。第二板斧边界对照。把不确定集范围设为极小比如±1%鲁棒优化的结果应该比确定性模型的结果略差但非常接近。如果差距很大说明模型中第二阶段的调整能力不足某些约束过度限制了实时调整空间。第三板斧蒙特卡洛模拟。这是最贴近实际运行情况的验证方法值得花时间做。做法是先生成大量随机场景比如5000个每个场景代表一组风光出力序列。然后使用鲁棒优化的第一阶段决策在各自场景下求解第二阶段优化也就是把第一阶段变量固定带入求解一个完整的确定性经济调度问题统计所有场景下的成本分布、失负荷率、弃风弃光率等指标。如果鲁棒优化的决策在几乎所有场景下都能保持可行性且成本比确定性方案更稳定说明模型确实是有效的。我在项目里配了一个monte_carlo.py脚本可以直接调用训练好的第一阶段决策做验证输出统计报告和分布图强烈建议你跑一下这比任何理论分析都能直观地让你感受到鲁棒优化的价值。5. 常见问题速查表复现时随手翻问题现象可能原因解决方案子问题KKT转换后gurobi报“unsupported quadratic constraint”互补松弛条件未线性化检查是否用big-M法线性化所有互补松弛项主问题添加场景后求解时间暴增场景数过多导致变量膨胀适当降低CCG收敛gap阈值考虑用Benders割替代部分场景约束目标值为负或明显不合理目标函数符号方向有误检查min和max层的方向是否搞反风光出力始终取边界值不确定集没有“预算”约束确认是否添加∑z≤Γ的预算限制UB和LB的gap一直不收敛子问题SP求解失败或主问题割平面失效先固定x单独测试SP验证SP最优值是否合理第二阶段变量出现负值缺少非负约束检查所有y变量的lb是否设为0迭代中出现不可行解某场景下第二阶段无可行解增加切负荷或弃风弃光等松弛变量惩罚系数调大求解速度慢但结果合理问题规模大数值条件差尝试调小big-M检查约束矩阵是否病态上面这个表格是我在实际复现中最常翻阅的清单基本覆盖了90%的常见问题。如果遇到表格外的报错优先检查模型的维度匹配和变量索引很多报错本质上是维数错误比如时间步数T的长度不一致、机组索引错位等。6. 从两阶段到更复杂的扩展方向复现完这个项目、把CCG算法跑通之后你会发现自己对整个鲁棒优化的理解上了一个台阶。这时候你可能会想把它扩展到更复杂的场景这里给出两个我认为最自然的扩展方向也算是我个人踩过路之后的推荐路径。第一个方向是从单微网走向多微网或者微网群协调调度。多微网系统里每个微网有自己的光伏、风电、负荷和储能彼此之间通过联络线交换功率。这种场景下第一阶段决策变成了各微网的机组启停和联络线计划第二阶段则是各微网内部的功率平衡。CCG算法依然适用但子问题的规模会成倍增长KKT转换写起来会更繁琐。建议在动手前先把单微网的代码吃透理解每一行变量索引的含义再考虑扩展。第二个方向是把二阶锥约束引入模型处理配电网潮流。很多微电网实际运行在网络拓扑和线路潮流约束下纯功率平衡模型是简化过的。引入DistFlow或Branch Flow模型后第二阶段会包含电压幅值、电流平方等状态变量约束变成二阶锥约束。这时KKT条件依然可写但子问题变成一个二阶锥规划求解器需要用gurobi的conic约束。整体框架不变只是每一层的数学形式更复杂了。我个人建议先把基础版的两阶段鲁棒优化做到能灵活调整不确定集盒式、预算式、椭球式和灵活增加约束的程度再去碰扩展方向。基础打牢了扩展只是工作量问题不是能力问题。最后再分享一个小技巧跑实验的时候一定要把每一轮迭代的场景、UB、LB都记录下来画成曲线。当你看到UB和LB的差距随迭代次数逐渐缩小时那种感觉比任何理论推导都更能让你理解CCG算法的收敛过程。这套代码里的日志和结果导出功能就是为这个目的设计的。我至今还留着第一次跑通时画的收敛曲线每次调试模型遇到问题都会回头看看很快就知道算法在哪个环节出了岔子。希望这份源码也能成为你调试路上的一份可靠工具。本文还有配套的精品资源点击获取