Race Course for the Pacing Optimization

For all the optimizations and plots shown in this article, you download them here: HeadTailWindR1.zip. To run the simulations yourself, you will need Optimal Cycling V0.9.1 or greater. Note that in the optimizations done here, we are using 428 points to represent the course and that acceleration effects are taken into account.

Optimized Power Using CCAP

From the previous article, here is the optimized power plot obtained using the CCAP power metric:

Plot #1: Optimized Power Using CCAP, 250 Watts, 5 m/s Wind

In Plot #1, the suggested power output in the first half of the course with the headwind is about 274 watts. The suggested power for the return leg with the tailwind is about 204 watts. Also, notice that it is recommended to have a short spike in power at the start of approximately 300 watts and to decrease your power when close to the finish.

Optimized Power Using Standard Normalized Power

Now, we take a look at the optimized power obtained by using a standard normalized power of the 4th order using a 30 second rolling average:

Plot #2: Optimized Power Using Standard Normalized Power, 250 Watts, 5 m/s Wind

Plot #3: Optimized Power Using Standard Normalized Power, 250 Watts, 5 m/s Wind (Start)

Plot #4: Optimized Power Using Standard Normalized Power, 250 Watts, 5 m/s Wind (Zoomed Middle)

Plot #5: Optimized Power Using Standard Normalized Power, 250 Watts, 5 m/s Wind (Finish)

The optimized power pacing strategy obtained using standard normalized power gives power plots that exhibit some unusual characteristics because of the use of a rolling average in the power metric. Plot #2 shows the overall view of the power plot and the very large spike in power at the start makes the graph difficult to see clearly.

Plot #3 shows just the start of the optimized power and we can see that using standard normalized power results in a suggestion of starting out at about 1200 watts! The suggested power for the start could have been even higher if the simulation didn’t cap the power output for the cyclist to a maximum value of 1200 watts. After this huge effort, the suggested strategy is to bring the power output down 0 watts and then bring it back up to race pace.

Why does standard normalized power give this seemingly illogical suggestion? The answer is because standard normalized power utilizes a 30 second rolling average that requires us to average the power output for the first 30 seconds of a race before calculating actual normalized power values. This averaging results in overly optimistic starting powers and then a characteristic large dip because it is beneficial to bring your speed up quickly from zero.

In Plot #4, we see the zoomed in plot of the middle portion of the race. The suggested power riding into the headwind is about 261 watts and the suggested power for the return leg with the tailwind is about 228 watts. Note that there are a couple of power spikes in the transition between these two states caused by the use of the rolling average. In Plot #5 at the end of the race, the rolling average once again causes problems with the suggested power output as seen by the greatly varying power.

What can be done about these power spikes caused by the use of a rolling average in standard normalized power? The answer is that we can remedy it to an extent using a different form of averaging as we will see in the following section.

Optimized Power Using Exponentially Smoothed Normalized Power

Now, we are going to take a look at the optimized power obtained using normalized power with exponential smoothing:

Plot #6: Optimized Power Using Exponentially Smoothed Normalized Power, 250 Watts, 5 m/s Wind

Plot #7: Optimized Power Using Exponentially Smoothed Normalized Power, 250 Watts, 5 m/s Wind (Start)

Plot #8: Optimized Power Using Exponentially Smoothed Normalized Power, 250 Watts, 5 m/s Wind (Zoomed Middle)

Plot #9: Optimized Power Using Exponentially Smoothed Normalized Power, 250 Watts, 5 m/s Wind (Finish)

Comparing Plots #6-9 with those of Plots #2-5, we can see that using normalized power with exponential smoothing provides more sensible results due to fewer large power spikes. Looking at Plot #7, we can see that we still have the unusual suggestion that we start the race at the maximum power of 1200 watts but we don’t have the dip to zero power anymore caused by the use of a rolling average.

In Plot #8, the suggested power output riding into the headwind is about 261 watts and the suggested power output for the return leg with the tailwind is about 228 watts. These suggested numbers are essentially the same as what we obtained in the middle portion of the race using standard normalized power. Also note that the transition of the power between these two states is much cleaner in Plot #8 compared to Plot #4.

