Acceleration & deceleration equations.

[ekhmuel]

I've been trying to set up a spreadsheet to give me 'thumb estimates' of various journey characteristics. It compares costs of infrastructure to costs of moving along certain routes. E.g. Barges move 50 units per vehicle for almost identical running costs as that of narrow boats (at 17 units), but narrow boats have lower inf. maint. It's quite complicated, it even factors in whether a route already exists along part of the region.

I've actually got it nicely accurate (if complex), but to add a bit more accuracy, I'd like to put in acceleration and deceleration modifications - for both hills and stop/start.

I've found however that the 'printed' estimates do not match my own calculations.

E.g:

The GWR 1400 class:
42000kg mass
149 kW of power,
62 kN of tractive force,
21 kN or braking force
63 N of rolling resistance
top speed of 80km/h
distance to stop when on it's own is quoted in the depot as being 470m

An example of my own calculations:

* Force=mass*acceleration   =>     acceleration=force/mass (a=F/m)

* A unit that decelerates constantly from top speed will travel:

distance = 0.5 * V_top * time    in the time it takes to decelerate to a stop.

* A vehicle of deceleration rate a will take (V_top/a) time units to decelerate to a stop.

* As a=F/m,  time to stop = (V_top * m)/F

* Therefore the distance travelled while braking to a stop from top speed is:

0.5 * V_top^2 *m /F


* (80 Km/h is 22.22222 m/s)

For the quoted loco,

d = 0.5 * 22.222222^2 * 42000 / 21000 = 493.827 m , not 470m

Even if you take rolling resistance into account, then it is still some distance off.

In addition, as it has 62kN of tractive force, then it should accelerate from standstill to top speed on a flat straight line in 167m. It actually takes about 1250m (10 tiles) if you actually play the game. Again, roll resistance does not alter the result more than a few metres and this train has neither tender nor waggons.

So, just what equations (or procedures) are actually being used?

[jamespetts]

Bernd Gabriel is the one who set up the physics system in Experimental, which is different to Standard. I must confess, I do not know the inner workings of it, as it involves mathematics of a a complexity that is rather beyond my fairly basic abilities. For steam locomotives, I should note that the power figures are almost never available (as opposed to tractive effort figures), so these are back extrapolated from a few steam locomotives with measured performance characteristics and the physical characteristics of other locomotives (heating surface area, firegreate area, boiler pressure, etc.) are used to extrapolate power in the locomotives where performance data are unavailable. I should also note that the performance characteristics of steam locomotives are different for any given weight/resistance/power/force data than for diesel or electric locomotives because steam locomotives are constant force machines, whereas diesel and electric locomotives are constant power machines.

[ekhmuel]

One of the things I could do for the time being is set up an 'experimental database'.


It has been noted that the values for decels I calculated are so far within 5% of those quoted in the depot.


Also, perhaps some tests in the real game engine and perhaps set up a 'correlation' - perhaps one for road, for rail steam, for sailing, etc. That, even if a bit laborious, can be built into the spreadsheet.


If I run tests for example and find that steam trains consistently should be multiplied by a factor, then that might work for the mo.

[jamespetts]

An interesting idea. Do note that there is already a spreadsheet that I use for calculating steam physics, which you will find on the Github repository.

[DrSuperGood]

Due to the game requiring a high level of determinism in order to support multiplayer all calculations are computed in fixed point form (even if they some do not appear so directly).

This introduces a lot of potential sources of error during multiplication and division where fractional parts may be lost. Due to performance constraints any complicated function (such as exponent) might also only give a close approximation of what it should be. The results are good enough that someone in the game without knowing the inner workings or having a mathematical background could be fooled into thinking they are correct however in reality they are only correct within a certain error.

The industry code is full of this sort of error where fractional units of product are being lost all the time. One of the drives behind my JIT2 code for standard was to try and reduce the possible sources of error to boundaries (seldom occurrence) with the factory rather than as part of its inner workings (every tick).

That said it would be useful in the depot if approximations to acceleration were shown to the user. I have no idea how weight, friction force, tractive force and power convert into an acceleration, only that it says my convoy can reach maximum speed. Since you are paid for actual speed there are often times where acceleration is more valuable that speed. Ideally this should be a small graph somewhere with 2 or so times on it (time to half speed, time to maximum speed).

[ekhmuel]

Yes, I've noticed the rounding error many times. It is present for example on 'pulls 7km/h @24 tons' entries - usually off by a few percent.

An interesting idea. Do note that there is already a spreadsheet that I use for calculating steam physics, which you will find on the Github repository.

I'll have a look!


It is amazing how quickly this whole project grew - from simply trying to determine if the extra maintanace costs of a barge canal was offset by the lower running costs of the vehicles. I then asked - so just how much cargo do I want to move per month to make a barge vs narrowboat canal more useful? (The more traffic you put on it, they both get better, but the barge canals much better still.) E.g. - would you really use a barge canal to move 1 narrowboat's worth of cider per month? Now what if you had 1000 units?


Then - what if your system already had a barge canal going half the distance? As that part is already 'subsidised' by the line already running on it, it can be counted as 'zero maint.' (As you would be running it anyway). Yuo then only have to pay for half the maint and barges become more attractive yet.


When does a dogleg route (particularly if already there) become better than trying to bridge a valley? Longer route = less pay, but might have lower maint. That might be ok for coal - but what if you now want a bus service on it? So a bridge gets better perhaps as passengers pay for time taken much more.


I then decided to take a week laboriously logging the data from the commodities list for price:average speed calcs.


Then I asked myself what would happen if...........


Right now I want to check when a 'wavy line' route becomes inferior to a 'straight over the hills and down the side'.





It's a big, formal spreadsheet now complete with colour-coding and macros. Upto 250 'routes', each of upto 50 straight-line steps, to be entered as coordinates (I actually never use that many, but I threw it in incase). Each can be assigned to upto 30 'Option Classes'. It calculates how much your vehicles will actually mass for the journey and how fast they will go (all the vehicles and ways are put on a database). And will also even calculate timetabling, to a point. Very helpful for trains.


Currently, however, I'd had to use estimates for acceleration and deceleration. Can't do traffic jams yet either.


You'd be amazed how many surprising results you get for many journeys.


I might tidy it up a bit (user friendliness is not a current property, lots 'local knowledge' - of my thought-methods - needed) and offer it round.

[ekhmuel]

This people might find interesting for general purposes: (I read it years ago).

http://www.twoof.freeserve.co.uk/motion1.htm