[POST_TITLE]
[POST_DEK]
A wind farm is a set of machines standing at specific points on a specific piece of ground. An operational forecast model does not know that ground. It knows a cell, roughly 3 km on a side, and inside that cell it carries one wind speed. This note takes one site, renders it at both resolutions, and follows what appears in between all the way through to the predicted power.
One cell over a ridge
Start with the geometry. A 3 km cell is wider than most of the terrain features that set hub-height wind. A ridge crest is a few hundred metres across. The pass the wind accelerates through is narrower still. The separated eddy that forms behind a crest and takes several metres per second out of the flow occupies a band downwind of it that is, again, a fraction of a cell.
When the model integrates, all of that is averaged into a single number. The average is not wrong in the way a bug is wrong; it is the correct mean over an area that happens to contain most of the physics we care about. The problem is that the turbines are not distributed evenly over the cell. They are on the crest, and in the pass, and behind the crest.
Fig. 1 — [POST_FIG_1_CAPTION]
[POST_FIG_1_PROVENANCE]
The same site, resolved
Now take the same footprint and mesh it. Elevation comes from a lidar-derived digital elevation model where one exists and from the 30 m global product where it does not. The flow is resolved on that surface, and the conditions at the edges of the domain are the same operational forecast that produced the single cell value — the coarse model supplies the synoptic setting, and the resolved solution supplies the terrain response inside it. The figures in this note are the reference solve, run to show what that response looks like; what runs on a forecast cycle is a pretrained flow model with the same terrain and the same boundary imposed on it.
| Domain | [LES_DOMAIN] |
|---|---|
| Horizontal cell | [LES_CELL] |
| Vertical levels | [LES_LEVELS] |
| Boundary forcing | [FORCING_MODEL] |
| Terrain source | USGS 3DEP lidar, 30 m SRTM fallback |
What comes out is not a smoother version of the coarse field. It is a different field with structure in it: a band of faster air along the crest, a jet through the gap, and a slow, unsteady wake in the lee that does not sit where a simple speed-up rule would put it.
Fig. 2 — [POST_FIG_2_CAPTION]
[POST_FIG_2_PROVENANCE]
What that does to the power
A wind field is only interesting here because it becomes megawatts. Through the steep middle of a turbine's power curve, output goes roughly as the cube of wind speed, which means the conversion from wind to power is also a conversion from a small relative error to a larger one.
The wind error is inherited. The power error is manufactured, by the curve, out of the wind error.
The published operational figure for that amplification on real onshore farms is 1.8–2.6× (Lange, On the uncertainty of wind power predictions, J. Solar Energy Engineering, 2005) — an industry figure, not ours. It is the reason a resolution improvement that looks modest in metres per second does not stay modest in megawatt-hours.
Two turbines a few hundred metres apart, one on the crest and one in the lee, therefore need to be treated as two forecasts. Wake losses between them are handled separately, by a correction learned from observed generation across multiple wind farms rather than assumed from an analytical wake model; its effect on forecast error is [WAKE_IMPROVEMENT].
Fig. 3 — [POST_FIG_3_CAPTION]
[POST_FIG_3_PROVENANCE]
Checking it against something real
None of this is worth reading unless it is checked against measured generation. ERCOT publishes five-minute generation for Texas wind farms in its 60-day SCED disclosure. That is the reference: real output from real machines, at five-minute resolution, over whatever period you want to test. The forecast is scored against it directly — not against another model's output, and not against a synthetic case.1
Delivery is deliberately boring. A forecast arrives as a table of timestamps and values per turbine, at the cadence you ask for:
# one row per turbine per interval
{
"site": "[SITE_ID]",
"issued": "[ISSUED_TIME]",
"horizon": "[HORIZONS]",
"interval": "[UPDATE_CADENCE]",
"turbines": [
{ "id": "[TURBINE_ID]",
"hub_height_m": "[HUB_HEIGHT]",
"wind_speed_ms": [ … ],
"power_mw": [ … ],
"revenue_usd": [ … ] }
]
}
The last figure is the one that matters: the error of the resolved forecast and the error of the coarse forecast against the same SCED series, over the same period, normalized both as a fraction of installed capacity and as a fraction of the energy actually produced. Those two normalizations differ by several times, and reporting only the first is the standard way to make a wind forecast look better than it is.
Fig. 4 — [POST_FIG_4_CAPTION]
[POST_FIG_4_PROVENANCE]
Headline numbers for this comparison are on the Results section of the home page, with the site list, period and sample count alongside them.
- Validated against ERCOT 60-day SCED generation data. ↩
[CTA_LABEL] [CONTACT_EMAIL]