Choosing Between Battery and Gas Peakers Without the Single-Event Trap

Every energy planner I know has a favorite horror story about the single-event trap. A utility picks battery storage based on one crazy heat wave, then finds the batteries fade too fast for the next summer. Or they pick a gas peaker for a cold snap, but the plant sits idle for years while fixed costs pile up. The problem isn't the technology—it's the method. You can't size peaking resources by looking at one extreme hour, then assume that hour repeats forever.

This article gives you a repeatable workflow to compare batteries and gas peakers across multiple years, multiple revenue streams, and real-world constraints. It's built for planners who already know the basics but want to avoid the traps that come with single-event thinking. We'll walk through who needs this, what data you need upfront, the core analytical steps, tools that make it work, variations for different grids, common failures, and a practical FAQ.

Who needs this and what goes wrong without it

Utility planners stuck with single-scenario IRP models

You run the one big winter storm case. Battery wins. You run the summer heat-wave case. Gas peaker wins. So you average the two and call it a day—wrong move. What actually happens is your portfolio tilts toward whichever technology happens to shine in whatever extreme scenario you modeled last. I have watched utilities commit to 200 MW of storage because a single polar-vortex event showed five hours of capacity need, then discover the next summer’s wildfire-driven evening ramp eats that battery in ninety minutes. The trap isn’t bad data—it’s the unstated assumption that one extreme event represents all future extremes. That sounds fine until ratepayers fund unused gas capacity for two decades.

The tricky part is that single-event analysis systematically overvalues whichever asset performs best in that one scenario—and this bias compounds. Quick reality check: if your only test is a three-day cold snap, combined-cycle gas looks cheap because you ignore its start-up penalties during frequent swing events. If your only test is a mild spring weekend, batteries look like gold because you never stress their energy throughput limits. Neither mirrors actual fatigue. Regulators reviewing resource adequacy filings see a neat cost curve and approve—but the curve hides that the portfolio fails under a different extreme, same probability, just not in your file.

“We ran the December 2022 event and storage was perfect. Then June 2023 happened—same battery, different weather, zero capacity after hour two.”

— Planning engineer, after two back-to-back filings rejected on cost grounds

Developers pitching storage vs. gas to skeptical boards

Board members love a single number. “This battery beats gas by 14% in Net Present Value.” They don’t ask which scenario produced that 14%. When I sit with developers, the pain point is always the same: the board sees one winner, signs off, then blames the developer when real operations diverge. The catch is that developers know the portfolio needs both technologies, but single-event analysis forces a false binary. You pitch hybrid—storage for daily cycling, gas for multi-day resilience—but the single-event model says “choose,” not “combine.” That hurts credibility.

What usually breaks first is the revenue guarantee. If your board-approved case relied on a specific event recurring annually—say, the August 2020 rolling blackouts—you own that bet. When next year brings a spring flood instead of an August heat wave, the gas peaker runs zero hours and the battery cycles daily on solar firming. Suddenly the 14% advantage flips. Without multi-scenario framing, the board sees failure, not different success. I have fixed this exact problem by showing three event types side by side—not averaged, not weighted, just honest. Boards tolerate uncertainty; they despise surprises.

Regulatory staff reviewing resource adequacy filings

Regulators face the worst version of this trap. They receive one filing per technology, each optimized for the applicant’s favorite scenario. The gas advocate chooses a December cold snap. The storage advocate picks a summer evening ramp. Both are real. Both are defensible. Neither alone tells you what the combined fleet will do in a May wildfire season with cloud cover and transmission congestion. The missing piece is concurrent stress—not just weather, but fuel supply, maintenance outages, and market pricing all aligning against one technology.

Most teams skip this because it’s messy. They want a single cost number to compare. But the regulatory risk isn’t cost—it’s reliability failure hidden behind an optimistic single-event assumption. One concrete anecdote: a Midwest ISO filing showed gas peakers at 92% availability during a winter storm. Excellent, right? Except the storm froze the gas supply chain. The plant was available; the fuel wasn’t. Single-event analysis never caught that because it modeled the plant, not the system. The fix isn’t harder math—it’s honest scenario variety before you lock in the portfolio.

Prerequisites: data and assumptions you must settle first

Load shape data: hourly profiles for at least 5 years

