1. 项目概述与核心痛点拆解虚拟电厂VPP这个概念这几年在电力系统里可以说是高频词中的高频词。简单说它就是把分散的分布式光伏、风电、储能、可控负荷等资源聚合在一起对外表现为一个可控、可调的电源或者负荷统一参与电网互动和电力市场交易。这种方式既解决了分布式能源单点容量小、波动大、难以调度的天然短板又能让分散资源产生规模化效益。但真正把虚拟电厂落到“能算、能跑、能用”的地步里面最难啃的一块骨头就是调度优化问题。最早接触这个方向的时候我以为虚拟电厂调度无非就是把设备出力排个表把成本算个最小化交给求解器一跑就完事。真正上手之后才发现如果只做一个时间尺度的优化要么是“计划赶不上变化”要么是“实时调节没有全局观”风光的随机波动、负荷预测偏差、电价实时变化这些不确定性靠一条时间线的静态优化根本兜不住。所以现在主流的研究思路都是把调度问题拆成“日前调度日内调度”两个时间尺度来做。所谓日前调度就是在每一天开始前基于预测信息负荷曲线、风光出力预测、电价曲线等制定未来24小时内所有可控资源的优化运行计划时间分辨率一般是1小时或者15分钟日内调度则是当日滚动执行的修正层通常采用15分钟甚至5分钟的滚动窗口基于最新实测数据对原计划进行局部调整消除日前预测偏差带来的供需不平衡。两个尺度层层嵌套、互相衔接构成了多时间尺度协调调度的基本框架。这也就是这个“【顶级SCI复现】【日前调度和日内调度两个时间尺度】虚拟电厂多时间尺度调度优化研究Matlab代码实现”项目标题的核心所在。如果你正准备写论文、做课程设计或者想把某个真实园区的小型虚拟电厂跑起来这篇文章会把两条时间尺度怎么建模、两个阶段怎么衔接、Matlab代码怎么组织、坑在哪里一五一十写清楚。既然是要复现SCI论文里的调度模型目标就很清晰了把数学模型看懂用Matlab把它写成可运行的优化代码再把计算结果与论文中的曲线、指标对得上。这不是对着代码读一遍就能交差的活中间涉及目标函数构建、约束转换、求解器配置、结果分析和误差调试每一步都有门道。下面我从方案设计、数学建模、代码实现、踩坑记录四个维度完整展开。2. 调度方案设计为什么必须分成两个时间尺度2.1 单时间尺度调度为什么不够用很多人第一次接触调度优化时会有一个疑问我直接做一个24小时全局优化把所有的预测数据都给进去求出来的全局最优计划不香吗何苦非要做两层。这个问题我当初也想不通直到真正跑了数据才明白全局最优计划在预测完全准确的理想条件下当然是最优的但现实世界不可能给你完全准确的预测。风电出力的波动、光伏午间的云层遮挡、负荷的突发变化任何一个环节出现偏差原来那个“全局最优”就会变成“实际不可行”或者“实际严重违背运行约束”的计划。比如日前计划要求某时段储能放电100千瓦结果实际负荷比预测高出一截或者光伏出力突然掉了一半储能再按原计划放电功率平衡就撑不住了。另一种极端思路是干脆全部实时调节、只做一个很短的滚动优化每一小步都拿最新的实测数据来算。这种方式的实时性好但同样有问题它只看得到眼前的几步缺乏对剩余时段整体经济性的统筹。比如午后电价处于高峰如果只做15分钟尺度的滚动优化储能可能因为局部最优而提前放掉了电等到电价更高峰时段反而没有余量可放全局经济性被牺牲得很严重。引入两个时间尺度的精髓就是用“日前全局计划日内滚动修正”来对冲这两种缺陷日前层负责大方向的时段协调它决定储能“什么时候充、何时放、留多少余量”、常规机组“开几台、出力基准是多少”可以说是运行基调日内层负责小偏差的消除它看到实际偏差后在尽量不背离日前计划大框架的前提下微调各资源的出力。2.2 日前与日内衔接的逻辑关系多时间尺度调度里最核心的设计问题不是两个层各自怎么做而是两个层怎么衔接。如果两层完全独立、各算各的那和单时间尺度没本质区别如果日内层把日前层的结果全盘推翻那日前层又失去了指导意义。主流做法是在日内调度模型里加一个“与日前计划的偏离惩罚项”或者干脆把日前计划值作为日内优化的参考基准让日内优化目标变成“运行成本最小偏离惩罚最小”的加权组合。我复现的这个模型采用了协调系数的方式处理衔接日内调度并不会将日前计划的储能SOCState of Charge荷电状态轨迹作为硬约束而是将其纳入目标函数中作为软性参考。实际效果是如果实际出力恰好与日前预测一致日内调度会自然跟踪日前计划的轨迹若出现偏差日内调度会灵活调整储能和可控负荷的出力来响应当前状态但是充电/放电的基本趋势比如午间充电、晚高峰放电不会被改变。这种方式比把日前轨迹做硬约束要稳妥得多——硬约束一旦遇到极端工况优化器直接给你提示“不可行”整个日内调度就崩了。除此之外两个时间尺度还有一层分工逻辑日前层侧重于“整个经济性全局最优”日内层侧重于“安全可行前提下的经济修正”。所以日前模型里的约束条件设置得很完整——机组组合、爬坡、储能容量、功率平衡都要覆盖日内模型则可以适当简化——比如固定常规机组的开停机状态只调整出力大小因为开停机动作在日前已经拍板了日内去动它反而会引起连锁反应。2.3 参考SCI文献中的经典建模套路从最近几年的高影响因子论文看虚拟电厂多时间尺度调度大体上分成三个流派确定性优化、随机优化、鲁棒优化。确定性优化假设预测值就是实际值建模和求解最简单适合做框架验证随机优化通过大量场景来刻画预测误差分布对数据要求高计算量大鲁棒优化则用不确定集来包络最坏情况求解结果偏保守但保护度强。复现SCI论文的时候一定要先看明白原文用的是哪个流派。我复现的这个模型走的是确定性优化的路线在日前层用典型日场景代表预测曲线日内层用滚动更新的实测数据来弥补预测偏差。实际效果在测试数据集上表现不错误差控制在10%以内运行成本相比单层调度降低了大概6到8个百分点。最妙的是这种“场景削减确定性优化”的组合对Matlab的求解器极其友好普通笔记本几分钟就能跑完一天的数据完全不用上高性能计算。这一点对做课题、发论文的人来说很重要——你不可能每调一次参数就等半天。3. 数学模型构建与SCI复现要点3.1 日前调度的目标函数与约束体系日前调度的目标函数主要考虑整个虚拟电厂一天的总运行成本最小。各项成本的分解大致是与外部电网的购电成本包含售电收益即当虚拟电厂向电网馈电时获得收益常规机组比如微型燃气轮机的燃料成本与启停成本储能系统的充放电老化折算成本需求响应资源的调度成本比如削减用户负荷时需要支付的补偿费用需要注意的是分布式光伏和风电的边际发电成本通常取零不算入目标函数这算行业惯例——反正太阳和风不要钱。但如果想做得精细可以给光伏和风电加上弃电惩罚项或者把运维成本折算进去这要根据SCI原文的设定来走不要自己乱加。约束系统是日前模型的重点每个约束都对应物理世界的规则第一类是功率平衡约束这也是最基础的约束。虚拟电厂与外部电网的交换功率加上内部各类电源出力分布式光伏、风电、常规机组、储能放电等于当前的负荷需求加上储能充电功率。这个约束没法开玩笑不满足的话整个优化结果就是空中楼阁。第二类是常规机组的运行约束包括出力上下限和爬坡速率约束。上限来自机组铭牌功率下限来自稳定燃烧约束爬坡约束确保机组相邻两个时段的出力变化不超过物理允许的调整速度。这个约束在做机组组合的时候尤其关键——如果忽略爬坡约束优化结果会出现“这台机组一个小时前还在满发下个小时突然降到零”的荒谬场景现实中根本做不到。第三类是储能系统约束涵盖SOC动态方程、充放电功率上限和SOC上下界。SOC动态方程是时间耦合的本时段结束时的SOC等于上一时段SOC加上充电效率乘以充电功率再减去放电功率除以放电效率最后除以电池容量。SOC本身也有运行范围一般为了保护电池寿命不会让它放到0%或充到100%而是限制在一个安全区间内比如10%到90%。3.2 日内滚动优化的模型简化与信息流日内调度和日前调度不同它不是一个24小时一次性求解的问题而是一个滚动时域优化问题类似模型预测控制MPC的思路。每一次滚动取未来一定时间窗通常是1到4小时用最新的预测数据和当前实测数据重新做一次优化然后只执行窗口内的第一步或前几步到下一个时间点再重复。这种滚动方式在数学上并不复杂真正需要想清楚的是“哪些状态量需要跨窗口传递”。储能的SOC是一个典型的跨时间状态量上一轮结束时储能的SOC是下一轮优化的初始状态如果这个值算错了或者传递错了后续所有结果都会跟着出错。这是复现时最容易翻车的地方代码报错往往不是模型的问题而是状态变量没有正确初始化。日内模型的约束比日前模型要简化一些。常规机组的开停机状态直接固定为日前计划的决定日内只见调整出力储能SOC的轨迹不用死死锚定日前值但目标函数里增加了对日前计划偏离的惩罚系数。偏离惩罚的权重大小值得反复调参——惩罚太大日内修正的灵活性被剥夺等于两层合成一层惩罚太小日内层可能跑出与日前计划完全相反的趋势虚拟电厂整体策略的一致性就崩了。我在复现的时候这个系数调了三轮最后定在0.3到0.5之间效果比较稳既保留了修正能力又不至于偏离过大。3.3 风光出力不确定性的处理方式如果完全忽略风光出力的不确定性日前调度计划在日内执行时大概率翻车。要在确定性优化框架内轻量地处理不确定性最常用的手段是“旋转备用约束”——说白了就是让常规机组和储能留出一定调节裕度以应对风光出力的突发波动。具体到建模上就是在每个时段设置一个正的备用容量要求这个备用容量必须大于该时段风光预测出力的一个比例比如20%或者一个固定数值偏差这相当于给系统买了一份额外的保险。这种做法相比鲁棒优化和随机规划要简单得多但效果已经很可观。我复现的模型采用的就是这个思路在日前模型中预留了10%到20%的备用容量日内模型再根据实际预测偏差滚动修正。整体测试下来虚拟电厂在最恶劣场景下也不会出现失负荷或大量弃光现象——虽然成本会略高一点但这是买确定性付出的合理代价。4. Matlab实现过程与核心代码解读4.1 代码总体架构与数据准备复现SCI论文的Matlab代码第一步不是写优化模型而是先把数据管道搭建好。我的代码结构大致分为五个模块数据初始化模块加载或生成负荷、风光出力、电价、市场信息的时序数据调度模型参数模块设置各类资源的物理参数机组功率、爬坡速度、储能容量输入预测场景模块对原始数据进行“典型日”提取形成日前调度的输入预测场景优化求解模块使用YALMIP工具箱构建决策变量、目标函数与运行约束调用求解器求解结果输出与分析模块生成运行曲线、对比分析、误差计算数据准备往往是整个复现过程中最耗时的环节。SCI论文使用的数据往往来自特定测试系统或真实微网数据集复现时需要找到合适的数据源。如果没有原始数据可以用相近气候条件和负荷特性的公开数据替代然后用论文中的曲线图进行核对校准——曲线形态大体一致、典型时段数值基本吻合就能接受。一个容易被忽略的细节是数据的“典型日提取”。SCI论文不可能把全年365天的数据全塞进模型一般会选取几个典型日比如夏季典型日、冬季典型日、过渡季典型日代表不同的运行场景。典型日提取方法通常包括K-means聚类算法、快速前向选择法或简单的等间隔抽样。我复现时用的是K-means聚类法效果不错——几个典型日的负荷和风光出力曲线形态差异明显覆盖了不同季节的运行特征。4.2 YALMIP建模与求解器配置建议Matlab里做优化建模我个人强烈推荐用YALMIP工具箱。它不是一个求解器而是一个建模层相当于把Matlab语言和求解器之间的翻译官。你不需要自己去查求解器API只需要用yalmip的语法定义变量、目标函数和约束然后交给你想用的求解器去算。我用的求解器是Gurobi原因很简单线性规划和混合整数线性规划的求解速度非常快学术许可证免费而且和YALMIP的兼容性极其稳定。先看决策变量定义的核心代码段%% 决策变量定义 % 调度时段数日前为24日内按滚动窗口设置 nHours 24; nUnits 3; % 常规机组数量 % 常规机组出力连续变量和开停机状态0-1变量 Pg sdpvar(nUnits, nHours, full); u binvar(nUnits, nHours, full); % 储能充电功率、放电功率、SOC Pch sdpvar(1, nHours, full); Pdis sdpvar(1, nHours, full); SOC sdpvar(1, nHours, full); % 与外部电网交换功率正为购电负为售电 Pgrid sdpvar(1, nHours, full); % 需求响应削减量 Pdr sdpvar(1, nHours, full);这里有个细节储能充电和放电功率为什么不直接用一个有正负号的连续变量而是拆成两个非负变量原因在于如果不拆开优化器可能同时出现“既充电又放电”的怪象——虽然结果上功率平衡可能没错但物理上根本不可能发生。拆成两个变量之后再给它们加一个互斥约束同一时刻至少一个为零或者通过在目标函数中设置小的惩罚系数来避免同时动作这样逻辑上就严谨了。目标函数的YALMIP写法相对直接%% 目标函数总运行成本最小化 Cost sum(Pgrid .* Price_DA) ... % 购电成本正/ 售电收益负 sum(sum(alpha * Pg beta)) ... % 常规机组燃料成本线性化 sum(cost_start .* max(0, diff(u, 1, 2))) ... % 启动成本 sum(cost_om_storage * (Pch Pdis) * dt_storage) ... % 储能老化成本 sum(cost_dr .* Pdr); % 需求响应成本 optimize(Constraints, Cost, sdpsettings(solver, gurobi, verbose, 2));需要特别注意的是常规机组燃料成本的处理方式。机组成本曲线实际上是二次函数aP^2 bP c但二次项会让模型变成QP问题求解速度明显变慢。SCI复现中一个非常常见的技巧是用分段线性化把二次成本曲线近似成几条线性段然后把成本写成“每段出力×对应斜率”之和——这样模型坍缩成MILP求解速度能提升一个数量级。我复现时把机组成本曲线拆成了3段线性近似误差控制在2%以内但求解时间从几十秒压缩到几秒这个权衡非常划算。约束条件的构建也直接在YALMIP里写以功率平衡约束为例%% 功率平衡约束 Constraints []; for t 1:nHours % 当前时段总出力光伏风电常规机组储能放电购电 % 等于负荷 储能充电 需求响应削减 Constraints [Constraints, ... Ppv(t) Pwt(t) sum(Pg(:,t)) Pdis(t) Pgrid(t) ... Pload(t) Pch(t) Pdr(t)]; end这个约束看起来简单实际调试时最容易出错的地方是符号方向。如果Pgrid定义为正数表示购电、负数表示售电那么等式右边应当是负荷加充电功率如果你把Pgrid的符号定义反了最后结果会出现虚拟电厂疯狂“倒贴卖电”的荒谬场景成本为负但物理上完全不可行。4.3 滚动日内调度的循环实现日内调度的核心逻辑是“滚动窗口状态传递”。我的实现方式是用一个for循环控制调度时刻每次取出当前时刻之后的一段数据调用一次优化然后把第一时刻的执行结果记录下来。关键代码结构如下%% 日内滚动调度主循环 MPC_step 4; % 滚动窗口长度小时 act_step 1; % 每次执行步数 % 初始化SOC状态 SOC_init 0.5; % 假设日内调度开始SOC为50% for k 1:horizon-1 % 计算当前窗口 [k, kMPC_step-1] window_idx k : min(k MPC_step - 1, horizon); % 取窗口内最新预测数据 Ppv_forecast Ppv_actual(window_idx); % 实际中需要预测这里用实际值带代表 Pwt_forecast Pwt_actual(window_idx); Pload_forecast Pload_actual(window_idx); Price_forecast Price_actual(window_idx); % 调用日内优化函数输入当前SOC状态和窗口预测数据 [x_opt, SOC_next] solve_intraday_mpc(SOC_init, Ppv_forecast, ... Pwt_forecast, Pload_forecast, Price_forecast); % 执行第一步记录实际出力 Pgrid_actual(:, k) x_opt.Pgrid(:, 1); Pch_actual(:, k) x_opt.Pch(:, 1); Pdis_actual(:, k) x_opt.Pdis(:, 1); % 更新SOC状态用于下一轮 SOC_init SOC_next; end这个循环有两点值得注意。第一每个窗口内调用solve_intraday_mpc时都要传入当前最新的SOC值而不是重新从默认值开始——否则储能电量就直接“凭空刷新”了物理过程不连续实验结果完全失真。第二每次只执行窗口的第一步不是把整个窗口的计划全部执行完毕因为窗口内的预测数据越到后面误差越大实际运行时必须持续刷新预测、滚动优化才能真正应对不确定性。在实际复现时我发现的另一个坑是日内模型里的日前计划参考值怎么传。你不能把整个24小时的日前计划全部塞进每个窗口那样模型会试图修正所有未来时段的偏差计算量无谓增大。正确做法是只取出当前窗口内对应的日前计划段作为软参考这样日内优化的视野始终保持在滚动窗口范围内。4.4 结果可视化与分析评价跑完代码之后结果分析也不能含糊。我自己习惯用几张核心图和一个统计表来呈现结果首先是“运行调度图”。横轴是时间纵轴是功率堆叠画出各资源出力、储能充放电、购售电功率的时序曲线。这张图能直观展示日前计划和日内执行之间的差异也是SCI论文中最常见的图型。其次是“SOC轨迹对比图”。把日前计划的SOC曲线和日内滚动优化后的SOC曲线画在一起能看到储能的实际运行轨迹和计划轨迹之间的偏差。如果偏差很大说明衔接参数没调好如果两条线几乎重合说明预测偏差本身就小。最后是成本对比统计表。至少应该对比三组日前计划成本、日内执行实际成本、以及一个“理想情况下完全不做日内修正”的对照组成本。理想对照组的计算方法是把日前计划原封不动搬到实际数据上校验如果有功率不平衡强制切负荷或弃光来补充计算出这个惩罚成本。这个对照组才是体现日内调度价值的标尺。5. 实操过程中踩过的坑与排查经验5.1 求解器配置与YALMIP的兼容性问题复现过程中第一个拦路虎几乎都是求解器环境配置。YALMIP本身只是一个建模框架真正计算要靠底层的求解器。常见的组合是Gurobi、CPLEX或者Mosek。很多学生用默认的linprog或者fmincon去求解MILP问题最后结果是“Infeasible problem”或者跑半天不出结果然后开始怀疑模型写错了——其实很可能是求解器不匹配linprog压根不处理整数变量。强烈建议安装Gurobi并配置好YALMIP的求解器路径。安装完成后先跑一个小的测试算例来验证YALMIP能否正确调用Gurobi% 验证求解器是否可用 clear; yalmip(clear); x sdpvar(1,1); optimize([x 0, x 2], x, sdpsettings(solver,gurobi,verbose,0)); value(x) % 应输出0如果这段代码跑出来不是0说明Gurobi的Matlab接口没有配置好或者license没激活。这种情况下你后面写任何模型都是白搭花十分钟先把这个地基打牢。5.2 模型不可行的定位思路做调度优化最磨人的问题就是“Infeasible”。模型报不可行不一定是你约束写错了有时候就是参数设置本身的物理矛盾。排查思路我一般按顺序来第一步把目标函数暂时设为零或者常数只求可行性。如果连可行解都找不到说明约束本身有矛盾。第二步逐个“放松”约束比如把储能充放电功率上限调大十倍把功率平衡等式改成不等式允许一个小偏差看哪个约束被放松后问题就变得可行矛头就指向哪里。第三步检查SOC动态方程的时间耦合是否正确。SOC更新公式里的时间步长单位、容量单位每个都是出错高发区。第四步检查变量索引对不对。Matlab从1开始编号如果你写了0索引YALMIP可能直接报错或者给你一个空变量。我印象最深的是有一次深夜调模型怎么都不可行最后发现储能放电效率写成了大于1的数值——物理上放电效率大于1意味着锂电池放电时不仅不损耗还能多发能量这当然可行不了。这个错误如果不仔细看排查一整天都发现不了因为公式语法完全正确只是参数数值反物理。5.3 求解速度优化与精度平衡如果模型不大但是求解很慢优先怀疑是不是引入了太多整数变量。机组的开停机0-1变量是MILP复杂度的主要来源。如果只是做多时间尺度调度这样中规模的模型3台机组、24个时段、储能、需求响应Gurobi几秒内就能解完。如果模型跑了几十分钟还没结果建议先看看是不是“约束写成了二次非线性”YALMIP里如果不小心用了两个变量相乘模型自动变成非凸问题求解时间就会飙到天上。再提一个数值尺度的细节。优化模型里功率动辄几百千瓦、成本动辄几万块、效率参数可能是小数点后三位这些量级不统一会让求解器内部出现数值病态。最稳妥的做法是对数据进行归一化或者把功率单位换成MW把成本换成万元让所有变量的数值控制在类似量级收敛速度和稳定性都会改善一个层级。同样一个模型归一化前后求解时间可以从1分钟降到5秒这不是夸张。5.4 与SCI原始结果对比校验的实操方法复现有风险因为顶刊论文的模型细节不可能全部公开。数据怎么预处理、目标函数的权重系数是多少、预测误差的方差数据从哪来这些关键细节往往被藏在脚注或附录里。我的建议是三步校验法第一步对形态画出调度曲线看总体趋势是否和原文一致。比如原文中储能是“午间充、晚高峰放”你复现的结果必须也是这个形态。如果形态都不一致数据或模型肯定有大问题。第二步对数值找相同时段的典型数值对比比如负荷峰值时段的购电功率误差在多少百分比以内。误差10%以内算合理超过20%就重新检查输入数据。第三步对指标对比总成本、可再生能源消纳率、弃光率等统计性指标。这些是SCI论文的核心贡献也是评审人最关注的数据。如果第三步对不上不要急着改代码先去看原文的场景设置。很多时候不是代码错是原文用了不同的电价方案、不同的储能容量或者不同的负荷数据差一步就会差出十几个百分点的成本差距。6. 常见问题速查与扩展方向建议6.1 常见报错与解决方案速查表现象可能原因解决方案YALMIP报错“No suitable solver”求解器未正确安装或路径未配置重新配置solver路径用验证脚本确认调用成功“Infeasible problem”约束之间物理矛盾或参数反物理按“目标置零→逐个放松约束→检查SOC迭代”的顺序排查求解时间过长存在二次项或非线性约束整数变量过多线性化成本函数减少机组组合的整数变量储能SOC出现跳变日内滚动时SOC初始值未正确传递检查每个窗口是否传入上一窗口的执行后SOC结果出现同时充放电储能模型用了单一变量而非两个非负变量拆成两个变量并添加互斥约束成本出现负数且极大Pgrid符号定义反了售电收益变成了购电收益检查功率平衡约束中的正负号方向6.2 从复现到发论文的几个扩展方向把SCI模型复现出来并不意味着工作结束了。真正的产出通常有两类一类是复现论文并确认结果可靠用作自己论文的基准方法另一类是在复现基础上做出实质性改进。可扩展的方向有很多。比较热门的一个方向是引入更复杂的不确定性处理方式——比如把日内层从确定性MPC升级为“随机模型预测控制”把风光出力的随机场景直接嵌入日内优化代价是计算量增大需要配合场景削减方法使用比如快速前向选择或基于概率距离的聚类算法。另一个方向是引入多智能体框架把虚拟电厂里的分布式资源建模成独立智能体各智能体局部优化、全局协调适合处理大量分布资源参与的调度场景。相比集中式优化多智能体框架在可扩展性和隐私保护上更有优势。如果手头有真实数据源也可以把模型从“仿真验证”推到“硬件在环测试”让代码直接对接真实的储能变流器或微电网控制器接口从论文到落地再往前走一步。6.3 关于代码组织与项目结构的一点体会最后分享一个代码组织习惯。做这类调度优化复现项目最大的风险其实不是某个模型写错而是实验记录混乱、改版改到忘记版本。我的做法是把配置参数独立成两个文件或两类命名空间一类放物理参数比如电池容量、机组爬坡上限这些参数一般保持不变另一类放实验参数比如备用容量比例、衔接惩罚系数、滚动窗口长度这些参数需要反复调。每次跑实验前只在实验参数区改不碰物理参数区跑完一组就记录一组结果。这套习惯让我在调参数的时候从来没有“回滚不了”的困扰。做研究型项目代码写得好不好不完全看架构多优雅更重要的是你下次跑还能知道自己上次跑了什么、调了什么、为什么调成那个值。那些SCI论文复现时调参花掉的大量时间其实一大半花在了“忘记上次怎么调”的代价上。另外实验参数里每个权重系数的改动都应该有记录像“备用容量比例从0.2改成0.3日内求解时间上升了15%但极端场景下失负荷概率从5%降到了0.8%”这种记录积累多了就是绝佳的论文实验素材。到时候写对比分析章节直接用这些记录整理成图表比临时补实验要省力得多。