R.A.N.T. – Physics doesn’t play nice with triathletes…

Ramblings About Numerical Things is a series of articles sharing my thoughts and opinions on the meaning or application of numbers in a particular area of interest.  I’ll try not to go overboard on the numbers themselves, but rather focus on how you can use numbers to meet your goals.

Physics doesn’t always play “fair”.  Yes, it’s repeatable and maybe predictable, but sometimes it’s also a bit complex to where common sense doesn’t always apply.  Let me give you an example.  If I ride up a hill on my bike and come down the other side, common sense may indicate that if I put out equal power on the way up and way down, that I’ll make up whatever time I lose going up, on the way back down.  Or, if I ride into a headwind leaving my house, that I’ll make up the difference on the tail wind on the way home.  Unfortunately it doesn’t work that way… on round trip rides & runs, wind and hills will always slow your average speed and decrease your efficiency.

Without getting too geeky, as I mentioned in my first RANT blog, speed and power are not a linear relationship.  The aerodynamic portion of power is a cubed function.  So as I increase the headwind speed, I really start to pay a big penalty, while not getting nearly the benefit from the tailwind.  Likewise, my aerodynamics are dwarfed by the power required to climb a hill, but when zipping down the other side, once again aerodynamics come into play.  The other significant co-conspirator in this “crime” is time… and we’ll talk about this below.

An easy way to understand the relationship is to use one of the bike power models.  Using a constant 180 watt output and no slope, I varied the windspeed to view the impact on a fictitious 20 mile ride, with 10 miles into the wind and 10 miles with a tailwind.  Adding the times together, I calculated the average mph of the ride, as well as a generalized efficiency in watts/mph.

wind2

Impact of wind (headwind + tailwind) on average bike speed and efficiency.

As you can see, the best situation is no wind, resulting in an average speed of 21.1 mph at an efficiency of 8.5 watts/mph.   At the extreme, a 20 mph headwind results in an average speed of 11 mph and the resulting tailwind is 34.5 mph.  Here’s where “common sense” can be problematic.  If we just average these two numbers together, it results in what appears to be a 22.75 mph “average” ((34.5+11)/2)… which is better than a no wind condition.  The problem is that simply averaging speeds fails to account for the amount of time we actually spent riding into and with the wind.  With no wind we were at 21.1 mph, so we would spend 28.4 minutes riding 10 miles away from home and 28.4 minutes riding 10 miles back home, for a total of 56.8 minutes on our ride.  With a 20 mph headwind, we’d average 11 mph into the wind resulting in a 10 mile ride away from home that takes 54.5 minutes… nearly the amount of time the entire 20 mile ride takes with no wind.  Although we ride home at a blazing 34.5 mph (and feeling great about how fast we are riding), it still takes 17.4 minutes, for a total ride time of 71.9 minutes.  Dividing the 20 miles by 1.2 hours (71.9 minutes) gives us the 16.7 mph and 10.8 watt/mph shown in the graph above.  The net loss in efficiency (watts/mph) is 26.5% in this extreme case of a 20 mph wind.

What about hills?  Well, they work in a very similar manner.  I used the same model, with the same general input, but varied the slope rather than the wind speed.  The resulting graph:

Impact of hills (up and down) on average speed and efficiency.

Impact of hills (up and down) on average bike speed and efficiency.

As you can see, the relationships look similar, but hills can have even a larger impact than wind speed, depending on slope.  Based on this model, around 3.5% slope (up and down) we’d have a similar average speed to a 20 mph headwind/tailwind.