In Plot #9 for the end of the race, we can see that we don’t have the same wild power spikes that standard normalized power produced in Plot #5. There is still a bit of noise, but is much cleaner.

Discussion

What can we take away from this comparison? The answer is that one must be careful in using averages as part of a power metric because it can lead to unintended power spikes if you use it to solve for the optimal power pacing for a given race course. Standard normalized power is not suitable for use in solving for the optimal power pacing because of the problems shown above where we do detailed simulations that take into account acceleration. Modifying standard normalized power to use exponential smoothing instead of a rolling average gives more realistic results but there is still the problem of abnormally high suggested power outputs for the start of a race.

CCAP gives more sensible results for the start and finish of the race as seen in Plot #1. However, there is a problem of extended power output above functional threshold power (FTP) that affects both types of power metrics. As noted before, CCAP gives a suggestion of 274 watts riding into the headwind and 204 watts riding with the tailwind. By comparison, the power out suggested by each of the normalized power optimizations gave 261 watts for the headwind and 228 watts for the tailwind. It may not be possible for a cyclist to ride at 274 watts or even 261 watts for the extended time needed to cover 20 km going into a 5 m/s headwind if his FTP is 250 watts.

This means that I will be improving CCAP in the future in order to provide a solution that gives both stable power values as well as take into account the duration a cyclist spends above certain power levels. In particular, I will be looking at and coding energy flow models to see what is viable.

In this analysis, we are going to consider a flat 40 km TT course that has a headwind for the first 20 km followed by an equal tailwind for the last 20 km. We are going to solve for the optimal power pacing strategy using a critical power of 250, 300, and 350 watts to see how different power output levels affect the time savings obtained. We are going to look at scenarios with wind speeds of 0, 3, 5, and 8 m/s (0, 10.8, 18, and 28.8 km/h respectively).

Plot #1 - Race Course for the Pacing Optimization

The flat 40 km race course will be modeled with 428 points. Other notable parameters from the optimization model include:

• Rider Mass: 70 kg
• Bike Mass + Other Equipment: 8.5 kg
• Power Metric: CCAP
• Air Density: 1.18 kg/m^3
• CdA: 0.28 m^2
• Coefficient of Rolling Resistance: 0.004

Note that you can download the all the simulations done for this discussion here: Simulation Files for 40 km Flat TT with Headwind & Tailwind. You will need Optimal Cycling v0.9.1 or greater is required to run the simulation files. Depending on the speed of your computer, it can take several hours to run through all the simulation files.

The summary of the time savings that can be obtained using an optimized pacing strategy versus a start & steady strategy is shown below:

Table #1 - Summary of Time Savings Using an Optimized Pacing Strategy

For the output of 250 watts, the “Start & Steady” strategies are shown below. This strategy consists of quickly going up to race power and holding it steady for the entire course. Plots 3-5 show how the racer travels much more slowly in the first half of the course compared to the second half.

Plot #2 - 250 Watts, 0 m/s Wind, Start & Steady

Plot #3 - 250 Watts, 3 m/s Wind, Start & Steady

Plot #4 - 250 Watts, 5 m/s Wind, Start & Steady

Plot #5 - 250 Watts, 8 m/s Wind, Start & Steady

Below are plots of the optimized power pacing strategies for the output of 250 watts, plotted by course position. In Plots 7-9, we see the optimized power pacing strategies generated by Optimal Cycling. The strategy can be described as going harder into the headwind and ease up in the tailwind.

Plot #6 - 250 Watts, 0 m/s Wind, Optimized Pacing

Plot #7 - 250 Watts, 3 m/s Wind, Optimized Pacing

Plot #8 - 250 Watts, 5 m/s Wind, Optimized Pacing

Plot #9 - 250 Watts, 8 m/s Wind, Optimized Pacing