The trick is that one year of hourly data looks like a sure thing—until a mild winter or a Covid lockdown skews your peaks. I have seen teams build a whole business case on 2020 load shapes and then wonder why their gas peaker sits idle in 2023. You need five years minimum, and honestly seven is better. That smooths out the weather anomalies and catches the slow creep of electrification—heat pumps, EV charging clusters, industrial retrofits. What breaks first is the shape of the summer ramp, not the annual total. A single August afternoon that hits 98°F with low wind will expose a battery that was sized for the 90th percentile, not the 95th. So pull hourly resolution, not daily averages; a 12-hour block that averages 50 MW may hide a 70 MW spike from 4 to 6 PM. Check for missing timestamps too—gap-filled data from the utility often flattens real spikes.

Most teams skip this: cross-referencing your load profile with the local capacity auction results. That sounds fine until you discover your ISO awards capacity credits based on the top 10 coincident peaks, not your facility's individual max. Your battery might be a hero on your own load curve but a nobody on the system peak. — that mismatch alone can swing payback by three years.

Not every energy checklist earns its ink.

Gas price forward curves and volatility

Henry Hub forwards are a starting point, not a finish line. The catch is that gas peakers burn physical gas, and the delivered price includes basis differentials, pipeline capacity charges, and daily balancing penalties—none of which show up in the NYMEX settlement. I fixed a model once that used a flat $3.50/MMBtu assumption; the actual winter peak cost was $8.20. That hurts. You need a forward curve that spans your project horizon, but also a volatility overlay for the cold-season months when peakers actually run. A battery doesn't care about fuel cost—that's its structural advantage—but if your gas scenario uses a flat forward curve while your battery scenario assumes perfect arbitrage on real-time prices, you're comparing apples to a Unicorn.

The prudent move: run at least three fuel-price regimes—low, mid, high—and watch what happens to the peaker's dispatch frequency. When gas hits $6, does the battery start winning on operating cost alone? When it drops to $2.50, does the peaker reclaim the stack? That tension exposes whether you're betting on fuel markets or on technology.

Battery degradation parameters (calendar vs. cycling)

Wrong order here kills the analysis. Calendar degradation—the capacity fade that happens whether you cycle or not—is often buried in a footnote. But that flat 2% annual loss compounds. A lithium-ion battery that loses 20% nameplate capacity by year 10 doesn't just serve less energy; it fails capacity accreditation tests earlier. And cycling degradation is worse than most spreadsheets admit. Each full-equivalent cycle eats about 0.03–0.05% of capacity, but that number climbs as the battery ages and internal resistance rises. Quick reality check—if you model 365 cycles per year for 15 years, you're past 5,000 cycles; many LFP datasheets guarantee 4,000 cycles to 80% retention. The seam blows out right around year 12.

What I see most teams miss: the interaction between calendar and cycling degradation in the same year. A battery that sits idle for six months (calendar hit) and then cycles hard for six months (cycling hit) takes a double dip. The gas peaker has no equivalent fade, but it has start-up wear and maintenance overhauls that hit at fixed intervals—not gradually. Both degrade; the shape of that degradation curve dictates which asset looks better in year 14.

Capacity market rules and accreditation methods

A gas peaker gets accredited for its nameplate capacity minus forced outage rate. Simple. A battery gets accredited for a fraction of its nameplate—often 50–70% of nameplate in the first year, dropping each year as the battery degrades. That sounds fine until you realize the capacity payment per MW is the same for both. If your battery is effectively a 0.6 MW asset for market purposes but you paid for 1.0 MW of hardware, your payback just stretched. Some ISOs now require performance testing during the peak window—if the battery can't sustain 4-hour discharge at full power, the credit shrinks. The gas peaker has a simpler path: show up, run, get paid. But it burns fuel to do it.

One concrete anecdote: a client in PJM modeled a 20 MW / 80 MWh battery with a fixed 0.8 accreditation factor. Two years later, PJM updated its rules to factor in degradation year-over-year. The battery's capacity credit dropped from 16 MW to 12 MW in year 5. The entire revenue curve shifted down 25%. The gas peaker's accreditation stayed flat. That delta—not the technology itself—decided the project. So settle the current accreditation method, but also check whether the market is moving toward performance-based or duration-based credits. If it's, the battery's advantage in fast response gets diluted by its shorter duration relative to a 100-hour gas resource. Build that assumption into your base case, and then stress-test it with a rule change in year 4.

