Dumbo's feather

[Mark Liversedge]

TSS IS NOT ADDITIVE

The problem of TSS additivity is shown in this single chart:

You will see that TSS (the green line) has a drift over time. This is related to the interplay between the NP calculation and the TSS calculation. When plotted it became clear that it has a classic shape, that of a root curve.

What is particularly interesting is the drift is present regardless of power i.e. it is systematic and related directly to the way TSS and NP are calculated.

From a physiological perspective it is obviously deeply flawed; up until now it has always been considered a problem when resting at the end of a ride; hence the infamous 'beer and burrito' rule of thumb (if you stopped for time to drink a beer and have a burrito split the ride to avoid TSS inflation).

But you can see from the above that this inflation occurs over time, regardless of whether you are pedalling or not. Which of course means that longer rides will score more highly for no reason.

In the chart above you will see TSS2 or as I'm calling it 'cTSS' does not have the same problem. It is additive. It is consistent regardless of whether you apply it to one ride of 9 months duration, or if you apply it to 250 separate rides over a 9 month period.

REMOVING THE SYSTEMATIC DRIFT

So, in order to remove that systematic drift we need to reverse it, and it turns out all we need to do is reverse that root curve drift. So yeah, we take the square root of the dimensionless (time) terms. And hey presto we get the blue line in the curve above.

You can try it for yourself in v4 *, I have defined a custom ride data series below:

And a custom metric cTSS, and used it as an input into the PMC:

Now you can use these to show how the cTSS grows with work done through a ride, and then the result in the PMC is the numbers will be scaled back -- but as a factor of ride duration -- TSS was inflated as ride length grew. So if all you do is SST rides for an hour and 40km TTs, you probably never noticed how it seemed to be easy to rack it up on long rides doing very little.

DUMBO LOST HIS FEATHER

Of course the implications to this are rather considerable, there is a lot of woo around  CTL/ATL and TSS and what specific values mean.. we will just have to start unpicking that now it is a more meaningful metric of stress. I'm sure there will be a heated discussion and debate. But ultimately it now is more meaningful.

One of the big things here is the way TSS is accumulated on rides of less than an hour -- very short rides may have a slightly higher cTSS, depending on what you do. This is something I'll blog in a more detailed exposition. And for the record, the insight was provided by someone who prefers to remain anonymous as a 'gift to you guys', I didn't have the smarts to work it out.

Mark

* it will need a fix I just pushed regarding using NP in custom ride series.

[Mark Liversedge]

Just to show how massively skewed (BROKEN) TSS is to ride duration here is the correlation matrix.

