TL;DR
- Target 200 minutes (3:20) for 42.195 km on 145 m gain / 290 m loss (Boston-style net downhill). Average pace 4:44/km, flat-equivalent 4:44/km — the engine returns the same number because net elevation correction lands at 0 seconds for this profile.[3]
- The model classifies the profile as "flat" for pacing. Net loss does not translate to a free pace gift; the long sequence of segments runs at the average rate.
- Quad damage cost is the missing variable. Sustained downhill before the halfway mark accumulates eccentric load that surfaces as 10 to 30 seconds per kilometer slowdown in the last 10 km.[1]
A common assumption ahead of a downhill course is that the math will pay back for the climbs: lose 290 m, gain 145 m, net descend 145 m, run faster. The pace calculator's flat-equivalent output disagrees, and the disagreement matters. Here is what the engine returns and where its assumptions stop predicting reality.
The scenario
A trained marathoner targeting 3:20 (200 minutes) on a course modeled after Boston's geometry: total elevation gain 145 m, total elevation loss 290 m. Net loss 145 m across 42.195 km. The runner has a flat-course 10K PR that supports this pace under steady conditions.
What the calculator returns
Running the inputs through the Marathon Pace Elevation tool:
Engine input
tool = marathon_pace_elevation
target_distance_km = 42.195
target_time_minutes = 200
total_elevation_gain_m = 145
total_elevation_loss_m = 290
Engine output
targetDistanceKm = 42.195
targetTimeMinutes = 200
averagePaceSecondsPerKm = 284
averagePaceLabel = "4:44"
flatEquivalentPaceSecondsPerKm = 284
flatEquivalentPaceLabel = "4:44"
netElevationCorrectionSeconds = 0
difficulty = "flat"
segments = 43 segments × 4:44/kmAverage pace 4:44/km (284 seconds). The flat-equivalent pace is also 4:44 because the engine computes that the net elevation correction is zero seconds for this profile: the up-cost and down-credit cancel under its Minetti-derived metabolic model.[1] Difficulty band: flat. Every one of the 43 segments runs at the same prescribed pace under the model's smoothing assumption.
Reading the numbers — what "net zero" misses
The output is correct for the model's purpose: an energy-budget-balanced pacing target across the full course. What it does not return is the time-domain consequence of when the gains and losses occur.
Three constraints break the symmetry:
- Asymmetry of metabolic cost. Going up costs roughly 3.5 W/kg per 1% gradient. Going down at the same gradient saves only 2.0 to 2.5 W/kg in metabolic terms[1]. Net-zero elevation does not mean net-zero physiological load.
- Eccentric quad damage on downhills. Minetti 2002's energetics model omits muscular damage, which scales nonlinearly with descent distance[2]. Beyond about 6 to 8 km of sustained downhill at -3% or steeper, race-pace deteriorates in the back half independent of cardiac load.
- Pacing variance. A "4:44 every km" prescription is impossible in practice when the road climbs 30 m in one km and descends 50 m in the next. Real pacing will be 4:55 on the uphill segment and 4:32 on the downhill, with the average landing on 4:44.
For a Boston-style course this matters because gains cluster in km 25 to 33 ("Newton hills") while losses cluster in the first 10 km and last 5 km. Running the prescribed 4:44 average requires absorbing roughly 50 m of climb between km 26 and 32 — a target effort closer to 4:55 to 5:00 for those segments — and recovering 15 to 30 seconds across the next several kilometers. Heart-rate drift on rolling terrain typically lags pace by 60 to 90 seconds; a power-meter or wrist-based effort gauge tracks the actual physiological cost more honestly than splits do.
Practical implication: a runner with no power meter should pace by perceived effort against terrain rather than by GPS pace. The model's 4:44 number is the right total-distance budget; the kilometer-by-kilometer execution belongs to the runner's body. A heart-rate cap (set 3 to 4 bpm under marathon-pace HR for the climb segments) is a more durable governor than a target split.
Where the formula breaks
The engine treats the course as homogeneous: total gain and loss as scalars, distributed uniformly across the distance. Real courses are not uniform, and three failure modes follow.
Concentrated descent before the halfway mark. Boston's first 10 km drops about 130 m. A runner who banks time at 4:35/km here will finish the first 10 km nearly a minute under target — which feels like wisdom and reads as catastrophe in the last 12 km when the quads fail. The model's "flat-equivalent" pace does not warn against this; the runner has to.
Heat-amplified pace decay. Above 18°C ambient, marathon pace decays roughly 2 to 4 seconds per kilometer per 1°C above threshold for an unacclimated runner. The model assumes ambient conditions and breaks on hot race days. Pair the elevation output with a Sweat Rate Calculator reading to estimate fluid-loss cost.
Granularity loss. 43 1-km segments at the same pace is a planning artifact. Real race pacing should split the course into 5 or 6 named zones (start descent, first sustained flat, Newton hills, peak, downhill recovery, finish flat) with separate effort prescriptions rather than a single average.
A more honest pacing table for this course
The model's 4:44/km average is correct on energy budget. The following per-zone breakdown holds the same total time but distributes effort against the actual terrain. The "bank" and "give back" framing matches how trained marathoners describe Boston pacing notes in the running press.
Course zone km range Profile Prescribed pace
─────────────────────────────────────────────────────────────────────
Opening descent 0 – 10 -1.3% avg 4:36 (bank ~80s)
Mid-course flat 10 – 25 rolling, net 0 4:44 (target avg)
Newton-hills climb 25 – 32 +0.7% avg 4:55 (give back ~80s)
Peak to finish flat 32 – 40 -0.5% net 4:42 (steady)
Final descent 40 – 42.2 -1.0% 4:40
Average n/a 4:44Same total time as the engine output, but the runner who follows this distribution has used the downhill segments to set up a sustainable hill climb instead of burning the quads early. Use the Race Time Predictor for a flat-course baseline before adjusting for terrain.
Related tools and follow-ups
- Marathon Pace Elevation — the engine used here, useful for any course with a known elevation profile.
- Race Time Predictor — Riegel-based predictions from a known shorter race time.
- Run Training Paces Calculator — Jack Daniels VDOT zones for the build-up.
For deeper validation work: Marathon pace elevation validated compares the engine's predictions against logged race data. Race time prediction: Riegel's limits covers the flat-course companion model. Marathon taper volume reduction curve covers the build-down to race week.
FAQ
How fast is a 200-minute marathon on a 145m-up, 290m-down course? Average pace 4:44/km (about 7:37/mile). With a net loss of 145m the elevation correction comes out near zero seconds on the engine's per-segment flat-equivalent rendering, because the calculator categorizes the profile as "flat" for pacing purposes.
Does downhill always make a marathon faster? Only up to about -2 to -3% gradient. Beyond that, eccentric quad damage costs more time later than the gravity-assist saves earlier. A Boston-style course with rolling downhills and a famously brutal back-half climb pattern is fast on paper and slow in the last 10K.
How accurate is the Minetti energy-cost model on rolling terrain? Minetti 2002 fits to ±5% on gradient ranges between -20% and +20% for sub-elite runners. The model breaks at extreme gradients (above 25%) and underestimates quad fatigue cost on sustained downhill above 8 km.
References
- 1 The energy cost of walking or running on sloped terrain (Minetti et al.) — Journal of Applied Physiology (2002)
- 2 Mechanics and energetics of level walking with backloads (Minetti, Saibene) — European Journal of Applied Physiology (1992)
- 3 Methodology — Marathon Pace Elevation — AI Fit Hub