Now, the same plots for the optimized power pacing strategies but plotted by time. In Plots 11-13, we can see that the portion of time spent fighting the headwind in the first half of the course becomes increasingly greater as the wind speed goes up.

Plot #10 - 250 Watts, 0 m/s Wind, Optimized Pacing, Plotted By Time

Plot #11 - 250 Watts, 3 m/s Wind, Optimized Pacing, Plotted By Time

Plot #12 - 250 Watts, 5 m/s Wind, Optimized Pacing, Plotted By Time

Plot #13 - 250 Watts, 8 m/s Wind, Optimized Pacing, Plotted By Time

What can we learn from these plots and the summary table? The most important thing to note is that it is important to vary your power on a course that has a headwind and tailwind portion. From Table #1, we see that varying power becomes important at headwind/tailwind speeds of 3 m/s and above (10.8 km/h).

The exact numbers vary for riders with differing power outputs but the overall idea to push harder as the headwind increases remains the same. In Table #1, we see that there is less time savings for riders that push high power outputs. This is caused by the fact that a rider with a higher power output will cover the course in less time and thus the time savings will be proportionately smaller. However, Table #1 shows that the time savings are still significant if an optimized pacing strategy is used over a steady power approach.

For an overall power output of 250 watts, a rider that varies his power can save 10 seconds over a rider that just rides steady on a course with 3 m/s wind. A savings of 10 seconds could easily mean the difference between several finishing positions. In Plot #7, we see that Optimal Cycling suggests a power output of about 268 watts going into the 3 m/s headwind and a power output of 225 watts coming back with the 3 m/s tailwind.

Varying power becomes increasingly more important as the wind speed goes up as shown by a possible time savings of 60 seconds for an overall power output of 250 watts when there is an 8 m/s wind (28.8 km/h). In Plot #9, we can see the optimized power pacing strategy for this specific scenario and Optimal Cycling suggests a power output of 278 watts going into the 8 m/s headwind and a power output of just 172 watts coming back with the 8 m/s tailwind. This shows that on courses with high winds, the race is largely decided by how hard you race going into the headwind. The ride back with the tailwind should be a relatively relaxing affair since you have a tailwind pushing you that allows you to sustain a high speed without much effort.

To view the optimized power output plots for a cyclist at 300 watts and at 350 watts, visit http://optimalcycling.com/2011/05/30/additional-plots-pacing-strategy-headwind/.

I hope you have enjoyed this article and increased your knowledge of effective pacing strategies.

Optimized power output plots for a rider at 300 watts, plotted by position:

Plot #14 - 300 Watts, 0 m/s Wind, Optimized Pacing

Plot #15 - 300 Watts, 3 m/s Wind, Optimized Pacing

Plot #16 - 300 Watts, 5 m/s Wind, Optimized Pacing

Plot #17 - 300 Watts, 8 m/s Wind, Optimized Pacing

Optimized power output plots for a rider at 300 watts, plotted by time:

Plot #18 - 300 Watts, 0 m/s Wind, Optimized Pacing, Plotted By Time

Plot #19 - 300 Watts, 3 m/s Wind, Optimized Pacing, Plotted By Time

Plot #20 - 300 Watts, 5 m/s Wind, Optimized Pacing, Plotted By Time

Plot #21 - 300 Watts, 8 m/s Wind, Optimized Pacing, Plotted By Time

Optimized power output plots for a rider at 350 watts, plotted by position:

Plot #22 - 350 Watts, 0 m/s Wind, Optimized Pacing

Plot #23 - 350 Watts, 3 m/s Wind, Optimized Pacing

Plot #24 - 350 Watts, 5 m/s Wind, Optimized Pacing

Plot #25 - 350 Watts, 8 m/s Wind, Optimized Pacing

Optimized power output plots for a rider at 350 watts, plotted by time:

Plot #26 - 350 Watts, 0 m/s Wind, Optimized Pacing, Plotted By Time

Plot #27 - 350 Watts, 3 m/s Wind, Optimized Pacing, Plotted By Time