Core workflow: sequential steps in prose

Step 1: Build a multi-year production cost model

You start by throwing out the single-year anchor. Most teams build one snapshot year—say, 2027—and assume it repeats. That kills you. Instead, string together a sequence of at least five years, each with its own load shapes, fuel price trajectories, and renewable buildout assumptions. The tricky part is forcing the model to retire units when they become uneconomic, not when you feel like it. I have watched teams spend weeks perfecting a single-year dispatch only to discover the battery stack never gets called because the gas peaker is already stacked at zero cost. Painful.

Set up your plant database with age-dependent heat rates, variable O&M escalation, and outage profiles that drift upward as units age. Don't plug in static forced-outage rates—that's a fiction. Use a Markov-chain approach: a unit that tripped last year has a 40% higher chance of tripping again. Most people skip this; I have seen the same gas peaker flagged as 'available' all year when in reality it limped through summer with three forced outages. The catch is you need historical outage data, not nameplate assumptions—beg the ISO if you must.

Step 2: Derive hourly dispatch and revenue streams

Run the production cost model hourly, not at daily granularity. You need the edge cases: 3 AM on a windy, low-load spring Sunday versus a July heatwave with a transmission constraint. Each year produces a stack of LMPs, ancillary service prices, and start costs. From that stack, calculate gross margin per unit—but don't stop there. Track the *distribution* of those margins. A battery might average $45/MWh but lose money in 60% of hours; a gas peaker might earn $80/MWh in only 200 hours but cover its fixed cost in those hours alone.

Wrong order: you think revenue drives the decision. It doesn't. The real lever is the *shape* of the revenue—when does it arrive? If a battery gets paid only during the 10% tightest hours, but those hours cluster in two weeks every August, your retirement logic breaks. We fixed this by tagging each unit with a 'revenue concentration' metric: if the top 20% of hours account for more than 80% of annual gross margin, that unit is one bad month from retirement. Quick reality check—gas peakers often hit 95% concentration; batteries can hit 99%. That hurts.

Step 3: Add real-options logic for retirement and repowering

Now you layer in the decision logic. For each year, ask: does this unit cover its going-forward fixed costs? If not, you have two choices—retire it or repower it. But don't decide based on one year's margin. That's the single-event trap. Instead, build a real-options threshold: retire only if the cumulative probability of covering fixed costs over the next three years drops below 30%. Why three years? Because a cold-start gas peaker takes 18 months to permit and build; a battery can be online in 9 months. The time asymmetry matters.

Not every energy checklist earns its ink.

Simulate the decision path 500 times with different weather and fuel-price seeds. Most teams run one scenario and call it 'base case.' That base case is a hallucination.

— paraphrased from a system operator who learned the hard way

For repowering, build a simple NPV model that swaps the existing prime mover with a battery-plus-solar hybrid. The trick is to use the *same* stochastic draws from your production cost model—don't re-simulate the weather. If you reuse the same 500 seeds, you preserve correlation: a year that was bad for the gas peaker (because of mild summers) is also bad for solar (because of overcast conditions). Most repowering analyses ignore that correlation and overstate returns by 15–25%. Not yet convinced? Run a single seed where the gas peaker saves the grid during a polar vortex—that unit might earn its keep for a decade in that one week. The distribution is fat-tailed. Your decision rule must be fat-tailed too.

Tools, setup, and environment realities

Production cost modeling software (PLEXOS, GridView, Aurora)

The commercial suite dominates utility planning for a reason—depth. PLEXOS handles unit commitment with granular heat-rate curves, minimum down-times, and must-run constraints that actually match how a gas peaker behaves on a hot August afternoon. I have watched teams spend six weeks building a PLEXOS model only to realize their license limits the number of reservoirs. That hurts. GridView is faster to prototype but stumbles on chronological coupling across years. Aurora sits somewhere in the middle, strong for market-price forecasting but weak when you need to model a battery's state-of-charge degradation over twenty years. The catch: none of these tools let you see the code. When your peaker runs 47 hours straight and the model says it's impossible, you can't open a solver log and trace the bug. You submit a ticket. You wait.

Cost is the second knife. A single PLEXOS seat runs $15,000–$25,000 per year, and that buys you the solver—not the hourly weather data, not the transmission topology, not the gas-price forward curves. Most teams I know end up spending 40% of their project budget on data licensing alone. Is the expense justified? Only if your portfolio is large enough that a 0.5% error in capacity value moves millions. For a single plant comparison, the commercial tools are overkill—a fact vendors rarely mention.

