Generator Operational Characteristics#
Overview#
Production cost models, capacity expansion models, and other power system planning tools generally need more than a generator’s nameplate capacity to represent how it actually behaves on the grid. They need estimates of things like how low a unit can run without shutting down, how long it tends to stay on or off once it starts a run, how quickly it can change output, and how its fuel efficiency changes across its operating range. These “operational characteristics” (sometimes called unit commitment parameters) aren’t reported directly by EIA or FERC, so PUDL estimates them empirically from EPA Hourly Continuous Emission Monitoring System (CEMS) hourly generation and fuel data, in the out_epacems__yearly_operational_characteristics table.
This methodology and its original implementation were generously contributed to PUDL by Sylvan Energy, with support for integration from GridLab,. We’ve adapted Sylvan Energy’s analysis to run automatically across every EPA CEMS reporting unit in the country as part of the regular PUDL pipeline. The table is still marked experimental while this integration continues. We describe the specific choices behind these metrics below so you can judge whether they suit your use case. Feedback Welcome!
This analysis processes several years of hourly readings for every EPA CEMS unit in the country using polars, a vectorized DataFrame library, reading the input data from Apache Parquet files. The full calculation completes in 1-3 minutes and peaks at around 16 GB of memory.
Scope: EPA CEMS Units, Gross Generation#
These estimates describe individual EPA CEMS “emissions units” (aka smokestacks),
identified by plant_id_epa and emissions_unit_id_epa, not EIA generators. A
CEMS unit doesn’t always correspond one-to-one with an EIA generator; see
core_epa__assn_eia_epacamd if you need to connect these characteristics to EIA
generator-level records.
Only fossil-fuel combustion units over 25 MW are required to report to EPA CEMS, so this table only covers that population – it doesn’t include smaller fossil units, and it doesn’t include non-combustion generation (e.g. wind, solar, hydro, nuclear) at all.
These characteristics are currently derived from CEMS’s directly monitored gross generation and fuel heat input, since that’s what CEMS reports hourly at the smokestack. Sylvan Energy has also contributed a method for converting gross to net generation, which is under active development and not yet integrated into PUDL. Once that lands, these tables will also offer net-generation-based versions of these characteristics, which will be more directly comparable to the net-generation accounting used elsewhere in PUDL.
A Rolling Window#
This table recomputes a single snapshot of each unit’s characteristics from a rolling
window of the most recent EPA CEMS data available – in production, the three most
recently completed calendar years. The report_year column records the vintage of
that snapshot (the most recent year included in the window). We plan to extend this
methodology to cover all available years, rather than just the most recent window, in
the near future.
Load Factor Bins#
Several of these characteristics are defined relative to a unit’s load factor: its gross load in a given hour, divided by the highest gross load it reached anywhere in the analysis window. Each unit’s own observed load factor range is divided into ten equal-width bins, and behavior is characterized within each bin (e.g. what fraction of hours fall in the lowest bin, how heat rate varies bin to bin).
These bins are scaled to each unit’s own observed operating range, rather than fixed, absolute bins shared across all units (e.g. 0-10% of some standard capacity, 10-20%, and so on). A large baseload steam plant and a small peaking combustion turbine typically operate over very different absolute ranges, and scaling the bins to each unit describes both in comparable, unit-specific terms. (Note that these load-factor bins are completely distinct from the ramp-rate bins described below in Ramp Rates).
Minimum Stable Load#
A unit’s min_stable_load_factor is defined empirically: it’s the lowest load-factor
bin in which the unit is observed sustaining operation for at least a minimum number of
consecutive hours (8 hours by default, though this threshold is configurable). This
reflects flexibility the unit has actually demonstrated during the window, rather than
a nameplate turndown rating, which may be more or less conservative than what’s observed
in practice.
Because this is based on directly observed behavior, a unit that has simply never had occasion to run for very long at low output will show a higher (less flexible) minimum stable load than it might technically be able to sustain.
Minimum Up and Down Time#
Once a unit’s minimum stable load is known, every hour at or above that level counts as “up,” and every hour at zero load counts as “down.” Minimum up time and minimum down time are each the shortest uninterrupted run of “up” or “down” hours observed anywhere in the window, rather than a typical or median run length. These statistics are most often used as hard constraints in production cost and unit commitment models (e.g. a unit cannot turn off after less than its minimum up time), which is the main reason for reporting the shortest observed run rather than a typical one.
Because it’s a minimum taken over many observed runs, a longer window that captures more up/down cycles is more likely to reveal a short, unusual run – so units may look like they’re becoming increasingly flexible as more historical data is included, independent of any real change in how the unit is operated.
Heat Rates#
Heat rate – fuel heat input divided by gross generation (MMBtu/MWh) – is a standard
proxy for thermal efficiency; lower is more efficient. Rather than a unit’s full,
continuous heat-rate curve across its entire operating range, two representative points
are reported: the median heat rate observed while operating in the unit’s highest
load-factor bin (heat_rate_at_max_load_factor_mmbtu_per_mwh), and the median heat
rate observed while operating in its minimum stable bin
(heat_rate_at_min_stable_load_factor_mmbtu_per_mwh). Comparing the two gives a sense
of how much efficiency degrades at low output relative to full output, without claiming
to characterize everything in between. The median, rather than the mean, is used within
each bin to reduce the influence of unusual hours (e.g. startup transients) that don’t
reflect a unit’s steady operation at that load level.
Ramp Rates#
Ramp rates describe how quickly a unit can change output, expressed here as a fraction of its maximum observed capacity per minute, which makes them comparable across units of very different sizes. They’re calculated only from hours when the unit was operating above its minimum stable level, which excludes the more extreme ramps associated with startup and shutdown events.
Rather than the single fastest ramp ever observed (likely an unusual one-off event) or an average ramp rate (which would be dominated by the much more common, comparatively slow, steady-state adjustments), the median of the fastest 5% of observed upward ramps is reported, and separately the median of the fastest 5% of observed downward ramps. This is meant to represent a ramp rate the unit can practically and repeatedly achieve, rather than either an extreme outlier or its typical, more leisurely pace of adjustment. Units that never operated flexibly enough during the window to produce a reasonable number of ramping events won’t have a ramp rate estimate at all, rather than one based on too few observations to be meaningful.
To find the fastest 5%, observed ramp rates are sorted and split into 20 equal-count (quantile) groups, and only the two extreme groups – fastest upward and fastest downward – are used. (Note that this is entirely distinct from the Load Factor Bins above mentioned above).
Feedback Welcome#
This is a newer, more experimental corner of PUDL, and for now we’ve focused on faithfully translating and productionizing Sylvan Energy’s original analysis rather than trying to evaluate any of the specific decisions it made. We don’t have as much domain expertise in power system operations and modeling as the people who actually use data like this every day, so we’d like to draw on the broader community of energy system data users to help evaluate and refine these choices – the rolling window length, the minimum-stable-level threshold, the ramp rate percentile, gross vs. net generation, or anything else described above. If any of it doesn’t match what you need, or you have ideas for how it could be improved, please get in touch!