Plot #28 - 350 Watts, 5 m/s Wind, Optimized Pacing, Plotted By Time

Plot #29 - 350 Watts, 8 m/s Wind, Optimized Pacing, Plotted By Time

Optimal Cycling v0.9.1 Screenshot

• Fixes an issue where Optimal Cycling won’t compile on GPUs by being more strict with the OpenCL syntax.
• Optimal Cycling can now cache more than one compiled version of the OpenCL code to reduce waiting time if you like to switch back and forth between CPU and GPU.
• Added an option to use exponential smoothing with the generalized mean power metric instead of with regular rolling average smoothing.
• The data file format has been updated to version 2.1. Older file formats will automatically be converted to the new one.

You can download the new version at http://code.google.com/p/optimalcycling/downloads/list.

I have submitted NotScripts v1.1.0 today to the Opera Extension moderators that supports Opera 11.10. It should be out for download in a couple of days. There was a syntax change to postMessage in the Extensions API. I have also fixed the issue where NotScripts would list scripts from multiple sites if there were iFrames so NotScripts now works properly (it was caused by a workaround to a bug in the Extensions API of previous versions of Opera).

Note that NotScripts v1.1.0 will only work with Opera 11.10 and above because of changes in the Opera Extensions API. You can always use NotScripts v1.0.4 on previous versions of Opera.

With the fixes made in NotScripts v1.1.0, I’m now looking at the behavior on HTTPS pages. I have tested NotScripts v1.1.0 on secure pages such as https://encrypted.google.com/ and it works. However, there appears to sometimes be an issue where the NotScripts drop down list does not receive the array of script sources for the site when the drop down list is opened. It only occurs once in a while and a page reload gets the message passing working again. I don’t think it is a problem with the NotScripts code itself since this is an intermittent problem and there are no JavaScript errors in the developers console. It may be a bug with the Opera Extensions API on HTTPS pages. I will have to take a closer look.

In case you are anxious for a working version of NotScripts on Opera and don’t want to wait, you can download NotScripts v1.1.0 from the project Google Code page: http://code.google.com/p/notscripts/downloads/list. The download is the same as what I submitted to the Opera moderators for approval and it should install over top of your existing version of NotScripts.

We will be using the power meter data for Gustav Larsson at the Tour of California 2009 Prologue. The reason for this choice is because TrainingPeaks published the power meter data for Gustav Larsson throughout the Tour of California 2009 and thus, we have a high quality data set for a world class professional time trialist that has medaled in both the Olympics and the World Championships. You can view the power meter data for Larsson’s TOC 2009 Prologue at the TrainingPeaks website.

Simulation Files Download

This article performs a detailed time trial power pacing optimization using Optimal Cycling V0.9.0. You can download the simulation files and the spreadsheet containing all the plots for this article here: TOC 2009 Prologue Simulation Files

Course Profile & Larsson’s Power Data

Plot#1: Course Profile for the Tour of California 2009 Prologue (3.9 km)

The course profile for the Prologue shows that it is a very flat course with only a slight bump in the first half. It is a short course at about 3.9 km in length. Notice in the above plot that I have added a 1 metre tall starting ramp at the beginning of the course that drops down over a length of about 6 metres. It looks vertical because of the scaling of the graph.

If we take an overhead view of the Prologue course, we can see that there are 4 notable corners that have to be negotiated:

Overhead View of the Tour of California 2009 Prologue, http://www.amgentourofcalifornia.com/

The 4 corners show up as 4 deep troughs in Larsson’s power meter data, indicating he had to momentarily stop pedaling to go through them:

Plot #2: Larsson's Power Meter Data for the Prologue

It is important to point out that Larsson’s power meter data shows him finishing the race in a total of 288 seconds while his actual race time as measured by the officials is 285.5 seconds. This could be a timing issue with the power meter or that it recorded too much data. Also, the altitude data in Larsson’s power meter data does not appear to be reliable for this situation as it does not have the resolution required to accurately distinguish elevation changes on the order of fractions of a metre.

Model Parameters