Open-source alternatives (PyPSA, Switch)

PyPSA changed the game for precisely this niche. It handles linearized optimal power flow, storage state-of-charge, and multi-year investment planning without a license server. I have built a battery-vs-peaker workflow in PyPSA that runs in forty minutes on a laptop—same core constraints as PLEXOS, but the results differ by 2–3% on net present cost. The tricky bit is the learning curve: PyPSA expects you to understand Linopy, pandas indexing, and how clustering affects time-series fidelity. Most teams skip clustering validation, then wonder why the battery never cycles in summer months. Wrong order.

Switch is older, stronger for hydro-dominated grids, but its scenario-tree syntax drives analysts mad. Both tools lack built-in visualization—you're exporting CSVs and plotting in matplotlib, which means every review meeting turns into "trust the CSV." That said, open source gives you one superpower: you can fork the repo, add a custom constraint for gas peaker ramp limits, and see exactly what the solver sees. No ticket. No waiting. For a single-project analysis, this transparency beats polished UIs every time.

Hardware requirements and cloud vs. on-prem

Commercial solvers are gluttonous. A PLEXOS model with 8,760 hourly timesteps, 200 generators, and transmission constraints will chew 32 GB of RAM by hour 5,000. I have seen analysts run it on a workstation with 128 GB and still hit swap after adding a battery degradation matrix. Cloud instances—AWS c5.4xlarge or Azure F72s—handle this gracefully, but you pay per hour and the solver license is tied to a physical dongle. Dongle-in-the-cloud is a mess; one team I worked with lost three days because their IT firewall blocked the license server handshake.

Open-source tools run leaner. PyPSA on an 8-core laptop with 16 GB RAM handles 500-bus models comfortably. Switch needs more cores for its Benders decomposition, but a $200/month Hetzner dedicated server outruns a $15,000 workstation. The real bottleneck is data I/O—reading hourly solar irradiance for twenty sites takes longer than solving the unit commitment. Store your input data as Parquet, not CSV. That single swap cuts runtime by 60%. Cloud or on-prem? For a one-off comparison, use your laptop and PyPSA. For a recurring quarterly planning cycle, stand up a cheap dedicated server with a fixed IP and cron the workflow. Anything in between wastes money or time—pick one extreme.

'We spent $12,000 on solver licenses before we ran a single hour. The answer was wrong anyway because we used the wrong weather year.'

— utility planning director, after a failed IRP submission

Variations for different constraints

High solar penetration: batteries win on cycling but face 4-hour duration limits

When solar saturates the midday hours—say, 40% or more of annual generation—the morning ramp and evening duck curve punish anything slow to start. Gas peakers can spin up in ten minutes, sure, but they hate being cycled daily. I once watched a client burn through a combustion turbine’s hot-path inspection interval in eighteen months because they dispatched it every single afternoon for only two hours. That hurts—maintenance costs per MWh nearly doubled. Batteries love that shallow, frequent cycling. They handle 300+ partial cycles a year without breathing hard. The catch: four-hour duration is the practical ceiling for most lithium-ion configurations on the market today. You can stack more containers, but then you're fighting interconnection transformers and real-estate constraints. So what happens when a storm knocks out solar for three days? Your battery is dead by midnight on day one. Gas can burn through the night. The trade-off is stark: daily flexibility versus multi-day resilience. I have seen teams solve this by pairing a 2-hour battery with a gas peaker that only runs 200–400 hours a year—the battery handles the daily dance, the gas unit covers the multi-day holes. That sounds fine until fuel supply gets tight.

Wind-heavy systems: gas peakers provide longer duration but lower utilization

