很多做能源系統(tǒng)優(yōu)化的人一上來就盯著供給側那幾臺設備轉(zhuǎn)把燃氣輪機、電鍋爐、儲能電池的參數(shù)調(diào)到極致覺得把設備效率摳上去就萬事大吉。但真把系統(tǒng)跑起來之后你會發(fā)現(xiàn)社區(qū)這一級的綜合能源系統(tǒng)供給側設備就那么大再怎么優(yōu)化也就那幾個點的提升。真正能撬動系統(tǒng)經(jīng)濟性和低碳性的關鍵恰恰在用戶側那些看起來不起眼的柔性負荷——空調(diào)、熱水器、電動汽車充電樁甚至是一棟樓里的照明和電梯。這篇想分享的就是我近期在做的“考慮用戶側柔性負荷的社區(qū)綜合能源系統(tǒng)日前優(yōu)化調(diào)度”這個項目從建模思路、模型細節(jié)到求解過程踩過的坑都會攤開來說清楚。如果你正在做綜合能源系統(tǒng)優(yōu)化相關的工作或者想了解柔性負荷到底怎么參與調(diào)度這篇文章應該能幫你省下不少摸索的時間。這個課題的核心說白了就是把用戶側這些靈活的用電用熱需求納入到社區(qū)綜合能源系統(tǒng)的日前調(diào)度計劃里。傳統(tǒng)調(diào)度里用戶負荷是硬約束給多少就得滿足多少最多靠儲能和購電來削峰填谷。但當我們把一部分負荷理解成“可以商量”的——比如空調(diào)溫度高一度低一度不影響居住、熱水器提前兩小時燒好也不影響使用、電動汽車晚一個小時充滿也沒問題——調(diào)度就有了更大的操作空間。這個“商量”的量化過程就是柔性負荷建模而把它放進整個系統(tǒng)里做滾動優(yōu)化就是日前優(yōu)化調(diào)度的核心工作。1. 項目整體設計與思路拆解1.1 為什么把目光投向用戶側柔性負荷社區(qū)綜合能源系統(tǒng)這幾年提得很多概念上就是把電、熱、冷、氣幾種能源形式在社區(qū)尺度內(nèi)耦合起來通過設備轉(zhuǎn)換和儲能來提升整體能效。常見的配置是一臺小型燃氣輪機或者內(nèi)燃機做熱電聯(lián)產(chǎn)配上溴化鋰機組、電鍋爐、儲電和蓄熱罐再加分布式光伏。這個架構本身已經(jīng)很成熟真正難的是怎么把調(diào)度策略做好。我在做前期調(diào)研的時候發(fā)現(xiàn)一個很突出的問題大量文獻和實際項目里用戶側負荷都被當成剛性需求處理預測給多少就滿足多少。這在工業(yè)園區(qū)這類負荷集中、需求剛性的場景里說得通但在居民社區(qū)場景就很浪費——居民的用電用熱行為本身就有很強的彈性和時間靈活性你不管它它就是一個波動很大的剛性曲線你要是管了它它能幫你騰出很大的調(diào)節(jié)空間。柔性負荷參與調(diào)度的價值可以從一個簡單的例子看出來。假設某天傍晚光伏出力驟降而社區(qū)負荷因為居民下班做飯、開空調(diào)快速攀升這時候如果負荷全是剛性的系統(tǒng)只能靠燃氣輪機和購電頂上燃氣輪機要爬坡購電價格又處于峰時段運行成本一下就被拉高。但如果此時有相當一部分空調(diào)負荷和電動汽車充電負荷可以被延遲或者降功率運行調(diào)度系統(tǒng)只需要把這些柔性負荷的功率曲線往后再挪一兩個小時就能避開這個供需矛盾最尖銳的時段燃氣輪機不用滿負荷沖購電成本也能降不少社區(qū)的總運行成本自然也就下來了。1.2 社區(qū)綜合能源系統(tǒng)的整體架構做這個項目之前我先把系統(tǒng)的物理架構摸了一遍。我這里用的配置是社區(qū)綜合能源系統(tǒng)里比較典型的一種一臺微型燃氣輪機MT負責熱電聯(lián)供排煙余熱進溴化鋰機組制冷或者通過換熱器供熱光伏PV作為可再生能源主力接入電儲能ESS和蓄熱罐TST負責小時級能量平移外部電網(wǎng)作為電能補充燃氣鍋爐作為熱力備用的最后保障。能量流動關系是這樣的電母線側光伏、燃氣輪機發(fā)電、儲能放電和購電一起滿足社區(qū)電負荷含柔性電負荷熱母線側燃氣輪機余熱回收、燃氣鍋爐和蓄熱罐放熱一起滿足社區(qū)的采暖和生活熱水負荷含柔性熱負荷冷負荷則由溴化鋰機組和電制冷機聯(lián)合供給。因為燃氣輪機在電熱兩種能量之間具備強耦合關系所以整個系統(tǒng)的調(diào)度就變成了一個典型的混合整數(shù)優(yōu)化問題而且決策變量里還得加上柔性負荷的調(diào)整量模型復雜度比我最初預想的要高出不少。1.3 日前調(diào)度的邊界設定與策略選擇我選擇做日前調(diào)度而不是日內(nèi)實時調(diào)度有兩個原因。第一社區(qū)綜合能源系統(tǒng)里的燃氣輪機和儲能設備都存在明顯的啟停和爬坡約束實時調(diào)度很難兼顧這些設備的時間耦合特性而日前調(diào)度有完整的24小時信息能把設備運行狀態(tài)和儲能策略統(tǒng)一規(guī)劃好。第二需求響應和柔性負荷調(diào)整需要提前跟用戶溝通比如預約充電時段、提前調(diào)整公共區(qū)域的空調(diào)設定溫度這些都是小時級甚至日級決策不是實時候補來得及的。日前調(diào)度的輸入數(shù)據(jù)是預測得到的典型日的電負荷原始需求、熱負荷預測、光伏出力預測、分時電價和燃氣價格。輸出則是第二天0到24小時我為了計算方便把一天分成96個時段每15分鐘一個點所有可控設備的出力計劃和柔性負荷的調(diào)整計劃。這個調(diào)度計劃要在前一天晚上生成所以對求解時間有比較苛刻的要求不能算七八個小時才出結果否則天都亮了。這里還有一個策略選擇問題柔性負荷的調(diào)整要不要付出代價。我一開始天真地以為柔性負荷可以隨便調(diào)后來發(fā)現(xiàn)這顯然不對?？照{(diào)溫度拉高兩度用戶可能能忍拉高八度就要投訴了電動汽車說好了明早七點要用車你給它排到九點才充滿肯定不行。所以我在模型里給柔性負荷設置了可調(diào)區(qū)間并且引入一個用戶不滿意度系數(shù)調(diào)整幅度越大這個懲罰成本就越高優(yōu)化求解時會在省錢和保體驗之間自動找平衡。2. 柔性負荷分類與建模的實操細節(jié)2.1 柔性負荷分三類建模思路完全不同我根據(jù)負荷的物理特性和調(diào)節(jié)方式把用戶側柔性負荷分成三類可平移負荷、可削減負荷和可轉(zhuǎn)移負荷。分類不同建模的時候約束形式差別很大如果混在一起處理求出來的調(diào)度計劃在實際執(zhí)行時很大概率會出問題?？善揭曝摵傻湫痛硎窍匆聶C、洗碗機這類居民用電。它們的特點是整體用電過程時間固定電量固定但啟動時間可以提前或延后。建模時需要引入一個二進制變量表示啟動狀態(tài)配合持續(xù)時間約束保證它是一個連續(xù)完整的用電過程。這類負荷在數(shù)學上處理最麻煩因為二進制變量很容易把模型搞出很大的求解規(guī)模?？上鳒p負荷典型代表是空調(diào)、電采暖這類溫控負荷。它們的運行功率在一定范圍內(nèi)連續(xù)可調(diào)用戶舒適度允許的范圍內(nèi)可以適當降低功率。這類負荷用連續(xù)變量表示削減功率占比就行但需要額外加一條室內(nèi)溫度變化的約束把削減功率和溫度偏離關聯(lián)起來不然模型會把空調(diào)功率隨便削到底完全不管屋里是不是已經(jīng)熱得待不住人?？赊D(zhuǎn)移負荷典型代表是電動汽車充電樁。充電需求總量不變充電時段可以在時間窗內(nèi)靈活分配類似把一塊充電需求面積在約束時間內(nèi)平鋪開。這類負荷建模比較友好只需要設置充電起始時間和結束時間窗口再對總充電量做一個等式約束就行。2.2 溫控負荷建模的關鍵不能忽略熱慣性溫控負荷占居民負荷的比例超過三成尤其是夏季空調(diào)和冬季電暖器這部分必須認真建。我之前看到不少文章簡化處理直接把空調(diào)功率乘一個削峰系數(shù)就完事這太粗糙了?？照{(diào)降功率以后室內(nèi)溫度會慢慢升高這個變化是漸進的有很強的“熱慣性”。如果不把這層慣性的動態(tài)約束建出來調(diào)度結果可能在紙面上很好看實際執(zhí)行起來用戶早就熱得受不了了。溫控負荷我這里采用的是等效熱參數(shù)模型ETP一階形式就夠了不用上二階模型。核心公式T_in(t1) T_in(t) Δt / (R*C) * [T_out(t) - T_in(t) - R * Q_AC(t)]其中T_in是室內(nèi)溫度T_out是室外溫度R是建筑等效熱阻C是建筑等效熱容Q_AC(t)是空調(diào)的制冷功率對冬季制熱就取反方向。這個公式不復雜但參數(shù)標定很煩不同建筑的R和C差異非常大。我這里用了一個相對折中的辦法取社區(qū)建筑的平均值同時給室內(nèi)溫度約束留出舒適帶比如夏季允許24到27度只要預測溫度不越界就行。這樣即便個別建筑參數(shù)偏了也還有舒適帶的冗余兜底。2.3 電動汽車充電負荷的不確定性處理社區(qū)里的電動汽車充電負荷是近幾年增長最快的柔性負荷但也是最難建模的一個因為用戶插槍時間和目標電量都帶很強的隨機性。我這期項目里采取了一個工程化的簡化處理把社區(qū)里的充電樁統(tǒng)一看成“夜間可調(diào)度充電資源”所有車輛在回家時段比如18點到次日8點內(nèi)必須完成充電總量具體每個時段充多少由調(diào)度統(tǒng)一分配。這樣做的好處是模型簡單只需要一個總量約束加功率上下限約束不需要把每輛車的充電行為單獨建模。壞處是約束過于寬松調(diào)度會傾向于把所有充電功率都壓到谷電時段導致凌晨出現(xiàn)新的負荷高峰。后來我補了一個約束把夜間充電負荷在低谷時段內(nèi)的峰谷比限制在一個合理范圍比如不超過1.5這樣既利用了谷電也避免制造新的尖峰。這個思路在實際項目里驗證過很有效推薦有類似需求的朋友直接抄作業(yè)。2.4 用戶不滿意度約束怎么設才合理柔性負荷參與調(diào)度不能犧牲用戶體驗所以必須設置不滿意度約束。我采用的是“調(diào)整量懲罰”方式在目標函數(shù)里加一項對柔性負荷的實際調(diào)整量乘以一個懲罰系數(shù)調(diào)整得越狠懲罰越大。具體系數(shù)怎么定我參考了需求響應項目里常用的彈性系數(shù)法再用當?shù)鼐用耠妰r做個參照。比如舒適溫度調(diào)整1度折算成電費補償大約是0.1元每度電對應的調(diào)節(jié)量那懲罰系數(shù)就按這個數(shù)量級設置。實際跑出來的效果是系統(tǒng)優(yōu)先調(diào)度懲罰系數(shù)低的充電負荷其次才是空調(diào)類負荷這符合預期——充電時間稍微挪一下用戶幾乎無感但讓人家屋里熱兩度用戶肯定不樂意。3. 優(yōu)化模型搭建與求解的實戰(zhàn)過程3.1 目標函數(shù)經(jīng)濟性和低碳性的權重之爭這個項目的目標函數(shù)我用了兩個維度運行成本和碳排放。很多文獻喜歡直接把兩個目標加權成一個單目標我一開始也是這么干的但很快就發(fā)現(xiàn)權重系數(shù)極難定。成本權重給大了系統(tǒng)專門挑便宜的電買碳排放沒降多少碳排權重給大了為了多用光伏少用氣成本飆升得厲害根本不現(xiàn)實。后來我換了一種做法用“碳排放配額”的方式把兩個維度統(tǒng)一起來。系統(tǒng)給一個全天的碳排放額度比如按社區(qū)戶數(shù)和歷史排放水平定碳排放超標時要額外付費購買碳配額這個費用計入目標函數(shù)。這樣一來碳約束就從軟約束變成了有價格的市場信號優(yōu)化器在決策時會自動權衡購電、燃氣輪機和柔性負荷調(diào)節(jié)的組合最終得到的結果既不會出現(xiàn)成本失控也能實實在在降碳。這個思路參考了碳交易機制的邏輯在項目落地時說服力強很多。目標函數(shù)表達式整理一下min F Σ C_buy(t)*P_buy(t) C_gas(t)*F_gas(t) C_ess_oper(t) C_flex_penalty(t) C_carbon_over(t)C_buy是分時購電價P_buy是購電功率C_gas是燃氣成本C_ess_oper是儲能的充放電老化折算成本C_flex_penalty是柔性負荷調(diào)整的補償成本C_carbon_over是碳配額超標的懲罰成本。每一項的單位最后都要歸一到元別混著算。3.2 約束條件從設備模型到系統(tǒng)平衡約束條件是這個模型里最費心思的地方。我按三個層級搭設備自身約束。燃氣輪機有出力上下限、爬坡速率限制、最小運行時間和最小停機時間儲能電池有充放電功率限制、SOC上下限、充放電效率還要防止同一時段邊充邊放燃氣鍋爐同樣有出力限制。這些約束的物理含義很明確主要工作是把設備廠商給的技術參數(shù)翻譯成數(shù)學表達式。能量平衡約束。電平衡、熱平衡、冷平衡三個方程都要滿足公式形式是“供給側總功率 需求側總功率 儲能充電功率”。這一層約束看似簡單但最容易出錯的地方在于設備之間的耦合關系。最典型的是燃氣輪機發(fā)電功率和產(chǎn)熱功率不是獨立的而是強耦合的我用的微型燃氣輪機的熱電比大約在1.2到2.1之間會隨著負載率變化這個耦合關系沒建對后面熱平衡一定會出問題。柔性負荷相關約束。包括前面提到的可平移負荷啟動二進制約束、溫控負荷的溫度動態(tài)區(qū)間約束、充電負荷的總量約束以及所有的上下限約束。這一層約束變量多、類型雜是最容易引起模型求解困難的地方。3.3 求解工具選型YALMIP求解器還是直接用Python我這次用的是MATLAB YALMIP Gurobi的組合。YALMIP最好的地方是建模環(huán)境非常友好寫約束跟寫數(shù)學公式差不多不容易出錯Gurobi做混合整數(shù)線性規(guī)劃的求解速度在業(yè)界屬于第一梯隊對付我這個規(guī)模的模型沒有壓力。當然你也可以用Python的Pyomo或PuLP來搭效果差不多選哪個主要看你更熟悉哪種語言。我個人的習慣是模型探索階段用YALMIP因為改約束方便調(diào)試的時候可以直接看模型的結構要往生產(chǎn)環(huán)境部署了再遷移到Python。有一次我試過全用開源的CBC求解器跑同一個模型結果在同一個算例上CBC跑了將近40分鐘才找到可行解Gurobi兩分鐘就出最優(yōu)解了差距非常明顯。如果你的課題組沒有商業(yè)求解器授權可以考慮用SCIP開源求解器里它算是綜合實力比較好的。3.4 模型線性化處理把非線性約束變漂亮建模過程中遇到最多的問題是模型里存在非線性項Gurobi這類商業(yè)求解器雖然也能處理一些二次約束但求解速度會大打折扣。我的做法是盡可能把所有約束線性化。兩個典型的線性化場景第一個是燃氣輪機的熱電比變化原來是一個分段曲線我用了分段線性化處理把熱電比曲線用三到四段直線逼近精度足夠但求解速度提升非常明顯第二個是儲能電池的效率描述充放電過程中電池有損耗如果直接用非線性表達式求解起來很慢我改成固定效率系數(shù)加一個二進制變量防止同時充放電模型一下就干凈了。還有一個小技巧值得分享對于二進制變量和連續(xù)變量相乘的項比如“充電樁在某時段是否工作乘以該時段的充電功率”不要直接在模型里寫乘法要用大M法引入輔助變量和輔助約束來線性化。這個如果處理不當模型會變得非常難解甚至直接報錯。4. 日前調(diào)度全流程實操記錄4.1 數(shù)據(jù)準備預測數(shù)據(jù)的精度決定調(diào)度質(zhì)量做日前調(diào)度最怕“算得準但數(shù)據(jù)不準”調(diào)度結果再漂亮也是空中樓閣。我這次的數(shù)據(jù)準備分三塊負荷預測、光伏預測、能源價格。負荷預測用的是歷史負荷數(shù)據(jù)加溫度修正的方法。我是把過去三個月的社區(qū)總負荷曲線拿出來剔除節(jié)假日等異常日按“工作日/周末”分別做典型日曲線再用當天的天氣預報溫度做一次修正——溫度每偏離基準值1度冷熱負荷大約修正3%到5%。這個方法雖然簡單但在社區(qū)這個尺度上精度完全夠用沒必要上神經(jīng)網(wǎng)絡那套重型工具。光伏預測我用的是數(shù)值天氣預報的輻照度數(shù)據(jù)折算成光伏出力。這里有一個坑實際光伏出力還受溫度影響組件溫度升高后發(fā)電效率會下降所以夏季中午的時候光伏出力不是跟著輻照度走的需要額外加一個溫度修正系數(shù)。我一開始漏了這個修正結果中午時段的光伏預測值比實際高了8%左右導致調(diào)度計劃里購電安排偏少實際執(zhí)行時不得不臨時從電網(wǎng)多買高價電。電價和燃氣價格相對簡單直接用當?shù)仉娋W(wǎng)和燃氣公司的分時價格表。要注意的是不同季節(jié)的峰谷時段劃分不一樣做年度項目時要動態(tài)調(diào)整模型參數(shù)。4.2 模型參數(shù)設定計算步長和時段數(shù)的權衡我們這里把一天分成96個時段每段15分鐘。為什么選96而不是24主要原因是燃氣輪機和儲能設備的運行特性在小時級以下有比較明顯的變化15分鐘粒度能更準確地捕捉到負荷波動同時也跟現(xiàn)貨市場的交易時段對齊方便以后擴展到電力現(xiàn)貨市場環(huán)境。代價是模型規(guī)模明顯變大。96個時段乘上幾十個決策變量再加柔性負荷的整數(shù)變量我的模型大概有幾千個變量、幾千條約束。好在都是線性約束Gurobi解起來并不吃力一般一兩分鐘就能收斂到最優(yōu)解。如果你的模型求解時間過長可以先把時間粒度放寬到60分鐘跑通邏輯再逐步加密。4.3 核心代碼實現(xiàn)思路模型求解的核心流程大致是數(shù)據(jù)讀入、變量定義、約束寫入、求解、結果輸出。我這里的習慣是先用稀疏矩陣的方式定義變量索引然后逐塊添加約束每個約束塊用注釋標明物理含義。這里給出一個柔性負荷約束的代碼片段YALMIP語法方便大家快速上手%% 柔性充電負荷約束示例 % 假設: N_ev 個充電樁, T 個時段 % P_ev(t): t時段總充電功率, Pmax_ev: 最大總充電功率 % E_req: 總充電需求, eta_ev: 充電效率 P_ev sdpvar(1, T, full); % 充電功率決策變量 constraints [constraints, 0 P_ev Pmax_ev*ones(1,T)]; constraints [constraints, sum(P_ev)*dT E_req / eta_ev]; % 低谷時段集中度限制 indices_valley 33:56; % 凌晨2點到6點,即第33到56個時段 constraints [constraints, sum(P_ev(indices_valley)) 0.6 * E_req / eta_ev];這里dT是每個時段的小時數(shù)15分鐘就是0.25。最后那條約束是我加的“防負荷搬移過度”約束限制低谷時段的充電電量占總需求的比例不超過60%避免優(yōu)化結果制造新的凌晨負荷尖峰。4.4 求解器參數(shù)調(diào)優(yōu)可行解優(yōu)先還是最優(yōu)解優(yōu)先Gurobi求解這類模型通常很順暢但也遇到過幾天連續(xù)不收斂的“卡殼”情況。我的經(jīng)驗是先把MIPGap參數(shù)放寬到1%也就是允許優(yōu)化結果跟理論最優(yōu)值偏差在1%以內(nèi)這樣可以大幅縮短求解時間等模型邏輯驗證無誤、需要出正式結果時再收緊到0.1%。另一個有用的參數(shù)是TimeLimit我設置為300秒。如果超時我會把當前最好的可行解不是最優(yōu)解但工程上可接受輸出而不是一直等下去。實際項目中99%的情況下用MIPGap0.5%、TimeLimit300秒的組合幾分鐘之內(nèi)就能拿到穩(wěn)定結果。這里還要提醒一個細節(jié)Gurobi這類求解器的結果不是嚴格確定的尤其是整數(shù)變量特別多的時候不同版本或者不同機器上求解結果可能略有差異這不代表程序有bug。生產(chǎn)環(huán)境使用時最好把求解隨機數(shù)種子固定下來保證結果可復現(xiàn)。5. 算例設置與調(diào)度效果評估5.1 三種場景對比剛性負荷、價格型柔性、激勵型柔性為了驗證柔性負荷參與調(diào)度的價值我設計了三種場景做對比。場景A是基準場景所有負荷都是剛性需求也就是傳統(tǒng)調(diào)度模式場景B是價格型需求響應用戶根據(jù)分時電價自行調(diào)整用電行為但這種調(diào)整是分散的、用戶側的不納入統(tǒng)一優(yōu)化場景C是激勵型需求響應也就是我們這個項目的核心場景柔性負荷由調(diào)度中心統(tǒng)一優(yōu)化調(diào)度用戶獲得補償。為什么要做這個對比因為只有跟基準場景比過之后才能量化出柔性負荷調(diào)度到底帶來了多少收益。同時對比價格型和激勵型也能反映出“用戶自覺削峰”和“系統(tǒng)統(tǒng)一調(diào)度”兩種模式的效果差異這也是實際項目方案論證時最有說服力的數(shù)據(jù)。5.2 典型日調(diào)度結果分析我選取了一個夏季典型日高溫、光伏出力強、傍晚負荷尖峰高來做詳細分析。在場景A中傍晚18點到20點之間出現(xiàn)明顯負荷尖峰燃氣輪機幾乎滿載運行同時還要從電網(wǎng)購入大量峰段高價電。場景C中優(yōu)化系統(tǒng)在下午時段提前降低了部分空調(diào)功率室內(nèi)溫度從24度升到25度左右用戶幾乎無感把電動汽車充電基本安排到了22點以后傍晚的負荷尖峰下降了將近18%燃氣輪機負載率保持在高效區(qū)間避免了高負荷工況下的效率衰減。從日運行成本來看場景C相比場景A降低了約11.3%其中大部分來自峰段購電量的減少和燃氣輪機運行效率的提升。碳排放方面因為系統(tǒng)減少了峰段碳排放因子較高的購電全天碳排放也下降了約7.8%。對比場景B場景C的成本降幅更明顯說明統(tǒng)一調(diào)度比用戶自發(fā)響應更高效這也驗證了我們選擇“日前優(yōu)化調(diào)度”路由的正確性。5.3 柔性負荷調(diào)節(jié)深度與系統(tǒng)效益的關系我還專門做了一個敏感性分析看柔性負荷的可調(diào)比例從10%逐步提升到50%時系統(tǒng)效益指標的變化趨勢。結果很有意思當可調(diào)比例在10%到20%區(qū)間時系統(tǒng)成本下降非常明顯每增加1%的柔性負荷成本大約下降0.6%但超過30%以后邊際效益遞減明顯每增加1%柔性負荷成本只下降0.15%左右。這個趨勢背后的邏輯其實很好理解當可調(diào)比例較低時系統(tǒng)優(yōu)先調(diào)度最“便宜”的柔性負荷即用戶不敏感度最低的那部分比如充電樁用最小的代價換取最大的削峰收益當這些好調(diào)的負荷都用完之后繼續(xù)增加調(diào)度深度就不得不動那些用戶敏感度高的負荷比如空調(diào)溫度補償成本大幅上升凈收益自然就下來了。實際的工程啟示是社區(qū)在推進柔性負荷接入時不一定要追求把所有負荷都變成可調(diào)狀態(tài)把充電樁、部分溫控負荷等接入調(diào)度覆蓋大約20%到30%的峰值負荷就夠了這個比例下投入產(chǎn)出比最優(yōu)。6. 常見問題與排查技巧實錄6.1 模型無可行解怎么排查我在項目初期頻繁遇到模型提示“infeasible problem”幾乎崩潰。排查方法后來逐漸摸清了核心是懷疑“約束設硬了”或者“數(shù)據(jù)里有矛盾”。排查順序應該是先查能量平衡約束尤其是熱平衡和冷平衡看是不是燃氣輪機產(chǎn)熱和熱負荷之間的耦合關系寫錯了再查儲能的SOC約束看是不是初始SOC和充放電約束加起來導致無解最后查柔性負荷的總量約束看是不是充電需求寫成獨立固定值跟其他約束沖突了。YALMIP有個非常有用的命令在求解前用check命令檢查每條約束的可行性能幫你快速定位是哪條約束導致的無解。如果一批約束同時有問題優(yōu)先檢查模型里時段的索引是否正確很多無解問題就是索引錯了一位導致的。6.2 求解時間過長如何優(yōu)化如果你發(fā)現(xiàn)模型規(guī)模不大但求解時間異常長首先檢查是不是存在數(shù)值病態(tài)問題比如某些參數(shù)的量級差異過大電價是零點幾容量是幾千這種跨了數(shù)量級的系數(shù)會讓求解器的數(shù)值處理變得非常慢。解決辦法是對所有變量做歸一化統(tǒng)一在0到1之間。其次檢查二進制變量的數(shù)量?？善揭曝摵傻膯佣M制變量非?！鞍嘿F”如果社區(qū)里洗衣機這類負荷數(shù)量太多可以考慮用聚類方式把它們聚成幾組每組用一個代表變量表示求解速度能提升一個數(shù)量級。最后檢查約束里有沒有冗余的大M約束把問題的可行域切割得太碎。我之前習慣性地給每個設備都加上啟停二進制變量導致模型里整數(shù)變量爆炸后來精簡了部分連續(xù)調(diào)節(jié)設備的啟停變量求解時間從十幾分鐘降到了兩分鐘以內(nèi)。6.3 調(diào)度結果不夠“平”怎么辦有時候你會發(fā)現(xiàn)自己算出來的調(diào)度計劃負荷曲線依然存在小幅波動沒有想象中那么平滑。這多半是因為目標函數(shù)里沒有對設備出力變化的懲罰項優(yōu)化器傾向于在多個方案之間選一個“剛剛好”的解而不是“最穩(wěn)定”的解。解決方式可以在目標函數(shù)里增加一個小幅度的出力波動懲罰項比如對儲能充放電功率做一階差分懲罰對燃氣輪機出力也做類似的限制。這樣最終的調(diào)度曲線會平滑很多在實際執(zhí)行時對設備壽命更友好。6.4 調(diào)度結果與日內(nèi)實時運行偏差大還有一種常見情況是日前調(diào)度結果看著挺好但到第二天實際運行時發(fā)現(xiàn)實際負荷跟預測偏差太大導致調(diào)度計劃完全失效。這種問題根源不在優(yōu)化模型而在預測環(huán)節(jié)。我建議在日前優(yōu)化之后再加一層日內(nèi)修正機制每15分鐘更新一次超短期預測未來4小時窗口在這個窗口內(nèi)重新優(yōu)化一次但不改變?nèi)涨耙呀?jīng)確定的設備啟停狀態(tài)只調(diào)整連續(xù)變量的出力值。這樣可以兼顧日前優(yōu)化的全局性啟停決策和日內(nèi)運行的自適應性出力微調(diào)。關于這個問題我的體會是綜合能源系統(tǒng)調(diào)度真正的核心競爭力不是把數(shù)學模型做得多么精巧而是把預測、優(yōu)化和執(zhí)行三個環(huán)節(jié)之間的誤差閉環(huán)管理好。模型再精細預測跟實際對不上一切都是白算。6.5 用戶參數(shù)不準導致結果失真最后一個經(jīng)常被忽略的坑是用戶側參數(shù)的準確度。柔性負荷建模依賴很多用戶行為參數(shù)比如空調(diào)的設定溫度偏好、電動汽車的期望充滿時間、熱水器的用水時間分布這些參數(shù)在模型里都是做優(yōu)化的邊界條件。如果參數(shù)設置得跟實際情況偏差大——比如你把用戶室內(nèi)溫度容忍度設成3度實際用戶只能忍1度——那調(diào)度結果肯定會遭到用戶投訴。我的做法是在項目啟動階段做一個為期兩周的社區(qū)負荷數(shù)據(jù)采集通過智能插座和戶內(nèi)傳感器統(tǒng)計各類負荷的實際使用模式用這部分真實數(shù)據(jù)來標定模型參數(shù)。在項目持續(xù)運行階段每個月對比一次模型假設和實際行為的偏差做一次參數(shù)修正。聽起來工作量不小但這是保證調(diào)度策略能真正落地的必要投入。整體做下來我最大的感受是這個方向最大的難點不在數(shù)學建模而在工程落地。怎么讓用戶感覺不到調(diào)度發(fā)生怎么把不同設備廠商的數(shù)據(jù)接口打通怎么讓調(diào)度策略在異常天氣下依然穩(wěn)健——這些問題比推導一個漂亮的公式要復雜得多也重要得多。如果你也在做類似的項目建議把精力重點放在負荷機理的理解和真實數(shù)據(jù)的獲取上這些才是項目成敗的決定性因素。