Power Metrics
Description of the CCAP Algorithm
The CCAP power metric is the primary constraint used in Optimal Cycling to enable the program to solve for the optimal power pacing. CCAP stands for Change Corrected Average Power. It is a linear combination of scaled power and scaled power rate. To calculate the CCAP power metric for real power values P(t), we use:
CCAP Equation
The descriptions of the variables are in the section below. Nominally, the coefficients KPOW and DPR are taken to be 1, while KPR is nominally taken to be 2. These coefficients are unitless real numbers and are required to be greater than zero. Note that the above formula does not provide a direct quantity of power, but rather is a representation of the “effort”. The first term of this linear combination represents the power-law scaled “effort” from steady state power. We scale it by how far P(t) is from PFTP to ensure that higher power outputs have a increasingly greater penalty than for lower power outputs than can be sustained for a relatively long time.
The second term in the above formula represents the scaled power rate. The scaled power rate is what promotes the ramping up and down in power of generated solutions instead of allowing instantaneous changes in power that are unrealistic. This is accomplished through the scaling of the magnitude of the power rate, |dP(t)/dt|, but alternative formulations can assign differing factors for both the positive and negative power rates to account for differences in response to whether power is rising or falling. An interesting thing about power rate in general is that it is a very, very seldomly used quantity in physics. It is typically only seen in the description of electricity generation in power plants.
To convert the above quantity to regular power values, a critical/maximal power curve is required. For a critical power curve, CP, we first scale it like what was done for the steady state power portion of the above equation:
Critical/Maximal Power Scaling
The rationale for scaling as such without the power rate term is that typical critical/maximal power curves from power meter analysis programs are calculated without the power rate portion. This shortcoming is somewhat offset by the expectation that the critical/maximal power curve would typically come from power outputs that are closer to steady state than rapidly changing and as such, the power rate portion would be a smaller proportion of the whole. In future iterations of CCAP, the idea of incorporating power rate into the power curve scale will be looked at to see if it is necessary for inclusion.
The next step in obtaining CCAP as regular power values is to determine the CPS(tf) value by looking it up on the CPS curve, i.e.: interpolation if CPS is not an analytical formula. Finally, we are able to obtain our goal:
CCAP Converted to Power
Note that during a power pacing optimization, if PCCAP > CPS(tf) then it is said that P(t) is not a viable solution.
Measurement of Power Rate in Real World Settings
The power rate term is a critical part of the CCAP algorithm but there is an important consideration when trying to measure power rate in real world settings with a power meter compared to the usage above in the CCAP algorithm. The CCAP algorithm as shown above was designed specifically for optimizing power pacing in Optimal Cycling where our physics model is not influenced by high frequency noise generated from the rapid impulses from the cadence of an athlete’s pedal stroke.
To obtain power data suitable for deriving power rates, raw power data from a power meter must be passed through a frequency based filter such as a Butterworth filter to remove the high frequency noise. A Butterworth filter function already exists in Optimal Cycling V0.9.0 and future versions of the program may enable the user to run their raw data through it. Note that rolling averages are typically not suitable for usage in this scenario since they laterally time-shift the data due to the nature of how rolling averages work.
Current power meters on the market may or may not already employ some form of high frequency data smoothing.
Description of the Variables
MCCAP, the raw CCAP value.
PCCAP, CCAP expressed in watts.
t, time.
tf, the final time.
P(t), a candidate solution of power values for a given power pacing optimization.
PFTP, the functional threshold power of the athlete.
KPOW, scaling exponent coefficient for power. Nominally set to 1.
DPR, linear scaling constant for the power rate portion of CCAP. Nominally set to 1.
KPR, scaling exponent coefficient for the power rate portion of CCAP. Nominally set to 2.
dP(t)/dt, power rate.
CP, maximal/critical power curve for the athlete.
CPS, scaled maximal/critical power curve for the athlete.
Sample Calculation
Example CCAP Calculation
For an example calculation of CCAP, you can download: Example CCAP Calculation Rev. 1 (Excel Spreadsheet)
Discussion
The above formulation of CCAP as described is currently used in Optimal Cycling V0.9.0. CCAP is by no means set in stone and in the future, there may be different iterations of CCAP to incorporate algorithmic improvements. As mentioned before, one such area for improvement may be to incorporate power rate into the scaling of the critical/maximal power curve.
Another area that I have looked at in the past and may revisit again in the future is to modify CCAP to perform a continuous comparison of the power metric values for all subset power values of P(t) since it is intuitively logical. By doing so, we can guarantee that the optimized power will at all times remain below the critical/maximal power curve. However, implementation wise this turned out to be a very computationally taxing method since the computing costs scale exponentially if we are to compute and compare all subsets.
The development of CCAP was required during the writing of Optimal Cycling because tests of common power metrics showed that they are not suitable for power pacing optimization when non-steady state conditions prevail. CCAP was arrived at by recognizing that in real life, power changes are not instantaneous but instead they go up and down with a finite slope. This was used in conjunction with the widely accepted observation that for athletes, higher power outputs require disproportionately greater “effort”. Many successive iterations of various power metric formulations, starting with average power, were performed to test whether sensible results were obtained as compared to what is expected for power output on flat courses and moving on to more complex courses as the formulations matured. Promising formulations were kept and reiterated with different terms while formulations that produced nonsensical results were rejected. In evaluating the formulations, it was necessary to look at how the terms of the equations affected the power pacing optimizations. In essence, CCAP was arrived at by a manual evolutionary approach that is similar in idea to how the differential evolution solver used in Optimal Cycling solves for the power pacing.
As I understand it, the optimal power profile for an individual athlete and specific course using the CCAP algorithm is based on one’s maximal power values over the full range of durations of effort. Ideally, this is the maximal effort for each specific target duration, measured without the complication of fatigue from other efforts at shorter or longer durations.
It isn’t clear to me how the optimal pacing using CCAP appropriately considers the effect of fatigue at a variety of levels-of-effort. For example, I couldn’t maintain my peak 2 min. power for 2 minutes immediately following a 30 sec. effort at my peak 30 sec. power. Or vice versa.
How can one verify that the optimization algorithm correctly accounts for fatigue at maximal power levels-of-effort, using the “exponentially scaled “effort” from steady state power?” How is the power-rate scaling factor determined for an individual athlete?
For the first part, yes, currently CCAP is in part constrained by the critical/maximal power curve over the full duration. For the second part, it is not logically correct to say “Ideally, this is the maximal effort for each specific target duration, measured without the complication of fatigue from other efforts at shorter or longer durations.” because fatigue is history dependent and you don’t necessarily reach *all* the points on the critical/maximal power curve during a race. For example, if you are racing a flat 4000m prologue, you don’t expect to hit both your maximal 4/5 minute power numbers AND your 10 second sprinting power.
Your example would violate your critical/maximal power curve for 2.5 minute power if you were able to pull off a ride with those numbers. Currently, CCAP considers the effect of cumulative fatigue by integration of the previous power and power rate values and is constrained by the critical/maximal power curve for the duration of the ride. In my testing, I’ve found that CCAP is pretty good in avoiding generating such efforts because of the power-law scaling and cumulative integration. But in the article above, I also mentioned that this is one area I’ve looked at in the past and may do so again in the future where we generate and compare all subsets of P(t) and compare it to the appropriate power on the critical/maximal power curve. I have implemented this in the past, but the computation costs scale exponentially due to what is required for comparison. A more efficient method of comparison is needed.
This is where end user testing and feedback is needed. I recommend running the CCAP_250m, CCAP_1000m, and CCAP_4000m simulation in the Optimal Cycling V0.9.0 Examples folder and playing around with that to see how CCAP reacts and seeing if the numbers would make sense to you if you run it with your own characteristics. From my testing, CCAP gives very reasonable optimized power pacing.
The power rate exponent scaling factor is nominally set to 2, but could be changed somewhat to reflect how an athlete copes with changes in power: Higher for athletes that fatigue more from change, and lower for athletes more easily able to generate differing power. There is currently no set method on how to determine this factor, but off of my head, it would require crunching through the power data files of an individual athlete.
Leave your response!
About
Optimal Cycling is software developed by Eric Wong that utilizes unique algorithms and technologies to provide accurate & detailed power pacing information for cyclists.
Optimal Cycling provides a comprehensive set of options and takes into account things such as acceleration, hills, wind, and varying efforts.
Optimal Cycling predicts your optimal power output at each point on a course and efficiently scales from as few as 10 points to as many as 10,000 points.
Links
Categories
Google Ads