CP and W' Solver - Tutorial

[Mark Liversedge]

I've posted a rambling and not too brilliant tutorial on the CP and W' Solver

In short - it was developed to solve the W'bal parameters for multiple rides where exhaustion occured. But there are a few issues left to overcome; the parameters move around with fatigue and recovery in-ride and across training.

So the solver really helps to explore the relationship between the parameters and exhaustion. One key point- it solves for W'=500J, since this is typically where exhaustion occurs (not zero).

Along the way I try to explain the new recovery ratio introduced into the differential model. The video is here: https://vimeo.com/160627324 but will likely re-record a more focussed version for the website.

Lastly, the two user data formulas (for the ride plot) are listed below, you should be able to cut and paste them straight in so long as you have the DEV1603 build of GC.

Integral:

## Skiba W'bal

{

## get CP / allow tweaking

CPP <- config(cp);

## calculate power above cp to use below

TT <- POWER > CPP ? POWER-CPP : 0;

## dave waterworths reformulation to iteration

II <- II + (exp(SECS / W'bal_TAU) * TT);

wpbal <- config(w') - (exp((-1) * (SECS / W'bal_TAU)) * II);

# we want kJ not Joules

wpbal / 1000;

}

Differential:

## Froncioni W'bal with R

{

## initialise

CPP <- config(cp);

RR <- 0.5; ## between 0.6 and 0.8 seems about right (?)

if (SECS <= 1) { wp <- config(w'); }

## compute

if (POWER < CPP) {

wp <- wp + (RR * (config(w')-wp) / config(w') * (CPP - POWER));

} else {

wp <- wp + (CPP - POWER);

}

## scale to kJ

wp/1000;

}

CHEERS

Mark

[Mark Liversedge]

One point that does not come across well in the video is related to the number of exhaustion points being solved at once.

The original idea was to solve for 3 or more exhaustions in relatively the same training period (e.g. a month). The theory was that CP, W' and R/Tau would converge given enough high quality data points. What we have found, so far, is that any convergence that does take place is usually for similar workouts/races (e.g. points races).

Convergence is a lot less likely when the athlete is at different levels of fatigue/recovery or the race/workout have a different profile/demand (e.g. IP v Scratch v Points). In these cases whilst CP and W' often do converge across workout types (as you would expect), the points at which they overlap rarely have the same value for R or Tau.

Also, when solving for only 1 ride you will get a very wide range of solutions that are all equivalent. The coloring of the plot uses red to show low values or R/Tau, green for mid values and blue for high values. The size of the dot indicates how close to a sum of W'bal^2 = 500J.

And the other important point -- by marking exhaustion points we can start to collect quality data for other purposes, not just for the solver.

CHEERS

Mark

[Mark Liversedge]

And last on this today from me, here are 2 points races and an IP plotted with R set to 0.6.

It we were to remove R altogether and use a constant of 0.6 (or some other value we could derive empirically?) then its pretty clear from the above that the points they converge are at or about CP and W' from the above... 

I would *love* to have a continuous function to derive each of these curves with a constant R (we use a metaheuristic at present which is ok, but costly and cannot be multithreaded easily). 

Any mathematician fancy the challenge?

Dave ..... ????

:)

Mark

[Nathan Townsend]

Fantastic work Mark. I haven't had a chance yet to test it out (in writing mode at present), but what I can re-iterate from a conceptual point of view is that solving for tau should be treated the same as performance testing for CP and W'.  It makes no sense to compute an individualised tau value when you're fatigued or tired or sick or whatever.  You need to be in performance ready shape (same goes for CP testing itself of course).  Secondly, when conducting maximal efforts in training, I think it is beneficial to continue the max effort until you definitely note that power is falling despite maintence of max effort.  Ideally you would let power drop to about CP, but I think as long as you're within about 50 W or so the margin or error will be low and accounted for by solving for W'bal = 500 J.

correct me if I'm wrong, but the solver constrains CP and W' to the values set under athlete properties right?

[Mark Liversedge]

On Tuesday, 29 March 2016 16:28:59 UTC+1, Nathan Townsend wrote:

Fantastic work Mark. I haven't had a chance yet to test it out (in writing mode at present), but what I can re-iterate from a conceptual point of view is that solving for tau should be treated the same as performance testing for CP and W'.  It makes no sense to compute an individualised tau value when you're fatigued or tired or sick or whatever.  You need to be in performance ready shape (same goes for CP testing itself of course).  Secondly, when conducting maximal efforts in training, I think it is beneficial to continue the max effort until you definitely note that power is falling despite maintence of max effort.  Ideally you would let power drop to about CP, but I think as long as you're within about 50 W or so the margin or error will be low and accounted for by solving for W'bal = 500 J.

correct me if I'm wrong, but the solver constrains CP and W' to the values set under athlete properties right?

The solver doesn't constrain anything by default, although it does limit the search space to plausible values.

The user can change them, and I did in the tutorial, to experiment.

I did find, interestingly, that the two points races and IP *did* solve using the differential model, with an R of 0.5.

Mark 

[Nathan Townsend]

On Monday, 28 March 2016 20:26:34 UTC+3, Mark Liversedge wrote:

So the solver really helps to explore the relationship between the parameters and exhaustion. One key point- it solves for W'=500J, since this is typically where exhaustion occurs (not zero).

I just did a little analysis of the assumption that W'bal = 500 J where exhaustion occurs based on results from 3 min ALL OUT testing.

n=12

What I did here was to look for the moment in time during the 3min AOT where W'bal remaining first dips under 500 J prior to the start of the 30 s rolling average period which corresponds to CP.

IOW how does it take to deplete that remaining 500 J if you are compelled to continue?

Time in sec (SD) from W'bal(500 J) to attainment of CP = 46 (15) sec

Power above CP at this moment in time = 24 (11) W

Time from start of 3 AOT test = 85 (19) sec.

So basically what this is saying is that on average (in 12 well trained cyclists) if you hit the 3 min ALL OUT test with everything you've got, it will take about 85 sec to reach W'bal = 500 J. Anyone who has done this test knows that 85 sec into an ALL OUT max effort is pure torture.   At that moment in time, you are about 24 W above your CP.  If you are compelled to keep going (eg: you commenced your sprint early, got a gap, but you're running out of steam before the line, so you've just gotta keep going), then it will take about another 46 sec before your power will finally decline all the way to CP.

 

From a practical perpsective it is a reasonabe assumption that people will voluntarily stop exercising (if they are not compelled to continue) with a small amount of W'bal left in the tank.  

What it also helps us to understand is that if you flag points in the ride file where you state "exhaustion" occurs.  Then it is worthwhile just checking to see what the power actually was at that moment in time.  If it is a lot more than 25 w above CP, this can mean a couple of things 1) you're underlying or background state of fatigue (from ATL) is higher than what it was when you tested for CP + W' originally, and/or 2) the moment you flag as exhuastion isn't really the best you can do. eg: if your power is 500 W and your CP is 300 W and you reckon you're totally spent, well you need some concrete in your bidon and HTFU.

