Patch: Estimated maximum speed v2 (for r10586)

[Bilbo]

I have done some experimental patch to show real maximum speed of train

Changelog:

v2:
Now shows maximum speed with fully loaded wagons instead of wagons in current state (i.e. usually unloaded)
Cleanup: Moved code common to calculating train acceleration and estimating max speed to helper functions to avoid code duplication

Since the maximum speed of the train is valid only for the engine itself + maybe few wagons and real maximum speed depend on how much wagons is appended, decision of how many wagons you can append to engine and still maintain reasonable speed is then based only on rough guess. You overdo it, and the train will crawl. This way you can watch the real max. speed while buying wagons and stop when it dropt to values unacceptable fro you

For example for Chimaera with 50 armored wagons it will say Max. speed: 640 km/h (614 km/h)
And 614km/h is the real maximum speed on flat surface, as with so many wagons, the train won't go faster.

This is not fully finished, but it is working (you can see the max. speed in train details)

What should be fixed/improved:

• Determine why the calculation is 1-3 km/h higher than reality and fix it. Probably some rounding error.
• Calculate the speed by solving equation "force - resistance = 0", instead of trying increasing speed and recomputing while "force > resistance".
• Place the real. max speed so the text will not overflow the window width

How does it look

estimate-max-speed.png (14.25 KiB) Viewed 8696 times

[hertogjan]

The maximum speed may also depend somewhat on the amount of cargo that is loaded. This is true for all railtypes that "suffer" from mass-dependent rolling friction. Especially for the heavier cargos, the cargo weight can be as large as the empty train weight itself. So it is not a factor that can be totally ignored.

As for the solution of the equation force - resistance = 0, it is not so easy to solve that one using a closed formula that gives the solution. Since force is inversely proportional to speed, and resistance consists of terms that are constant, linear and quadratic in speed, this leads to a cubic equation in speed which is not easily solved. But maybe you can look for a method that approximates the solution, since an estimate will be good enough.

[Bilbo]

The maximum speed may also depend somewhat on the amount of cargo that is loaded. This is true for all railtypes that "suffer" from mass-dependent rolling friction. Especially for the heavier cargos, the cargo weight can be as large as the empty train weight itself. So it is not a factor that can be totally ignored.

As for the solution of the equation force - resistance = 0, it is not so easy to solve that one using a closed formula that gives the solution. Since force is inversely proportional to speed, and resistance consists of terms that are constant, linear and quadratic in speed, this leads to a cubic equation in speed which is not easily solved. But maybe you can look for a method that approximates the solution, since an estimate will be good enough.

Computing the value with fully loaded wagons is in my TODO list for this patch. Consider this as a preview :)

Basically the equation is now something like:

resistance = a * speed^2 + b * speed + c

force = const / speed
(for maglev if is simpler force = const)

+ there are few conditions like "if (force<minimum) force=minimum" which complicates the things a bit

So you'lll end up with trying to solve equation "a* speed^2 +b*speed +c -d/speed =0" - and try to find value of "speed"

