Wind Model
RaceCraft already knows which way you are running and what the wind is doing at the hour you get there — see Weather Along the Course. The wind model takes that and turns it into time: a headwind slows your predicted pace, a tailwind gives a little back, and your finish time moves accordingly.
Like the fatigue and terrain models, this is a model, not a measurement. Read the Limits before you plan a race around the number.
What it does
Every segment gets a wind_factor that multiplies its predicted time, exactly
the way terrain_factor and the fatigue multiplier already do:
segment_time = base_time x terrain_factor x fatigue_multiplier x wind_factor
A factor of 1.04 means that segment takes 4% longer than it would in still air.
A factor of 0.996 means the wind is helping, slightly.
The physics
Running through air costs energy, and the cost rises with the square of the air speed you meet. Following Pugh (1971) and Davies (1980), the extra energy cost per metre is:
delta_e = k x (drag_term - v^2) k = 0.5 x rho x CdA / m
| Symbol | Value | What it is |
|---|---|---|
rho |
1.225 kg/m3 | Air density at sea level, 15 °C |
CdA |
0.24 m2 | Effective drag area of a runner (Pugh's wind-tunnel figure) |
m |
70 kg | Reference runner mass — only CdA/m matters |
v |
varies | Your ground speed on that segment |
drag_term is the total relative air speed multiplied by the part of it running
along your direction of travel. Divide delta_e by the energy cost of running
itself (~3.6 J/kg/m) and you have a fractional slowdown.
Those constants are not tuned to make the output look reasonable — they reproduce Pugh's measured result that air resistance accounts for about 2% of the energy cost of level running at middle-distance speed, rising to 6-8% at sprint speed.
Three things this gets right for free
A headwind hurts more than the same tailwind helps. A headwind equal to your running speed doubles the air speed, which quadruples the drag — three times the still-air cost. The most a tailwind can ever do is cancel that still-air cost entirely. Unlike a cyclist, a runner cannot be usefully pushed faster than the air around them, so the benefit saturates there rather than growing without limit. The asymmetry is roughly 3:1 and it comes straight out of the maths.
A crosswind is not free. It raises the total air speed you are pushing through even though none of it opposes you directly, so it carries a small penalty rather than none at all — a second or two per kilometre in a stiff breeze.
Slow ground barely feels it. Drag scales with your own speed as well as the
wind's, so the same gale costs you far less grinding up a 20% climb than it does
on a fast descent. No special-casing required — it falls out of v.
Rough magnitudes
Per kilometre, for a runner at 6:00/km, at the default mixed exposure:
| Forecast wind | Headwind | Tailwind | Crosswind |
|---|---|---|---|
| 10 km/h | +3 s | -1 s | ~0 s |
| 20 km/h | +6 s | -2 s | +1 s |
| 40 km/h | +17 s | -2 s | +3 s |
| 60 km/h | +33 s | -2 s | +4 s |
The tailwind column stops improving because it has already cancelled all the drag there is to cancel. That is the model working, not a bug.
Exposure: the honest fudge
The forecast is taken at one point — the route start — measured 10 m above open ground. The wind a runner actually meets varies enormously:
- On a bare ridge or an open coastal flat, they feel most of it.
- In a valley, a forest, or on tree-lined singletrack, they feel a fraction.
Passing the forecast straight through would overstate the effect badly on a sheltered course. So every wind speed is damped by an exposure factor before it reaches the model:
| Setting | Factor | Use it for |
|---|---|---|
| Sheltered | 0.35 | Forest, valley floors, tree-lined singletrack |
| Mixed (default) | 0.60 | Some open, some sheltered — most courses |
| Exposed | 0.85 | Ridgelines, open country, coast, desert |
| Auto | varies | Estimated per segment from that segment's terrain type |
Auto reads exposure off the terrain type each segment already carries:
| Terrain | Factor | Reasoning |
|---|---|---|
| Scrambling | 0.90 | Almost by definition above the treeline |
| Road | 0.75 | Roads tend to run through open country |
| Dirt road | 0.70 | As above, often with some tree cover |
| Rocky runnable | 0.65 | Mixed |
| Very technical | 0.60 | Mixed |
| Smooth trail | 0.55 | Often cut through vegetation |
| Technical | 0.50 | Tends to be forest or gully singletrack |
This is a proxy and a weak one — terrain difficulty describes what is under your feet, not what is around you. The correlation is real but loose. If you know your course, pick one of the three fixed levels instead.
No setting passes the forecast through at full strength. That is deliberate: one forecast point cannot justify it.
Where it applies
Base Pace mode only. Target Time mode distributes a total you have already fixed — slowing segments for wind there would break the very target it exists to hit. The forecast panel still appears in Target Time mode; it just does not move the clock.
Wind also does nothing at all when:
- No race date is set — there is nothing to forecast against.
- The race is more than ~16 days out, beyond Open-Meteo's horizon.
- The forecast service cannot be reached. Weather never blocks a plan.
In each case the panel says which, and the plan is exactly what it would have been without the feature.
Chicken and egg
Wind depends on when you reach each stretch of course. When you reach it depends on the wind. RaceCraft opens the loop by modelling the plan once in still air, projecting the forecast onto that provisional schedule, then applying the resulting factors.
One pass is enough. Wind moves segment times by a few percent, and shifting a leg by a couple of minutes rarely moves it into a different forecast hour.
The same still-air pass does a second job: when a saved plan is opened without recalculating, its segments carry no wind numbers, so the weather endpoint models the plan from the plan's own settings and attaches estimated per-segment effects to the panel. Estimates use the same model and constants as a real calculation — they are provisional only because they rest on a still-air schedule with no checkpoint stops, rather than the finished plan — and they are discarded the moment a real calculation replaces them.
Out-and-backs do not cancel
Averaging the head component over an out-and-back gives roughly zero — half into the wind, half with it. Running it is not free, though: the headwind half costs about three times what the tailwind half returns.
So the factor is computed leg by leg along the route and then distance-weighted, never from the segment's averaged head component. An out-and-back in a stiff breeze comes out slower than the same course in still air, which is what any runner who has done one will tell you.
Reading it in the app
- Wind column in the segment table: the time the wind adds to each kilometre (or mile), signed — red for a cost, green for a saving. Same shape as the Fatigue column.
- Effect on finish time in the Weather Along the Course panel: the total, across the whole race.
- Pace column in that same panel: the per-segment figure again, next to the wind that caused it.
- CSV export carries the per-segment figure too.
Limits worth knowing
- One forecast point. On a big mountain course, ridge wind and valley wind are different weather. Multi-point sampling is the obvious follow-up.
- Forecasts move. Results are cached for three hours; re-open a plan near race day and it picks up revisions.
- Gusts are not modelled. The panel reports peak gust, but pacing uses sustained wind. A gusty day is harder than the number suggests.
- Sea-level air density. Altitude thins the air and softens every wind effect; the model does not know your altitude, so it stays conservative.
- Exposure is a guess. It is the largest source of error here by some margin, and no amount of physics downstream can fix a wrong exposure setting.
Treat the output the way you would treat the fatigue model: a considered estimate that beats ignoring the wind entirely, not a promise.
Technical notes
- Wind factors are aggregated per leg, then distance-weighted across the segment
- Applied in:
POST /api/calculate
References
- Pugh, L.G.C.E. (1971). The influence of wind resistance in running and walking and the mechanical efficiency of work against horizontal or vertical forces. Journal of Physiology, 213(2), 255-276.
- Davies, C.T.M. (1980). Effects of wind assistance and resistance on the forward motion of a runner. Journal of Applied Physiology, 48(4), 702-709.