From TrainingPeaks, we are able to learn that Gustav Larsson is 80 kg and by looking at the various power files & the maximal power curves released at the Tour of California 2009 for him, we are able to do a pretty good job of estimating his overall maximal power curve that we will use in our power pacing optimization:

Plot #3: Critical Power for Gustav Larsson at the Tour of California 2009

In our power pacing optimization, we will be taking advantage of the detailed computational capabilities of Optimal Cycling and use 293 points for the simulation so that we can do a one to one analysis between Larsson’s power meter data and the optimized power output we solve for. It takes a longer amount of computation time to handle so many points compared to a simpler simulation, but it is a nice stress test for the program.

To account for the 4 corners seen in the overhead of the race course, we will constrain the power output at those specific points to 0 watts for corners 1, 2, and 4 and to 220 watts for corner 3 so that they correspond similarly to how Larsson negotiated those corners.

For the power metric we are using to constrain this simulation, we will be using CCAP with a power rate coefficient, D_PR, of 0.25 since Larsson is a world class athlete that is able to generate varying amounts of power more efficiently than an average rider would.

Other notable simulation parameters assumed are:

• Total Equipment Mass: 8.5 kg
• Coefficient of Rolling Resistance: 0.004
• Air Temperature: 20 degrees Celsius
• Dew Point Temperature: 0 degrees Celsius
• Air Pressure: 101325 kPa
• CdA: 0.29 m^2 off the starting ramp and 0.26 m^2 after that
• Wind: Judging by Larsson’s power meter output & speed plots, there did not appear to be significant wind for him.

The CdA values for Larsson were the hardest to estimate but I arrived at them by analyzing both the Prologue here and the later Solvang time trial at the same Tour of California (I will be analyzing the Solvang TT at a later date). The CdA values were chosen so that they give model verification times that are very close to Larsson’s actual race times.

Model Verification

We now check to see if we have a reasonable model of the course and athlete by running Larsson’s raw power meter data directly in Optimal Cycling to see what time we get from the physics calculations. This verification is included in the Optimal Cycling simulation files you can download for this article. The time obtained from running the raw power numbers in our program is 285.8 seconds, which is very close to his actual race time of 285.5 seconds. This means that we can move forward with our analysis.

Power Pacing Results

After running Optimal Cycling for a while to solve for the optimal power pacing, we are able to compare our theoretical optimized power with Larsson’s power meter data:

Plot #4: Comparison of Larsson's Power Meter Data to the Calculated Optimized Power (By Position)

Plot #5: Comparison of Larsson's Power Meter Data to the Calculated Optimized Power (By Time)

Plot #6: Comparison of Larsson's Power Meter Speed to the Calculated Optimized Speed (By Position)

The time obtained by using the optimized power generated by Optimal Cycling is 284.6 seconds. This compares favorably to the 285.8 seconds we obtained in our model verification by running Larsson’s raw power meter data. It results in a time savings of 1.3 seconds.

Discussion

What can we gather from the results of Plots #4, 5, and 6? The first thing that is apparent is that we can save about 1.3 seconds by using the optimized strategy generated by Optimal Cycling compared to Larsson’s raw power numbers. To put this into context, a 1.3 second time savings would have moved Larsson up from his 38th place finish to a higher 29th place finish. Utilizing the optimal pacing strategy generated won’t make him magically win the Prologue, but it gives him a good boost in ranking.

Looking at Plot #4, we can see where Larsson rode less than optimal. Compared to the optimized power pacing in blue, Larsson went too hard at the start, did not put out enough power during the middle portion of the race, and actually had a sprint left in him at the end when he should have used that power much earlier to maintain a higher sustained speed. It is not to an athlete’s benefit to be able to sprint at the end of a time trial. Instead, Larsson should have put out more sustained power beforehand so that he is near exhaustion about 250 metres away from the finish line, relying on his kinetic energy and remaining power to carry him through.