It would be a bad idea to run the solver in these cases where you are fatigued from heavy ATL, or you just didn't do a full max effort.  Lastly, if the power IS within 25 W of CP, you flag the effort as a full max exhaustive effort, but you notice that W'bal (prior to running the solver) is a long way from 500 J eg: it is 3.5 kJ, this can also reflect accummulated fatigue from heavy ATL.

For these reasons, the solver tool should be treated as a performance test function.  It should only be run on rides where you feel good and able to produce PB or near PB efforts on current form.

[Nathan Townsend]

On Tuesday, 5 April 2016 16:37:37 UTC+3, Nathan Townsend wrote:

Time from start of 3 AOT test = 85 (19) sec.

I've got some other data on wingate testing on a different group fo subjects.  This shows that W'bal get be almost depleted on the 1st 30 sec bout of a wingate test, but more often it requires two bouts.

There is evidence that any all out sprint effort longer than only 15 sec ends up getting subconsciously paced ie: it is almost impossible to achieve the same peak power (or peak 10 sec average) when you do a 15 sec all out test compared to a 3 min ALL OUT test.  Pacing occurs whether you like iot or not.

This would explain why it took nearly 85 s to get W'bal down to 500 J despite an "alleged" all out effort, whereas if you know you only have 30 s, then it only take one or two 30 sec wingates to achieve the same.

60 sec might be a happy medium ie: if you do an ALL OUT 60 sec effort it might be possible to fully expend W' in that duration.  A max effort 1 min CWR test leave W'bal left in the tank at the moment of task failure.