What about running?  The same concepts apply, but both hills and wind have much less impact when you are running than biking.  There’s an online calculator that shows the impact of wind on pacing, from research done by Jack Daniels, here.   Assuming an 8 minute mile pace and varying wind speed from 0 to 20 mph, and a round trip run (both headwind and tailwind, the resulting impact on average pace and % speed loss is shown below:

Impact of wind speed on round trip running paces.

Impact of wind speed on round trip running paces.

Unfortunately I don’t have an online model to work with on running speed versus slopes, but there have been several studies done showing the impact of hills on running speed.  An example showing the impact at extreme slopes is shown here, with a graph of the data shown below:

Metabolic cost of running up and down hills.

Metabolic cost of running up and down hills.

The takeaway is that the benefit of going downhill is less than you lose going uphill, similar to biking (the slope of metabolic cost is much steeper going uphill).  When the slope going down gets steep enough (around 10%) the metabolic cost begins to rise again.  In essence, you only get back about 55% of what you lost on the way up.

How can you apply this information?  I’ll give you a couple of examples:

  • At the Elkhart Time Trial, it’s a 12k down and back course.  Typically the wind is out of the south, and it often around 10 mph.  Looking at the chart above, 10 mph headwind/tailwind represents a 6% loss in average speed.  Of course I’d use the bike calculator with my expected watts to get a more accurate representation at my target power levels.
  • Let’s say you were interested in a triathlon with a lot of climbing, like the Ax Tri in Norway.  The bike course goes from sea level up a mountain, down the other side and then back again, resulting in 2 climbs around 10 miles long at 7% grade, and the corresponding descents.  Using the model above, a 7% grade and 180 watts results in a speed of 6.3 mph on the ride up, and 42.3 mph on the ride down.  Of course you can’t (or at least I can’t) average 42.3 mph and navigate switchbacks, so a more realistic downhill speed may be a 20 mph average.  With 20 miles of climbing, this equates to 20 / 6.3 = 3.2 hours just going uphill.  At 20 mph on the way down, that would be another 20 / 20 = 1 hour to the ride.  With an additional 16 miles left on the ride (56 miles – 40 miles going up and down), assuming no slope the model shows an average speed of 21.1 mph or 16/21/1 = 0.8 hours, for a total ride time of 5 hours (3.2+1+0.8).  We could go one step further and assume an average 8 mph wind, the loss in associated speed would be 4.2%, adding another 13 minutes to the ride, for an “ideal” ride time of 5:13.  In this example, I would see this as a starting point, and in reality the target would be slower.  Getting on/off your bike, corners, aid stations,  waiting to pass, accelerating/decelerating, etc. all slow your speed and negatively impact efficiency.  At least this gives me an idea of how much time would be required on the bike, and I could plan bike fueling strategy accordingly.

I read a great quote that said, “Essentially, all models are wrong, but some are useful.”  (George E.P. Box, statistician).  The point is that using calculators like these may not be able to pinpoint exactly what your predicted time would be in a race, but they may be able to get you in the right zip code.  I find them most useful for modeling varying conditions, like those above, to better understand when Physics is or isn’t on my side…

Notes:

  1. If you are interested in the Excel file with the data and associated graphs, it is located here.

6 thoughts on “R.A.N.T. – Physics doesn’t play nice with triathletes…

  1. Hi! Nice article! I am looking into modeling the effect of the wind in running. More specifically, in the effect it has in power now that I have Stryd to play around with.
    I downloaded your excel file but I saw that the columns are not named nor explained.
    Could you please help here? I would want to know what are the variables, what calculations are you making and why, if possible.
    Thanks a lot in any case!

    • On the RunWind tab, the columns are: D=wind speed, E=wind effect, F=original pace + wind effect, and G is % change from the original. What I did is started with the Jack Daniel’s wind effect page at http://www.runsmartproject.com/calculator/ . I then simply entered varying wind amounts and recorded the associated “wind effect” (basically the seconds lost or gained due to the wind) in column E, and then added that to the number of seconds at a generic 8:00 per mile pace (480s). I just increased the wind by 2 mph up and down (using the headwind or tailwind option), and then calculated the percentage impact versus the original pace value. Note that you need to select the “Advanced Features” link to see the wind, altitude or temperature effect. The graph is simply the changes in the pace based on wind, showing the pacing and the % impact. Make sense? If you have additional questions, let me know.

      It will be interesting to see what your Stryd will pick up associated with wind effects. Theoretically I would assume it would pick up the changes in required acceleration required to overcome wind, but I’m not sure if it will actually have that level of resolution / accuracy. I purchased the 3 pack of Stryds a while back as part of the coaching program launch, and have been experimenting with them. I had some interesting runs with them outdoors, but I was disappointed (literally this morning on a treadmill ramp test run) to find that it is currently unable to quantify changes in incline on a treadmill. After corresponding with Stryd, they use a “environmental sensor” (I’m assuming barometric pressure) to sense vertical changes and the associated power (ignoring the accelerometers in that plane). So essentially Stryd will only accurately see power changes outdoors (associated with actual elevation changes), as it does not recognize slope changes on a treadmill… making it’s value (and accuracy) on a treadmill questionable other than at zero slope.

      If you are interested, here’s the graph of power (yellow), HR (red), cadence (light blue), SMO2 (aqua blue), and hemoglobin (brown) on my ramp test. The protocol I used for the ramp test was:

      Stryd ramp test on treadmill. WU laps 1-3, incline ramp test 4-10, rest 11, speed ramp test 12-17, cd 18. Stryd showed very little variation or sensitivity to incline changes (4-10), when clearly (by HR and muscle oxygen) there were substantial differences in effort. Stryd clearly picked up changes due to speed changes (12-17). Laps below show the protocol used.
      1 – 6@1%
      2 – 8@1%
      3 – 6@1%
      4 – 6@0%
      5 – 6@2%
      6 – 6@4%
      7 – 6@6%
      8 – 6@8%
      9 – 6@10%
      10 – 6@12%
      11- 2@0%
      12 – 5@0%
      13 – 6@0%
      14 – 7@0%
      15 – 8@0%
      16 – 9@0%
      17 – 10@0%
      18 – 3@0%

      A little outside your original question… but as a Stryd user, I thought it may be something you’d be interested in.

      • Hi!
        WOW! Thank you very much, first of all, for replying to my question. And secondly, for sharing with me your analysis about slope effects on power measurement with Stryd on treadmill.
        I believe it is a shame that it does not pick-up the incline on the treadmill. And I have to say that I am astonished about it! Does that mean then that it also ignores the power related to the vertical oscilation of the runner? As far as I have been able to see in high speed videos with synchronized force measurements (e.g. here: https://youtu.be/RRGHArGZUXc), the vertical component of the force a runner exerts is probably the largest one by a factor of 5-10; and, in my opinion, the ratio between horizontal and vertical force (and, consequently, power) should be an indication of the mechanical efficiency of the subject…
        So far, I have only tested it outdoors.
        I will keep you posted about what I find. Is there a better way to do so than in here?
        Thanks once more!
        Xavier.

      • I had a couple of email discussions with Stryd today. They were a little reluctant (understandably) to discuss the specifics of their intellectual property about how exactly they are calculating power. They didn’t confirm it, but I suspect they are measuring barometric pressure for elevation changes outdoors to capture the vertical plane. So, I think the numbers are likely much better when used outdoors in that manner. My outdoor runs have reflected hills (in terms of changes in power reflective of changes in HR), so at this point I’m assuming they are okay. To some degree, if you use consistent methodology (a little like cycling), even if your absolute numbers are off… as long as they are off by the same amount every time (high repeatability), they can still be useful for training purposes (just not for comparison to others). I may compare some of my outdoor runs / paces against my no incline segment on the treadmill to see how they compare from a power vs pace standpoint. Stryd discussed considering using an input from their app down the road, to input incline on a treadmill. This wasn’t on their immediate to-do list, as they are a small company. As you mentioned, the vertical plane may be a much bigger driver on overall power, so my guess is that a small errors in estimating elevation changes with an accelerometer creates a significant error in overall power… hence the initial drive to just input the incline via the app.

        My takeaway then is that Stryd is fine for doing running power tests outdoors (I’d still be looking for as flat of course as possible), but not a good solution on the treadmill, unless you are at 0% incline. The problem is that at 0% incline, you’ll likely be overstating your efficiency and pacing, due to the movement of the belt…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s