Wind doesn't follow a predictable daily pattern—it gusts and stalls for days at a time. A 100-MW wind farm might generate nothing for 36 hours, then blow at 90% capacity for 12. Batteries sized for the typical lull (say, 4 hours) get stranded when the lull stretches to 30. Gas peakers can run 12, 24, even 48 hours straight if the gas supply holds. The problem is utilization. If your gas peaker only fires 300 hours a year—common in high-wind zones—the unit cost per MWh skyrockets. Fixed costs get spread thin. I have seen annualized costs hit $200/MWh on a peaker that ran less than 5% of the year. That's brutal. One workaround: dual-fuel capability. Run the peaker on diesel during extended wind lulls when gas supply is constrained, but that adds fuel storage and emissions headaches. Or you can oversize the battery—say, 6 to 8 hours—and accept that you will leave capacity idle most days. The real question: is your wind profile persistent (long gaps) or choppy (short fluctuations)? Most teams skip this diagnosis and end up with a battery that can't bridge the multi-day event. — We fixed this once by running a year of 15-minute wind data through a simple outage simulation. The answer flipped from 4-hour battery to 8-hour battery plus a 50-MW gas peaker.

Reality check: name the planning owner or stop.

Island grids: dual-fuel gas with battery buffer

Islands are a different beast. Fuel arrives by ship—disruptions happen. One hurricane or port strike and your gas peaker is a paperweight. Batteries alone can't cover weeks of fuel shortage unless you grossly oversize them (nobody does). The practical answer: dual-fuel gas peakers that can burn propane, diesel, or LNG, paired with a modest battery buffer—say, 1 to 2 hours—for spinning reserve and frequency support. Why the small battery? Because on an island, inertia is scarce and a gas peaker’s ramp rate (typically 5–10 minutes to full load) leaves a gap that renewables or load swings can exploit. The battery fills that gap. It buys time for the peaker to sync without dropping frequency below 59.5 Hz. — I once saw an island utility try a battery-only solution for a 20-MW solar farm. The battery worked fine until a three-week fuel disruption hit the backup diesels. They ended up renting a temporary LNG barge. Dual-fuel gas + small battery is the least-worst combination when supply chains are fragile. The variations for other constraints—weak interconnection, low renewable shares, high diesel cost—mostly collapse into the same tension: short-duration assets cycle well but fail on endurance, long-duration assets sit idle but cover the extremes. You pick your poison based on which event scares you more.

Pitfalls, debugging, what to check when it fails

Ignoring startup costs and minimum downtime

The single most expensive mistake I see in planning runs is treating a gas peaker like a light switch—flip it on, power flows, no questions asked. A real 50 MW frame machine burns roughly 200 MMBtu of fuel just to spin up from cold iron, plus another 15 minutes of partial load before it can sync. Your model won’t scream at you; it will quietly show a cost curve that looks competitive until you scan the “starts per month” diagnostic. If that number exceeds four for a reciprocating engine or two for a simple-cycle turbine, your economics are lying. Minimum downtime is equally venomous—schedule the unit off for two hours then back on six cycles later, and you’ve effectively halved its hot-start life. The fix: add a binary state variable (off/on) with a ramp-up penalty and a lockout period. Check your output’s “unit state timeline” chart, not just the summary LCOE.

Using perfect foresight for battery dispatch

That simulation that shows your battery charging at 2 AM when prices bottom out and discharging at 7 PM when they peak? Pure fantasy—unless your operator has next-week’s hourly load curve taped to the control room wall. We don’t. Perfect foresight lets the optimizer “see” the highest price of the week and schedule every megawatt-hour to hit that single golden hour, which makes batteries look 20–35 % cheaper than they actually are. The catch is that in real operations, you’re dispatching against a forecast that gets worse beyond hour 48. What usually breaks first is the cycle count: perfect-foresight models run 120 deep cycles a year; real ISO data shows 180–220 because you charge and discharge into false signals. Run your model with a day-ahead rolling horizon and compare the cycle histogram against your “oracle” run. If they diverge by more than 15 %, throw away the perfect-foresight numbers.

‘A battery that cycles twice a day in simulation will cycle three times in the wild—and lose 0.4 % capacity every time.’

— root-cause note from a 2023 reliability audit

Underestimating degradation in high-cycling years

Degradation is not a straight line. Most planning tools apply a fixed annual fade—say 2 %—and call it done. Wrong order. In years where the battery dispatches 250+ equivalent full cycles (EFC)—often years 3–5 of a solar-heavy system—the calendar fade holds but the cycling fade accelerates. A lithium-ion NMC cell that degrades 0.3 % per 50 EFC in low-use periods can hit 0.5 % per 50 EFC when the stack is thermally stressed and the depth-of-discharge swings between 10 % and 95 % daily. I have seen a model project 70 % remaining capacity at year 10 when the real end-of-life was year 7. The diagnostic to check: plot “annual EFC” vs. “capacity fade rate” side by side for every simulation year. If the relationship is flat, your degradation input is probably a single number—replace it with a piecewise curve that ramps up above 200 EFC. That hurts the battery case by roughly 8 % on LCOE, but it forces an honest comparison with a gas peaker that just needs an oil change every 2,000 hours.