This analysis can be further confirmed by looking at Plot #5 where we graph the power on a time basis instead of by a position basis that we did in Plot #4. Plot #5 shows that at the first two corners of the course (indicated by the deep troughs in power), Larsson was actually ahead in time compared to what the optimized power produced. However, Larsson lost this time advantage when he put out too little power in the middle of the race as can be seen by the difference between the power troughs at corner 3 (about 180 seconds on Plot #5).

Plot #5 compares the speed data from Larsson’s power meter to the speed obtained by using the optimized power from Optimal Cycling. It shows that Larsson went much too hard at the start of the race. His highest speed obtained during the race was during the first 500 metres only to meet the first corner where he had to slow down dramatically. To obtain the best time, it is generally not a good idea to spike up your speed but instead, you should try and keep it steady unless the course makes you slow down or speed up.

From about 600 metres to 3000 metres, we see that Larsson did not go fast enough since the speed plot from our optimized power is above Larsson’s own. This correlates with the power plots which give the same observation. From about 3500 metres onwards, we see Larsson’s speed go up because he is sprinting with the power he held back, which is not the best overall strategy.

Concluding Remarks

I hope this article has been insightful for you and how powerful Optimal Cycling is in helping you assess your own pacing strategies. In future articles, I will be taking a look at longer and more complex time trial courses and how we can model these course without entering every single course point manually. If you have questions or want me to do an analysis of a specific course, leave a comment or send an e-mail to contact@optimalcycling.com.

Problem Description

Ideally, the organizers of this race for the Tour of Qatar would have publicized the course profiles of the race, but ASO has not done so and has not indicated the exact location of the route for the Stage 1 ITT. However, since this ITT is only 2 km in length and is done on city streets in a desert region, I think it would be reasonable to assume that it will be a flat course. Another assumption we will make for this route is that there is a 1 metre tall starting ramp that drops down over 5 metres, which will undoubtedly affect what power output Optimal Cycling will recommend for the start.

As for the wind on the course, it can be quite gusty in Qatar but barring better data we are going to have to assume no wind for our baseline analysis. For the air, we will assume 25 degrees Celsius for the ambient air temperature and a dew point temperature of 0 degrees Celsius. For the atmospheric pressure, we will assume 101325 Pascals (sea-level like conditions).

For our hypothetical athlete, we are going to assume a mass of 70kg and a total bike & equipment mass of 8.5 kg. In the past the Tour of Qatar has disallowed pure time trial bicycles and equipment, meaning that only road bikes can be used in the race. For this reason, we are going to assume that the in-drops CdA of our hypothetical rider is 0.28 m^2 and while he is going down the start ramp, it is 0.30 m^2. Since this is going to be raced on the road, a typical coefficient of rolling resistance of 0.004 is going to be used. We are going to assume that our athlete has an functional threshold power (FTP) of 425 watts and his critical/maximal power curve looks like:

Critical/Maximal Power Plot

For the power metrics, we are going to analyze it with CCAP, average power, and a 4th order generalized mean with no rolling average. We will discuss the overall meanings of the results after the optimized power pacing results are shown in the next section.

Power Pacing Results

To download the Optimal Cycling V0.9.0 power pacing optimization files for the simulations done in this article, click here: Tour of Qatar 2011, Stage 1 Power Pacing Optimizations.

First off, we have the time trial pacing strategy generated with the preferred CCAP power metric:

Plot#1: Optimized Power Pacing (CCAP) with Course - Tour of Qatar 2011, Stage 1 ITT

Plot#2: Optimized Power Pacing (CCAP) with Speed - Tour of Qatar 2011, Stage 1 ITT

The top plot shows the course profile (in red) along with the optimized power output. If you look closely at the bottom left of the plot, you will see a small blip that is the starting ramp. It looks vertical since it only makes up 5 m out of the 2000 m course. The second plot shows the speed of the rider along with the optimized power output.

A question some people may have when using the CCAP power metric is what happens if I just set the power rate to a smaller value? The plot below shows the power pacing optimization done using CCAP with a zero power rate term. Note that at the start, it recommends a higher power output than when using CCAP with the nominal power rate term.

