Predicted W'bal depletion

Now that I have running power (Garmin variant), I am trying to create some workouts based on power. I see very interesting the predicted W’bal depletion that is shown in the editor:

image

I can see that the short recovery will stress me on the following intervals because it is not a full recovery, and I will finish with 0 at the final one. That’s fine.

However, I do not understand why if I change the number of repetitions (up to 10, just to try), I can go more further than the 3 previous repetition, and finish with 0 at the end of all the intervals:

image

Am I missing something?

Check the values, it seems you are going to negative values and the scale for wbal in both charts is not the same, being the minimum the lowest wbal value achieved in each workout

2 Likes

Ouch… I see. So, several mistakes. I did not noticed the 0 line.

It seems that my pace zones do not correspond to power zones. I’ve done 2km at Z6 pace and 0.5km Z2 pace recovery on the past (last month) and I did not die. But reviewing the power zones, that intervals were on Z5 power, not Z6.

However, even changing the interval to Z5 power, I am going to negative:

Perhaps I have wrong my configuration due to my low experience in running power. I need to learn much more yet.

I have never used it for running but for cycling, going negative means that either W’ is set too low or FTP (or to be precise CP) is set too low or both.
Don’t expect to get spot-on results, W’ is only a very rough estimation of what you can do above FTP (CP).

2 Likes

Well, I have to say, it was promising. I’ve checked one hill activity workout:

And it was pretty much the same as the Garmin stamina graph of a past real activity:

That’s why I have started to think in the possibilities of the power based workouts.

What is the equation that defines the W’ recovery once you were under the FTP power?

This is the code that calculates W’ in Javascript (data = watts stream):

for (let i = 0; i < data.length; i++) {
  let t = time[i]
  let secs = t - pt
  let deltaW = secs < maxGap ? cp - data[i] : cp  // assume resting if there is a big gap
  if (deltaW > 0) {
    for (let j = 0; j < secs; j++) wb += deltaW * (wPrime - wb) / wPrime
  } else {
    wb += deltaW * secs
  }
  data[i] = Math.floor(wb)
  pt = t
}

So the recovery for each second under CP is deltaW * (wPrime - wb) / wPrime.

In Swift, calculated each second

if wPrime > 0 && cp > 0 {
      let deltaW = Double(cp - watt)
      
      if watt < cp {
        wPrimeBal += deltaW * (Double(wPrime) - wPrimeBal) / Double(wPrime)
        wPrimeBalPct = String(Int(round((wPrimeBal/wPrime * 100))))
      } else {
        wPrimeBal += deltaW
        wPrimeBalPct = String(Int(round((wPrimeBal/wPrime * 100))))
      }
    }