FAQ or checklist in prose

How to handle rare events without over-weighing them

The single-event trap is not a modeling flaw—it's a narrative one. When I review planning documents, the one-in-fifty heat wave always gets a spotlight slide. But that same team will dismiss the cumulative effect of thirty ordinary weekday afternoons that happen to overlap with solar drop-off. The fix is brutally simple: run your battery-vs-gas comparison twice—once with the raw historical sequence, once with the top 1 % of load events capped at a reasonable ceiling (say, the 99th percentile). If the technology choice flips between those two runs, you're not planning for reliability; you're planning for a headline. Short declarative: cap the tail, not the logic. The real edge case is the mundane cloud front that lingers over a metro area for six hours—not the apocalyptic August spike that makes the evening news once a decade.

That said, there is a practical trap in treating all rare events as equal. A 20-year simulation might include one heat dome that lasts four days. If your battery fleet cycles through its full capacity each day of that dome, the degradation math gets ugly fast—gas peakers laugh at that scenario. However, if you flatten the duration of that dome in your model, you artificially cap the battery's disadvantage. Most teams skip this: they apply a generic "extreme weather multiplier" to load but never adjust the *shape* of the event. The result is a model that says batteries win—until the board asks why the actual plant data shows twice the cycle count you promised.

“We validated against one year of calm weather and three weeks of hell. The hell week broke the model. That was the validation.”

— plant engineer, after a storage-plus-gas hybrid got dispatched into unplanned cycling during a September thunderstorm cluster

What discount rate to use for 20-year comparisons

The discount rate is where polite planning conversations become arguments. A utility treasury desk will push for 6.5 % nominal—that's their weighted average cost of capital. A developer with tax equity in the structure will insist on 9 % because their exit timeline is seven years, not twenty. Wrong order. You don't pick one rate and run. You run the whole LCOE stack at three rates: the owner's cost of capital, the societal discount typical in integrated resource plans (usually 3–4 % real), and the rate that makes the gas plant break even in year twelve—because that's the year the carbon adder or the emissions regulation tends to bite. The catch is that battery projects look better at low discount rates (high upfront capital, low operating cost) while gas peakers look better at high rates (low capital, fuel cost risk pushed far into the future). I have seen a 2 % swing flip the winner from battery to gas in a straight 20-year NPV. That's not noise—that's the difference between deciding on technology and deciding on financing structure. Don't let the spreadsheet settle an argument the boardroom should own.

How to validate model outputs against real plant data

Most teams compare annual energy (MWh) and call it validation. That's like checking a car engine by measuring the paint thickness. What breaks first is cycle count and part-load efficiency. Take your model's predicted dispatch schedule for a gas peaker—how many starts per year, how many hours at 30 % load versus 90 % load—and compare it to the operational logs of an existing plant in the same ISO or balancing authority. If your model says the peaker starts 120 times a year and the real asset started 40, your heat rate penalty assumptions are wrong. The fix: pull an actual SCADA trace from a random Tuesday in March and a stressed Wednesday in August. Run your model on that exact load sequence—not a synthetic profile—and see if the battery dispatches the same way the operator did. It won't. The operator had a human bias: they avoided discharging the battery below 20 % state of charge because they feared a cloud front. Your model probably doesn't have that fear. You can code it in. We fixed this by adding a "operator fatigue" penalty—a simple multiplier that reduces battery dispatch aggressiveness after three consecutive high-stress days. That one change brought our model's battery cycle count within 8 % of real plant data. Don't aim for perfect correlation; aim for the one or two behavioral mismatches that dominate the error. Fix those, and the rest tends to fall in line.

One more check: compare the *sequence* of decisions, not just the totals. A model that picks the right technology but cycles the battery at 3 a.m. when the real system would have used a gas peaker is still wrong. Run a simple string-matching metric—what fraction of hours does the model's dispatch choice match the actual plant's? Anything above 65 % is excellent for planning models. Below 40 % and your input assumptions are detached from reality.