Plot#3: Optimized Power Pacing (CCAP_ZERO_PR) with Speed - Tour of Qatar 2011, Stage 1 ITT

Next, we have the results from using the average power as the power metric:

Plot#4: Optimized Power Pacing (AVEPOW) with Speed - Tour of Qatar 2011, Stage 1 ITT

Notice that using the average power as the power metric provides an unrealistic optimized power output. At the start, the average power metric recommends generating a full on sprint instantaneously at the maximum power this athlete can generate (1500 watts), which is not possible to do.

Finally, we have the results from using a 4th order generalized mean without no rolling averages:

Plot#5: Optimized Power Pacing (GM_NO_RA) with Speed - Tour of Qatar 2011, Stage 1 ITT

Discussion

So what can we gather from these optimized power pacing & speed plots? The first thing to see is that the *exact* power output recommendation is dependent on what power metric you use. My preference is to use the nominal CCAP power metric (Plot #1) since I developed it specifically for Optimal Cycling and that in my experience, it has provided the most reasonable results for the many simulations I have done during the development of Optimal Cycling.

However, we can see general recommended strategy for this 2km flat course with a starting ramp is to:

1. Ride at a relatively high power output until you get up to race speed, which should take you around 10-15 seconds.
2. Then, lower your power output just enough to maintain that race speed.
3. Finally, when you are about 15 seconds away from the finish, you should also be close to exhaustion and require ramping down your power output significantly.

This means that you should not have the ability to ride through the finish line with a sprint or even close to the power output you gave during the middle portion of the race. You should be near exhaustion about 15 seconds before the finish and just pedal on fumes for the rest of the race and coast down your speed as needed. You do not want to finish the race with anything close to what you were putting out because that means you are just wasting power to make you go fast *after* the finish line. Instead, both your power output and speed should drop as you approach the finish.

Another important thing to keep in mind, is that when starting the race, you should *not* generate so much power that you go over your race speed of the middle portion of the course. All the plots show that your speed should ramp up until you reach race speed, but not go over it because of an overzealous start.

If we take a look at the time required to finish the first half of the race compared to the last half, we can see that in all cases that first half will take longer then the second half. This means that we have a negative-split strategy here. For example, with the CCAP power metric optimization (Plot #1), it takes a total riding time of 139.7 seconds. The first 1000 m require a time of 72.0 seconds, while the second half required only 67.7 seconds.

Concluding Remarks

I hope that this article has been useful and informative in showing you the benefits of using Optimal Cycling to help you with your time trial pacing strategies in a systematic way. If you require clarifications or have questions, leave a comment or send an e-mail to contact@optimalcycling.com.

Example Data Folder

I have posted up detailed documentation for the file format Optimal Cycling uses for power pacing simulations: http://optimalcycling.com/power-pacing/file-format/. I recommend to read it for anyone trying to create their own power pacing simulations to get an overview of the file format and the details of what is needed.

Run Your First Power Pacing Optimization

For users interested in getting started with calculating the optimal power pacing for time trial type events using Optimal Cycling, I have written a step by step tutorial to help you install the program and run your first example simulation while I get more documentation posted:

http://optimalcycling.com/power-pacing/getting-started/

Also, I have now posted a page describing the CCAP power metric that is the primary constraint used in Optimal Cycling to solve for the optimal power pacing:

http://optimalcycling.com/power-pacing/power-metrics/

It is a must read for anyone curious as to how I got Optimal Cycling to work the way it does now, although it is a bit technical.

CCAP Equation

Optimal Cycling Command Line

The Optimal Cycling Project is a new & open source software program that provides the most sophisticated power pacing optimization for cyclists in time trial type races. It takes in the course profile of a race, the critical power curve of the cyclist, along with many other environment conditions and is able to consistently and efficiently generate the optimal power output of a cyclist.

A frequently asked question by time trialists and triathletes is how to correctly pace in a race to obtain the best possible time. The Optimal Cycling Project enables detail oriented athletes, coaches, and researchers to understand and help verify how to pace using power in a consistent and systematic way. It enables one to more quickly understand a race course before setting foot on it and to help demystify pacing.

The current version is Optimal Cycling V0.9.0 and is a cross-platform command line tool shown above. A graphical user interface is in development.

Some Examples of What It Can Do

Optimized Power Pacing (CCAP) - 250 m Flat Course, No Wind

Optimized Power Pacing (CCAP) - 1000 m Flat Course, No Wind

Optimized Power Pacing (CCAP) - 4000 m Flat Course, No Wind

Optimized Power Pacing (CCAP) - 10000m Hill Climb, No Wind

Optimized Power Pacing (CCAP) - 10000m See Saw, No Wind

Optimized Power Pacing (CCAP) - 40000m Flat Course, No Wind, 1612 Points!

Optimized Power Pacing (AVEPOW) - 1000m Flat Course, No Wind

Optimized Power Pacing (AVEPOW) - 4000m Flat Course, No Wind

Optimized Power Pacing (GM) – 1000m Flat Course, No Wind

Optimized Power Pacing (GM_NO_RA) - 1000m Flat Course, No Wind

Optimized Power Pacing (GM) – 4000m Flat Course, No Wind

Optimized Power Pacing (GM_NO_RA) - 4000m Flat Course, No Wind

Optimized Power Pacing (GM) - 10000m Hill Climb, No Wind

Optimized Power Pacing (GM_NO_RA) - 10000m Hill Climb, No Wind

What Sets the Optimal Cycling Project Apart

The key thing that sets the Optimal Cycling Project apart is that it pays attention to details. For example, whereas many previous papers and attempts at power pacing assumed steady state power and no acceleration, the Optimal Cycling Project does not make these assumptions that can adversely affect the results. Optimal Cycling generates the optimal power output WITH varying power AND acceleration throughout, as well as taking into account things such as hills and wind. The coding and math are much harder when such details are taken into account, but the end result is a more realistic and accurate answer. Optimal Cycling also enables you to create power optimizations for detailed courses, even if you want hundred or thousands of points in your simulation. This means that you can optimize power down to a course resolution of 10 or even 5 metres.

To optimize the power output, we have to use a suitable power metric that provides realistic results. A new & unique algorithm named CCAP (stands for Change Corrected Average Power) was the result of this effort. It takes into account the non-linearity of the effort required from high power outputs and also the power rate of the result. A new & unique algorithm was required to be developed because there were shortcomings in common power metrics, such as average power and general mean type metrics (like Normalized Power) where they could produce chaotic spikes in power. More will be written about the power metric algorithms in the near future.

Another way that the Optimal Cycling Project raises the bar is that it is scalable and efficient. The core logic of Optimal Cycling is written in OpenCL, which enables it to run on multicore/GPGPU systems with relative ease. The algorithms used are optimized for parallel processing and speed since generating an optimal power output can be a very compute intensive task that can take hours for detailed simulations.

The solver in Optimal Cycling is a custom written version of differential evolution and the algorithm is modified with smoothing operators for much faster and consistent convergence. Many different function minimization methods were tested to arrive at the current algorithm. They include simulated annealing, particle swarming, Nelder-Mead, quasi-Newton, and genetic algorithms. The current solver has been tested up to 10,000 points on a single course.

More Information / Download

To read more about the Optimal Cycling Project, visit http://optimalcycling.com/power-pacing/. I will be updating that section of the website as I write up more documentation and explanations of the examples. I HIGHLY recommend you read the information there before trying to run Optimal Cycling. There are dependencies on .Net/Mono + OpenCL.

To download the executable for Optimal Cycling or to view the source code online, visit the project’s Google Code page at http://code.google.com/p/optimalcycling/.

Since this is the first release of the power pacing tool for Optimal Cycling, it should not be considered final. It should be considered an Alpha level release. It is currently a command line tool that is not suitable for users without some experience running in the command line. If you should run into trouble running the program or have questions, e-mail me at contact@optimalcycling.com.