[I will post p-values once I've fixed my R install to get package Hmisc]

               TSS          IF      cTSS    Duration
TSS      1.0000000  0.26423835 0.9011881  0.93316299
IF       0.2642384  1.00000000 0.5809284 -0.05868783
cTSS     0.9011881  0.58092836 1.0000000  0.72580728
Duration 0.9331630 -0.05868783 0.7258073  1.00000000

And some obligatory scatter plots

It would be interesting to compare this with data from folks that have a more varied training plan than me, I ride similar routes all year every year. But the data still shows a massive correlation to duration -- but really the killer chart is in the original post that shows the systematic drift built in to the flawed calculation of TSS.

Mark

[Lucas]

From a physiological perspective it is obviously deeply flawed; up until now it has always been considered a problem when resting at the end of a ride; hence the infamous 'beer and burrito' rule of thumb (if you stopped for time to drink a beer and have a burrito split the ride to avoid TSS inflation).

Hi Mark,

just pausing the Garmin doesn't avoid this TSS inflation? splitting the ride is really needed to do this?

cheers

[Mark Liversedge]

Exactly. The inflation is systematic. But is made much worse when a ride contains coasting.

When you start tracking coasting time you may be surprised how much you have as well, for me this is on long hilly rides and recovery day rides. Both are inflated considerably.

I have now got a better formulation from another person which has the same ratios as the one here, but is dimensionally correct and therefore additivity is complete (we had problems with rides shorter than an hour with the one shown above). 

I am in the process of writing it up and getting some examples. I will be particularly interested to hear from anyone that collects RPE data with better discipline than I do, to see if cTSS tracks RPE better, since it seems to for me but I'm not so good at collecting it.

Mark 

[Mark Liversedge]

The formulation used has been improved by Daniel Besse, I've put his proof into the GC repo you can get it here:

https://github.com/GoldenCheetah/GoldenCheetah/blob/master/doc/contrib/cTSS.pdf

It means that the cTSS formula is truly additive and still dimensionally correct, so coasting doesn't inflate the score, and you can split and combine rides with the same mathematical outcome. i.e. it is a coherent formulation.

It tends to affect recovery, hilly, mountain, track, crit, group and mountain bike rides where time spent coasting will be 10%-30% depending on the race/course etc.

It means that the absolute values for cTSS are slightly lower than TSS. See the distribution plot below, TSS is blue, cTSS is red. This is for my data but I see a similar pattern for other datasets I have tried.

I'm working to get some analysis of RPE-TSS v RPE-cTSS to see if it improves that issue.

Here is a good example of inflated TSS, a hilly ride with lots of coasting on the downhills, it really helps to show how cTSS and TSS differ in these circumstances.

CHEERS

Mark

[TJDunnigan]

Thanks, Mark.

This is a dramatic illustration of the effect. It helps me understand better why an hour on a trainer is so much more tiring (next day) than an hour on the road.

[Mario Crisafulli]

Dear Mark,
I'm not sure if I'm doing anything wrong here... if I create a the "User Defined Metric" exactly as it shows in your screenshot:

{

# calculate metric value at end

value { (NP/config(ftp))^2 * (Duration^0.5/3600^0.5) * 100; }

count { Duration; }

}

when I click "save" and then open it again, it shows as:

{ \n # calculate metric value at end\n value { (NP/config(ftp))^2 * (Duration^0.5/3600^0.5) * 100; }\n count { Duration; }\n}

For the records, I'm using the latest v4 build (1602) on Wndows 7 64bit.

If that's a bug I'm happy to raise a bug report

Cheers,

Mario

[Mark Liversedge]

OH POO. its a bug, I've just fixed it.

BTW, the dimensionally correct version is: (NP / config(ftp))^4 * (Duration/3600) * 100

I will get the development builds re-issued with this fix.

Mark 

[Mario Crisafulli]

That's great, thank you! :-)

Then I'm looking forward to put my hands on the next build.

Kind regards,

Mario

[Mark Liversedge]

On Sunday, 21 February 2016 16:01:57 UTC, Mark Liversedge wrote:

I'm working to get some analysis of RPE-TSS v RPE-cTSS to see if it improves that issue.

A friendly coach has supplied several seasons of data from tour pros, lets call them Pro A and Pro B.

Both ride a variety of intensities and durations:

There is a small bump in IF for long rides, pros have more time!

In terms of the difference in TSS v cTSS distribution A and B look very similar. Red is cTSS and Blue is TSS. The distribution has been squeezed, 300+ is rare, rather like data from non-pros.

Now both of them log RPE for every ride, and this seems to correlate very well with IF as you would expect, and the envelope shows how it relates well to a maximum and drops off, which the coach will use to indicate fatigue or strain. (As an aside its interesting how infrequently Pro A says its over 5).

The relationship between RPE and TSS/cTSS is inconclusive, there doesn't seem to be much we can draw from this, its rather similar.

and

There are some things we can draw from this that may be meaningful:

• Recalibrating 'meaning' from TSS to cTSS values seems quite straight forward.
• For disciplines/workouts with coasting, cTSS does not inflate like TSS 
• For data with gaps in recording cTSS is consistent where TSS needs the 'beer/burrito' rule
• For general tracking it makes no real difference since TSS inflation is systematic
• When shifting from the small to the large (intervals->ride->seasons) the additivity issue becomes critical.

So from my perspective, whilst TSS is broken, its good enough for the level of analysis available (e.g. PMC). But the cTSS correction will assist when wishing to apply performance models across intermittent exercise, training blocks and even multiple seasons.

Mark

 

[Salvatore Iovene]

Hello Mark,

thanks for this interesting perspective!

I'm running GC from git master, and I managed to add a custom metric for the cTSS and also to feature it in a bar graph of my cTSS/(time period).

However I have no idea how to get a PMC graph based on cTSS. Can you please advise?

Thanks!

  Salvatore

[Mark Liversedge]

On Monday, 22 February 2016 19:17:58 UTC, Salvatore Iovene wrote:

I'm running GC from git master, and I managed to add a custom metric for the cTSS and also to feature it in a bar graph of my cTSS/(time period).

If you called the metric 'cTSS' then this will work, just save to a file ending with '.xml' and drag and drop it in.

https://gist.github.com/liversedge/e9fb0e9435e7b29b78c0

I will publish it to the cloud chart database. Joern is already looking at how we can include custom metric definitions in the chart file to enable sharing.

Mark 

[Salvatore Iovene]

On 22 Feb 2016, at 21:24, Mark Liversedge <liver...@gmail.com> wrote:

On Monday, 22 February 2016 19:17:58 UTC, Salvatore Iovene wrote:

I'm running GC from git master, and I managed to add a custom metric for the cTSS and also to feature it in a bar graph of my cTSS/(time period).

If you called the metric 'cTSS' then this will work, just save to a file ending with '.xml' and drag and drop it in.

https://gist.github.com/liversedge/e9fb0e9435e7b29b78c0

Thanks Mark, that worked!

One thing that’s missing, it seems, is the ability to override this metric for rides done without power. I can override TSS with my estimation, but the “Details -> Metric” page, on an Activity, doesn’t offer me the ability to override the cTSS.

Am I missing something or is GC?

Thanks again!

  Salvatore

[Mark Liversedge]

On Monday, 22 February 2016 19:34:42 UTC, Salvatore Iovene wrote:

One thing that’s missing, it seems, is the ability to override this metric for rides done without power. I can override TSS with my estimation, but the “Details -> Metric” page, on an Activity, doesn’t offer me the ability to override the cTSS.

https://github.com/GoldenCheetah/GoldenCheetah/wiki/FAQ-METRICS#How-do-I-add-a-metric-to-the-details-screen-so-I-can-override-it- 

[Stefan Lorenz]

Hi,

I have TSS and cTSS in the PMC chart now,

but how did you get the stress chart in the activties tab?
I'm really impressed about the endless possibilities of GC :-)

[Mark Liversedge]

On Monday, 22 February 2016 21:18:58 UTC, Stefan Lorenz wrote:

Hi,

I have TSS and cTSS in the PMC chart now,

but how did you get the stress chart in the activties tab?

You can define a User Data series.

Use the formulas;

((NP/config(ftp)^4 * SECS/3600 * 100

((NP/config(ftp)^2 * SECS/3600 * 100

For TSS and cTSS respectively.

It computes at each point through the ride and plots it.

Note that "config(ftp)" will honour the 'use FTP for Coggan metrics' setting.

Mark 

[Mark Liversedge]

On Monday, 22 February 2016 21:25:24 UTC, Mark Liversedge wrote:

((NP/config(ftp)^4 * SECS/3600 * 100

((NP/config(ftp)^2 * SECS/3600 * 100

Sigh.

I mean:

(NP/config(ftp))^4 * SECS/3600 * 100 

(NP/config(ftp))^2 * SECS/3600 * 100 

Mark

[Salvatore Taibi]

This is great, and since I do a lot of long rides I expect to see a large disparity. I've never felt the PMC told me much, and I've been desperately searching for an alternative. Thanks!

Ok, my question is how do I create a CTL/ATL/TSB using cTSS? I've created the metric, but I'm not following how to use it as an input to the other metrics.

[Salvatore Taibi]

Sorry, running the latest dev on Mac OS...

[Stefan]

This really is a great improvement! As a mountain biker I too have noticed the disparity between my long indoor rides (winter can be harsh here) and my training rides outdoor. Here is an example from yesterday:



All three descends were not very technically (but nontheless fun). So I wouldn't count these as training.

The standard TSS is 200. Quite a lot when I compare this to similar workouts in my basement. cTSS comes out at 105! Frustrating but I must admit the figure is more realistic.

I've often wondered if it wouldn't be better to derive TSS from "time spent in zones". But that just changing the exponenent will have such an effect is really amazing.

[Mark Liversedge]

On Tuesday, 23 February 2016 10:14:22 UTC, Stefan wrote:

The standard TSS is 200. Quite a lot when I compare this to similar workouts in my basement. cTSS comes out at 105! Frustrating but I must admit the figure is more realistic

Hi Stefan,

Thats really useful. Bear in mind the cTSS number is scaled differently, so 100 cTSS should still be a hard ride (I think).

It would be really useful to get a sense of the TSS -> cTSS relationship is for MTB rides that you would consider easy, moderate, heavy or severe. The typical spread seems to be in the range 0-300 for cTSS vs 0-400 for TSS. I wonder if MTB may be one area where cTSS is more meaningful than TSS. Can you find 2 or 3 examples and share any insight ?

Mark

[Stefan]

Here are 4 examples, easy rides get scaled down. Which mirrors my "feeling" after these rides. I did a lot of long E2 rides this autumn/winter. Accumulated huge TSS numbers. But these did not reflect my "felt" strain.

The race was a podium position in the >40 age group.

[Stefan Lorenz]

Thx,

that worked fine.

But I had to ad it in the "Ride" chart, because there is no "Stress" chart in my activity tab. And in the "add diagramm" menu there is no "Stress" chart...

I'm using the latest dev version under Windows 10 with german language...

[Mark Liversedge]

On Tuesday, 23 February 2016 12:08:28 UTC, Stefan Lorenz wrote:

Thx,

that worked fine.

But I had to ad it in the "Ride" chart, because there is no "Stress" chart in my activity tab. And in the "add diagramm" menu there is no "Stress" chart...

Ah, you may need to view > reset layout to get the latest default setup. But that will lose your changes.

[Stefan]

I've just installed GC v4 and have implemented a cTSS PMC. Interestingly, cTSS-PMC does not differ from TSS-PMC. It is at a lower level but the pattern is the same. Even though those long Z2 rides were scaled down it did not make a difference for PMC.

[Stefan]

And here are my TSS CTL and cTSS CTL. cTSS is a little bit more damped. Mmmmm ... does not really help

[Mark Liversedge]

On Tuesday, 23 February 2016 18:22:50 UTC, Stefan wrote:

And here are my TSS CTL and cTSS CTL. cTSS is a little bit more damped. Mmmmm ... does not really help

Indeed. 

You can input Distance, Duration, Work, TSS, Heartbeats or many other approximations of work done and get pretty much the same shape PMC curve..................

Mark 

[Mark Liversedge]

e.g.

 

[Mark Liversedge]

And who needs a 3 grand power meter when all you need is a HR strap ?

;)

Mark 

[Stefan]

So why the discussion at all? Why the thread on Wattage?

[Mick Drake]

Well I have a HR strap... if only I understood what this is all about LOL

[Mark Liversedge]

On Tuesday, 23 February 2016 19:27:20 UTC, Stefan wrote:

So why the discussion at all? Why the thread on Wattage?

OK, maybe I was being flippant.

A few dimensions to this, but I want to explore, from a plan and track feature perspective:

(a) Factor selection :- to what extent are current metrics independent of each other

(b) Indirect measures of physiology :- can we track physiological processes and infer anything with existing metrics

(c) Direct measures of performance :- can we measure and track performance (see a)

(d) Measures of impulse :- can we measure and track stress and/or strain (see a and b)

(e) Impulse-Response :- can we see any relationship between d and c 

A friend suggested an improvement to TSS, I found it interesting. Its mostly related to d. FWIW, I think heartbeats and work are two of the most important measures since they are *direct* measures of external output and internal response.

Mark

[Mark Liversedge]

On Tuesday, 23 February 2016 19:28:21 UTC, Mick Drake wrote:

Well I have a HR strap... if only I understood what this is all about LOL

Quite seriously, track load by counting heartbeats. i.e. use heartbeats not TSS as an input into your PMC.

Mark 

[Stefan]

OK, maybe I was being flippant.

yes, a little ;-)

[Eric Griffin]

What about the influence of external factors on HR like temp, stress, fatigue, hydration, nutrition, etc? I don't think HR is really a direct measure. I am not a scientist, but that doesn't seem to jive with everything I have learned as an endurance athlete over the past 25 years.

[Mick Drake]

I think I have jumped into a pool that is far too deep for me......

This is me WWW.mickdrake.com

But I do really enjoy what this is all about.

[Mark Liversedge]

On Tuesday, 23 February 2016 20:17:34 UTC, Eric Griffin wrote:

What about the influence of external factors on HR like temp, stress, fatigue, hydration, nutrition, etc? I don't think HR is really a direct measure. I am not a scientist, but that doesn't seem to jive with everything I have learned as an endurance athlete over the past 25 years.

Yes, HR is influenced by lots and lots of things, if we were to use it to set intensity zones then day-by-day it will fluctuate quite wildly leading to all sorts of problems. That's why PM are really useful.

But as a measure of training load, over days and weeks, it works pretty well, certainly with the data I have looked at.

Mark 

[Mark Liversedge]

On Tuesday, 23 February 2016 21:12:41 UTC, Mark Liversedge wrote:

But as a measure of training load, over days and weeks, it works pretty well, certainly with the data I have looked at.

Here is 6 years of data from a gifted amateur (cycling only).

Mark 

[Eric Griffin]

I hear ya, that makes sense. And certainly the charts you have posted are promising! 

Doesn't Strava have its "suffer score" based of HR?

[Alex Harsanyi]

On Saturday, February 20, 2016 at 6:53:50 PM UTC+8, Mark Liversedge wrote:

Just to show how massively skewed (BROKEN) TSS is to ride duration here is the correlation matrix.

[I will post p-values once I've fixed my R install to get package Hmisc]

               TSS          IF      cTSS    Duration
TSS      1.0000000  0.26423835 0.9011881  0.93316299
IF       0.2642384  1.00000000 0.5809284 -0.05868783
cTSS     0.9011881  0.58092836 1.0000000  0.72580728
Duration 0.9331630 -0.05868783 0.7258073  1.00000000

Hi Mark,

The fact that TSS is so stronly correlated with duration is not
really a surprise, after all TSS = Duration_Hours * (IF ^ 2) *
100, where IF = NP / FTP.  Most IF values would be between 0.7
and 0.9 and squaring them will narrow the range of the multiplier
on duration.

If you change the formula to cTSS = sqrt(Duration_Hours) * (IF ^
2) * 100, the correlation remains, but now cTSS is a function of
the square root of duration.  The "normal" correlation fromula
only detects linear correlations so the correlation appears to be
lower, but really isn't.

Also, I don't really understand how cTSS accounts
for "freewheeling" time, where power is 0.

My understanding is that NP, being a kind of average power,
already accounts for the portions of the ride where power is 0.
However, the way the NP formula is designed, it will give less
weight to lower power values and more weight to higher power
values.  If you think TSS values are inflated, you might want to
try using average power instead:

  cTSS = (avg_power / FTP) ^ 2 * Duration_Hours * 100

The TSS and cTSS values also depend heavily on FTP.  A 5% error
in the FTP value will result in a 10% error in the TSS and cTSS
computations.  To get an accurate PMC, one would need really
accurate FTP values.

Best Regards,
Alex.

[Mark Liversedge]

On Wednesday, 24 February 2016 06:09:29 UTC, Alex Harsanyi wrote:

On Saturday, February 20, 2016 at 6:53:50 PM UTC+8, Mark Liversedge wrote:

Just to show how massively skewed (BROKEN) TSS is to ride duration here is the correlation matrix.

[I will post p-values once I've fixed my R install to get package Hmisc]

               TSS          IF      cTSS    Duration
TSS      1.0000000  0.26423835 0.9011881  0.93316299
IF       0.2642384  1.00000000 0.5809284 -0.05868783
cTSS     0.9011881  0.58092836 1.0000000  0.72580728
Duration 0.9331630 -0.05868783 0.7258073  1.00000000

Hi Mark,

The fact that TSS is so stronly correlated with duration is not
really a surprise, after all TSS = Duration_Hours * (IF ^ 2) *
100, where IF = NP / FTP.  Most IF values would be between 0.7
and 0.9 and squaring them will narrow the range of the multiplier
on duration.

If you change the formula to cTSS = sqrt(Duration_Hours) * (IF ^
2) * 100, the correlation remains, but now cTSS is a function of
the square root of duration.  The "normal" correlation fromula
only detects linear correlations so the correlation appears to be
lower, but really isn't.

Yes. I wanted to find a way of showing the bias towards duration in the TSS calculation vs cTSS.

It wasn't a very good way of showing that.

 

Also, I don't really understand how cTSS accounts
for "freewheeling" time, where power is 0.

My understanding is that NP, being a kind of average power,
already accounts for the portions of the ride where power is 0.
However, the way the NP formula is designed, it will give less
weight to lower power values and more weight to higher power
values.  If you think TSS values are inflated, you might want to
try using average power instead:

Yes NP accounts for short periods of zero power by smoothing it by raising power ^4 then taking the 4th root.

This is supposed to account for the variability of power data when compared to the stress it would apply.

At longer durations (measured in a minute or more) NP drops very slowly when power is zero. 

And thats where the problems begin. And why "NP busters" tend to have short bursts of effort above FTP followed by lots of recovery.

Now for the general case, that isn't a problem, but when you spend 20-25% of a ride coasting, NP is going to be inflated.

So yes, you could use AP instead, and I will look at that, but the simplest way of resolving issues with NP when including it in the TSS calculation is to account for this by increasing the rate of decay. Since TSS has artbitrary units it doesn't matter if it accumulates slightly more slowly. But if we do ^4 it now also accounts for longer periods of freewheeling, whilst still letting NP do its thing for shorter durations.

But lets be clear; its a small improvement to one part of the problem.

 

  cTSS = (avg_power / FTP) ^ 2 * Duration_Hours * 100

The TSS and cTSS values also depend heavily on FTP.  A 5% error
in the FTP value will result in a 10% error in the TSS and cTSS
computations.  To get an accurate PMC, one would need really
accurate FTP values.

BINGO!

I couldn't agree more. The whole Power > NP > TSS > ATL/CTL > TSB is a blunt tool with huge margin for error.

By the time you've taken a derivative of a derivative of a derivative you're left with something akin to homeopathy.

Add in the margin of error on FTP and you might as well use a horoscope.

The one thing that the PMC gives is a measure of recent work vs past work (TSB).

We can use that as an indicator of overreaching etc -- but its very very blunt

Is it positive or negative? It it right or wrong? (TSS/FTP error etc).

There are a lot of people making a lot of claims about absolute values of TSB, CTL, TSB, RR etc.

They associate different values different meanings, they have rules about when the values mean something and when they don't.

I think mostly they're just reading tea-leaves.

But its all we have at present, which is a shame.

We all deserve something better.

Mark 

[Mark Liversedge]

On Wednesday, 24 February 2016 07:36:55 UTC, Mark Liversedge wrote:

Now for the general case, that isn't a problem, but when you spend 20-25% of a ride coasting, NP is going to be inflated.

So yes, you could use AP instead, and I will look at that, but the simplest way of resolving issues with NP when including it in the TSS calculation is to account for this by increasing the rate of decay. 

I used AP instead (but obviously no need to square it).

It looks like this (its in pink):

Mark 

[Alex Harsanyi]

On Wednesday, February 24, 2016 at 4:27:19 PM UTC+8, Mark Liversedge wrote:

On Wednesday, 24 February 2016 07:36:55 UTC, Mark Liversedge wrote:

Now for the general case, that isn't a problem, but when you spend 20-25% of a ride coasting, NP is going to be inflated.

So yes, you could use AP instead, and I will look at that, but the simplest way of resolving issues with NP when including it in the TSS calculation is to account for this by increasing the rate of decay. 

I used AP instead (but obviously no need to square it).

It is not obvious to me why there is no need to square it?  It is not consistent with the definitions for TSS and cTSS.