Assuming speed is not zero (which wouldn't be the solution anyway :), you can multiply the equation with speed to get "a*sp^3 +b*sp^2+c*sp+d=0"

This could have theoretically 3 solutions in general case, but if you discard solutions with speed<=0 and pick lowest from the rest, I think you'll get the correct value (probably there would be only one solution for speed > 0 anyway).

But there are still the problems with clamping of various variables during the acceleration calculation, which makes exact numeric solution aquite harder

Only problem is when someone modifies the train acceleration code, you'll have to redo the calculations from scratch again ...

[Erendir]

The equotion a*x^3 +b*x^2+c*x+d=0 had 3 solutions:
One possibility is the following: (http://en.wikipedia.org/wiki/Cubic_equa ... c.2C_and_d)




where

and


and here are

and


(i hope the formula will help you)

[Bilbo]

The equotion a*x^3 +b*x^2+c*x+d=0 had 3 solutions:
One possibility is the following: (http://en.wikipedia.org/wiki/Cubic_equa ... c.2C_and_d)




where

and


and here are

and


(i hope the formula will help you)

Hmmm ... maybe I'll try rather search by binary splitting (is the force enough to maintain 300km/h? No. 150 km/h? Yes. 225 km/h? No. 188km/h? ......) If I'll precalculate all precalculatable variables, it may be faster than computing these equations (lots of third square roots, necessary test if this or that is>0 to be square-rootable + all this have to be done in floating point instead of integers -> there we have rounding errors)

This way 10 or 11 tests would be enough to pinpoint the correct speed from 0-640km/h range with 1km/h accuracy (which would be better than current state of making up to 640 calculations for that :)

And nothing will need chaning if I put calculations common to estimation and to real physics handling to helper function(s).

[athanasios]

I hope this progresses quickly and makes it into the trunk as soon as possible. It is extremelly helpfull.

[hertogjan]

(...)
Hmmm ... maybe I'll try rather search by binary splitting (is the force enough to maintain 300km/h? No. 150 km/h? Yes. 225 km/h? No. 188km/h? ......) If I'll precalculate all precalculatable variables, it may be faster than computing these equations (lots of third square roots, necessary test if this or that is>0 to be square-rootable + all this have to be done in floating point instead of integers -> there we have rounding errors)

This way 10 or 11 tests would be enough to pinpoint the correct speed from 0-640km/h range with 1km/h accuracy (which would be better than current state of making up to 640 calculations for that

And nothing will need chaning if I put calculations common to estimation and to real physics handling to helper function(s).

Ideed, like you say, the analytic solution is not a very good option, due to the presence of the square and cubic roots. It will be better to do an approximation. The method you suggest will eventually lead to an accurate answer, but it is not very quick, in the sense that you need a lot of steps to get a solution that is accurate enough. There are methods which converge faster to a solution. One example is by using tangent lines to the graph of the function. This involves computing the derivative of the function, but that is not a big problem. If you like I can give you more details about this method.

[Bilbo]

(...)
Hmmm ... maybe I'll try rather search by binary splitting (is the force enough to maintain 300km/h? No. 150 km/h? Yes. 225 km/h? No. 188km/h? ......) If I'll precalculate all precalculatable variables, it may be faster than computing these equations (lots of third square roots, necessary test if this or that is>0 to be square-rootable + all this have to be done in floating point instead of integers -> there we have rounding errors)

This way 10 or 11 tests would be enough to pinpoint the correct speed from 0-640km/h range with 1km/h accuracy (which would be better than current state of making up to 640 calculations for that :)

And nothing will need chaning if I put calculations common to estimation and to real physics handling to helper function(s).

Ideed, like you say, the analytic solution is not a very good option, due to the presence of the square and cubic roots. It will be better to do an approximation. The method you suggest will eventually lead to an accurate answer, but it is not very quick, in the sense that you need a lot of steps to get a solution that is accurate enough. There are methods which converge faster to a solution. One example is by using tangent lines to the graph of the function. This involves computing the derivative of the function, but that is not a big problem. If you like I can give you more details about this method.

There is question whether it is faster to take 5 more complex steps or 10 easier ones. Calculating derivative of a polynomial is trivial, so maybe I can try it ....

[hertogjan]

Oh, and I forgot to mention that the polynomial in question has exactly one positive root. That is under the assumption that the power (for traction force) is positive, and that the three coefficients for the resistance force are also positive. If one of the coefficients is zero*, then it may be possible that the derivative of the function is 0 for speed = 0. This may be a problem to look at when using the approximation method I told about in the previous message, which can only work in points where the derivative is unequal to 0. But as fas as I think of it now, it does no harm as long as your estimates remain positive**.

If you do not mind, I will also try to implement this feature in my physics patch, which uses a calculation that is somewhat different (although not much) from the realistic acceleration in trunk.


*This is true when the coefficient for the constant term in the resistance force is zero, which is true if the rolling friction is zero (true for maglev) and there is no other force that is constant in speed.
**In this implementation, it must be sufficiently positive, since overflows and underflows may prevent it from working properly.

[Bilbo]

Oh, and I forgot to mention that the polynomial in question has exactly one positive root. That is under the assumption that the power (for traction force) is positive, and that the three coefficients for the resistance force are also positive. If one of the coefficients is zero*, then it may be possible that the derivative of the function is 0 for speed = 0. This may be a problem to look at when using the approximation method I told about in the previous message, which can only work in points where the derivative is unequal to 0. But as fas as I think of it now, it does no harm as long as your estimates remain positive**.

If you do not mind, I will also try to implement this feature in my physics patch, which uses a calculation that is somewhat different (although not much) from the realistic acceleration in trunk.


*This is true when the coefficient for the constant term in the resistance force is zero, which is true if the rolling friction is zero (true for maglev) and there is no other force that is constant in speed.
**In this implementation, it must be sufficiently positive, since overflows and underflows may prevent it from working properly.

For very small speeds under 3 km/h there is special case that applies "extra accelerating force" , perhaps to push the train to go if the engine is weak (also, there are thing like "force=power/speed" so it is probably also to avoid division by zero :) ....

You can implement it in your physics patch, however it would be good if it would stay somewhow compatible, to avoid unnecessary rewriting of code. This could probably be easy, if you separate calculationg force and resistance to helper function, as I have done in last version of the patch - then it will require only little or no modification for my patch to work with your patch too, as my patch will query for force and resistance with this weight and this condition and your path will just answer. My patch will then determine the max. speed :). If you would do this that way, perhaps my patch can be applied independently of whether your path is installed or not and it will work :) Or at least with very little modification

[hertogjan]

I will look into your patch and try to see whether I can apply the ideas to the physics patch.

Note that in my patch most coefficients are not hardcoded but global constants/#defines; in the trunk version, the values are hardcoded and therefore it is harder to understand what is going on.

I will notify you in this topic when the work is done, or in a stage that it works sufficiently well.

[Bilbo]

Because hertogjan's patch at http://www.tt-forums.net/viewtopic.php?f=33&t=22995 redoes the train physics and also includes the same functionailty as this patch, I decided to halt development of this patch until the hertogjan's patch is either accepted into trunk (then this patch will be obsolete), or rejected by devs (then I'll resume the development).

Since hertogjan's patch does the job better, I hope for the first option (that it will get in trunk)