Incorrect calculation of wind drag

[gedejong]

Dear maintainer,

First of all, thank you for all the hard work. While I was looking at my power numbers, I was wondering if the calculation might be wrong. I think I found a problem with the drag calculation for the power estimation. In GoldenCheetah/src/FileIO/FixDerivePower.cpp line 287 the following calculation is done:

W = cos(bearing - windHeading) * windSpeed * 0.27777777777778; // Absolute wind speed relative to cyclist orientation (m/s) which 'normalizes' the wind depending on the direction of the driver. In effect, a side-wind would have a wind speed of 0!

This, however, is incorrect for calculation of drag, since the bicyclist still has to cycle through that extra column of wind coming from the side. The correct calculation is not much more difficult and is detailed in A Practical Analysis of Ærodynamic Drag. This would effectively calculate the apparent wind speed and velocity, calculate the drag on that, and then apply it to the forward component of the bike.

I would love to make this change, but I simply do not have the development setup here yet. Would anyone like to pick this up?

[gedejong]

see also this wonderful article from 1984

[amtriathlon]

I would love to make this change, but I simply do not have the development setup here yet.

If you enable Travis and/or AppVeyor for your fork, ci-builds will happen everytime you push to your master branch, and they will generate downloadable artifacts ready to install or use. For simple changes it may dispense the need to have a local build environment.

Would anyone like to pick this up?

It seems highly unlikely to me.

[gedejong]

I'll try to write the correct version in one go. I have the correct calculations in Python. I also want to show the difference in energy expenditure on an average ride. Is this functionality not used? For me it was one of the primary reasons to get introduced to Golden Cheetah.

[amtriathlon]

It tends to be used only mostly by new users without power meters, until they understand you really need one if you want to use power data in any serious way for general outdoor cycling, IME.

[gedejong]

From a training perspective, this would be useful if the athlete would know the components of the power required for the intended speed. Also, I think the mistake I indicated above makes a huge difference when cycling in cross wind.

So, if I would design this from scratch, I'd write this using a Kalman filter, with a rather big margin on the windspeed. Thinking about implementing this in Python right now.

[amtriathlon]

The wind effect is handled according to Validation of a Mathematical Model for Road Cycling Power, assuming the CdA parameter is the one corresponding to the direction of advance, to account for the yaw you would need to measure how CdA changes with yaw. Anyway, GoldenCheetah Data Processors, s.t. Power estimators, can be implemented completely in Python without the need to change source code or rebuild to test your ideas, see: https://github.com/GoldenCheetah/GoldenCheetah/wiki/UG_Special-Topics_Custom-Data-Processors-in-Python

[gedejong]

First of all, you used a very interesting article (now I wonder if there is more modern literature on the subject as well). I've read the parts of the article that detail the calculation of the air velocity of the bike and the adjustment of the drag area and skipped over drivetrain efficiency and such.

It is interesting to see that the authors do consider that the drag area changes, but they do not take into account that it is the total amount of air that slices through the rider and bicycle that 'drags' on the bicycle. And that amount of air is determined by the combination of the wind vector plus the rider vector. So, for example, when you are riding at 10 km/h and you have a side wind at 10 km/h, the amount of air reaching you is coming at 14 km/h. That whole column needs to open and close around the driver (and thus drags).

The reason why the authors of the article didn't see their mistake is because the wind speed is relatively low in their experiments (2.3 m/s of wind vs 6.8 m/s of rider speed). You can see it in the table: their modelled air speed is almost the same as the rider speed. However, they should have calculated something like sqrt(2.3^2 + 6.8^2) = 7.1 m/s. And here you see just a small change. It's 4% higher.

Here in the Netherlands, we often have a moderate breeze at around 25 km/h (7 m/s) or higher. In that case, this side component becomes very relevant.

The CdA component with changing yaw angle is indeed interesting. I am really surprised to see that the drag area reduces when the yaw angle increases! Nevertheless, it could be all the same within the error of measurement.

(And while I am digging further into this topic, I find this very accessible article from SystemSix, see page 46: http://aerogeeks.com/wp-content/uploads/2018/07/SystemSix_Whitepaper_June28.pdf)

Also, I hope you appreciate this. I understand it would make sense to do further calculations all in Python. In addition, I would love to have these calculations before a big race, to make some estimates of the amount of power and energy required at specific stages. So, even though power meters have become more accessible nowadays, it helps to understand the various aspects of drag in order to make informed decisions during training and matches.

[amtriathlon]

I think unless you have an onboard anemometer, to further refine the calculations is moot to estimate power in an outdoor ride, which is the purpose of the builtin data processor. The forum is a better place for this, you may find interested users there to discuss your findings and test your Python data processors scripts for other applications s.t. to estimate the required power to ride in given conditions.