Topic: Nonsense rail physics?

[jamespetts]

That is not an entirely easy topic. It is often said that the steepest railway gradient in the UK is the Lickey Incline at 1 in 37, but in fact the line between City Thameslink and Blackfriars in central London is 1 in 27. 0.05% is 1 in 200, which, for a railway, is quite a gentle incline, and almost negligible for a road. Perhaps the shallower incline might be 1% (1 in 100) and the steeper incline perhaps 5% (1 in 20), making it largely impractical for a railway, and challenging for road vehicles. Of course, these should be really set in simuconf.tab if the code is to be modified, so these can easily be calibrated by in-game testing.

[Vladki]

I think, that for now it would be best to make the gradient for both half and full slope configurable, and also to remove the code that makes consecutive gradients steeper. This would allow for more experimenting and balancing.

[jamespetts]

I think, that for now it would be best to make the gradient for both half and full slope configurable, and also to remove the code that makes consecutive gradients steeper. This would allow for more experimenting and balancing.

Would it be not better to implement A. Carlotti's system for gradient steepness if one were changing this code? Of course, if one were making it configurable, one might simply have an option to turn on and off the Carlotti Gradient System.

Incidentally, as to gradient steepness: perhaps the maximum steepness of a gradient might be 1 in 30 or so, which would reflect the possibility of inclines such as that at Blackfrairs (albeit these are only really usable with electric trains; this incline was built long after the steam age, in the 1980s, I believe).

[Vladki]

Just a few links about the most extreme stuff

https://en.wikipedia.org/wiki/List_of_steepest_gradients_on_adhesion_railways
https://en.wikipedia.org/wiki/Baldwin_Street

ACarlotti's system of gradients looks nice. But I think we should first focus on getting simple gradients right (together with the rest of rollling and air friction physics). When I was studing the code I got lost a bit maybe due to the fact that the calcualtions are not always in SI units - mixing tons with kg, km/h with m/s, etc, etc...

[jamespetts]

Interesting information! I am not sure that there is much to be gained by improving gradients in two distinct stages rather than tackling it all at once, however.

[Vladki]

My idea is first to get right the physics with simple model, and then we can add the smoothing.

I was thinking how steep the gradients should be. Let's take the budweis-linz railway as an example, as if I'd like to make a model of this railway in simutrans.
The lowest point is Donau in Linz: 246 m above sea level. Vltava in Budweis is 379 m. Highest point at Kerschbaum is 709 m. Total distance is 128.8 km. In simutrans that is 1030 tiles (at 125 m/tile). Kerschbaum is exactly in the middle. There were 5 passing loops on the line - approx 20-22 km apart.

The question is how many height steps should the line pass? If we consider that full height slope is necessary for double-decker to pass under, it will be some 8 m. (4 m half height). That would be 82 half-height steps only for the nothern part, and 115 on the southern. That is too much for simutrans. Should we take the smae scale for height as for distance, we get 25 m for half-height (five levels make a cube). That would be 13 steps for northern half and 18 steps for southern.  A 1 % slope would be 1 half-height step every 20 tiles. That looks much better for long distance, but makes non-sense for single tile slopes...   

Nah, I can't come up with something tha would work equally well for both long distance (>10 km), and short distance - i.e. bridge over road/river.

[ACarlotti]

Under my proposed system, setting the smothing distance equal to (or less than) the tile distance would effectively disable it.

James: In terms of actually implementing this, I would be hesitant to deal with the configuration settings, but could probably manage the rest of the changes fine. So if you were to make a branch and add a gradient smoothing distance and a height per level setting to the configuration (and tell me how to access that setting), then that would be helpful for me.

[jamespetts]

Under my proposed system, setting the smothing distance equal to (or less than) the tile distance would effectively disable it.

James: In terms of actually implementing this, I would be hesitant to deal with the configuration settings, but could probably manage the rest of the changes fine. So if you were to make a branch and add a gradient smoothing distance and a height per level setting to the configuration (and tell me how to access that setting), then that would be helpful for me.

Certainly - I will branch from master rather than vehicle-management, as that is a complex project that will take many months to complete (and I have not been working on it for the last few weeks on account of being preoccupied with other things). I will let you know when this is done.

Edit: I have now added the relevant settings on the gradient_smoothing branch. I hope that this is helpful. Do feel free to change the names, units or default values if you think appropriate; it should be fairly straightforward to work out how to do so by looking at the commits.

[Vladki]

Further notes about horse power:

The original privilege to build the horse railway stated that a single horse should be able to pull 10 times more load on railway than on road. The official test proved that it can pull 30 times more. There's a picture of 2 horses pulling a road waggon loaded with 12 barrels (of salt), and a single horse pulling 3 rail waggons with 40 barrels each. So really 10 times more. Another picture shows 2 horses pulling 5 waggons. Other pictures show passenger transport with one coach pulled by 2 or even 3 horses (that was probably on the steepest part of track). Another report says about 2 horses pulling 2 waggons form Budweis to Kerschbaum, but then it was split in two for the descent to Linz. In general, all trains on the southern (steeper) part were split in two, and had extra horse for the steepest (>2%) part. More pictures here: https://de.wikipedia.org/wiki/Pferdeeisenbahn_Budweis%E2%80%93Linz%E2%80%93Gmunden.

One of the very first rides on unfinished railway was documented: 2 horses pulled 7 waggons with 14 tons of load "easily" at 30 km/day. Downhill towards Budweis, probably without changing horses, so they had to have a rest.

Passenger trains took 14 hours to travel the whole line, with 1-hour lunch break in the middle. (avg speed 10 km/h).
EDIT: German wikipedia says average speed 10 - 12 km/h erreicht, maximum downhill speed 15 km/h.

Cargo trains took 3 days. On the steepest part (2.17 %) they needed 2 horses to pull 1 waggon with 2.52 t of load.
Average over the whole line was that one horse on railway pulled 3.92 tons while one horse on road only 0.56 ton.

I could not find how fast were the cargo trains. But the timetable was that at 5 AM a passenger train departed from Budweis. Only after that they could load, assemble and dispatch a cargo train. It arrived at 10 AM to next station Holkov, changed horses and continued further on. Horses were fed, had a rest, and at 2 PM, another cargo train back to Budweis was dispatched. It had to arrive and unload before 7 PM when passenger train from Linz arrived. So I think the train must have gone the 20 km to next station in at most 4-5 hours, i.e. 5-4 km/h (EDIT: german wikipedia says 4 km/h average speed for cargo trains, and 40 km/day - no traffic during night)

Amount of horses for each train was dependent on the gradient of the section to the next station.
They needed 2x more horses for the southern half of line than for the northern.
In 1846 they experimented with oxen but not sucessfully.
In 1854 they experimented with steam engine on the wooden rails, but it was too heavy and damaged the track.

Another old report says about one horse pulling 100 barrels of salt downhill towards Budweis.
Some bridges were wooden, as there was a report of sabotage by burning a bridge. Other bridges were stone viaducts and survived today.

Fix about loops - there were stations every 20-22km where horses were changed (both cargo and passenger trains), but later some extra passing loops were added, probably every 7-8 km.

1868-1872 track was rebuilt for steam operation
And that's all I found in the book and other sources about this line

[jamespetts]

Thank you - that is very interesting.

[ACarlotti]

Nah, I can't come up with something tha would work equally well for both long distance (>10 km), and short distance - i.e. bridge over road/river.

Yeah, that is a difficulty. I think doing this properly might require allowing a larger range of possible tile heights and changes to the map generation system. But that's getting somewhat off the original topic, and away from my current experience (I haven't tried generating or playing very large maps yet).

[jamespetts]

I suspect that changing the map generation system would be much more difficult than the originally proposed idea; as for increasing the number of heights, this would require such an enormous amount of new graphics that it is probably not feasible at all.

[ACarlotti]

I think you misunderstood me. I'm not suggesting increasing the number of different tile slopes, just the range of possible tile heights. At the moment there seems to be some sort of limit to around 30-40 different altitudes, which would correspond to 150m-200m, and at these heights tile selection seems to be a bit buggy. If this altitude limit could be increased then we could have a higher range of possible altitudes - e.g. 256 would corrsepond to almost 1.3km, which encompasses almost the entire variation of heights in the UK.

My reference to the map generation system was based upon a couple of observations: firstly that such a large range of altitudes would probably require some modifications to the generation code just to give usable landscapes; and secondly, that on that sort of scale you might want roughness to vary across the map - e.g. there is a big difference in roughness between Scotland and southeast England.

In any case, this is not relevant to game balance, but could be something nice to have in the (distant) future.

[jamespetts]

Ahh, yes, I see: apologies for misunderstanding. I can see the merit in this: while it would still be quite a lot of work, it would at least not be an unmanageable amount.

[ACarlotti]

I've been investigating this a little (and have tested some interim code changes that fix the bugs but don't yet implement gradient smoothing) and am wondering if the problem lies in a poor understanding of the physics of horses. I probably need to think about the physics a bit more, but in essence my concern is that hooves don't work in the same way as wheels, and I am suspicious that the current physics engine may not allow for this.

So, two questions:
1. Have there been any issues observed in convoys not powered by horses?
2. Does it seem plausible that we have got the physics of horses wrong in some way? (An alternative explanation would be if the figures used were derived from how much a horse can pull, ignoring that it is also moving itself.)

[DrSuperGood]

Mechanically I imagine horses to work like normal road vehicles except with very good relative tractive force and breaking power for their power compared with a train.

Ultimately when climbing a hill tractive force and power is all that matters. If tractive force is too little then the horse would slip a lot so not be able to apply all its power. If the tractive force was minimal, eg horse on ice covered hill, then the weight of the coach will pull the horse backwards as the horse cannot apply any power. If the tractive force is excessive (spider man like hooves) then the up hill speed of the coach is entirely limited by mgh and frictional losses.

Assuming a coach weighs 1.2t with 11 passengers of 70kg each that is 1.97t of coach. This is the sort of coach one has in the late 1700s in Pak128 Britain. With a tile being 125m, a half height tile is an increase of elevation of 62.5m. Gravity is ~9.8m/s/s. Hence the total kinetic power converted into gravitational potential power by the full coach climbing up a single slope tile is {1970 * 9.8 * 62.5} = 1,206,625J of energy. Assuming a horse outputs 1 horse power (a reasonable although incorrect assumption) that is 745.7W. As such it would take a single horse {1,206,625 / 745.7} = 1618s = ~27minutes to climb a single height ramp. This results in a top speed of 0.077m/s or 0.278km/h, which is painfully slow. Now obviously it would take the horse longer in reality due to rolling resistance and other losses.

However no single horse pulls a coach. I imagine 4 horses being more reasonable so one can assume the time of ~7 minutes and 1.112km/h. Still very slow and sub 1km/h. If one averages out the half height slope over 8 tiles, 1km, then one gets a time of ~7 minutes at 8.899km/h, much more reasonable but still slow.

However a horse is not 1 horse power. A horse power is the amount of sustained power one can harvest from a horse over a 4 hour working period without straining the horse, eg using it to drive a mill every day. A horse is capable of considerably more than 1 horse power for short periods. Additionally larger or stronger horses which have less stamina might be capable of more power over short periods. As such for this example lets say the 4 horses apply 3 horse power each for the duration of a single height slop averaged over 8 tiles. The result is the climb takes a time of ~135 seconds or 2.25 minutes achieving a speed of 26.698km/h which well beyond the maximum speed a horse can go at so they would be having to use considerably less than 3 horse power.

So why not give the horse a value of 2 horse power or 1491.4W? Well the problem is that Simutrans Extended is simulating the horse itself as a load and not just the spare power from a horse, which is what a horse power is defined as. As such in real life a horse producing 1 horse power of power is actually producing a lot more due to having to move itself around in the process. Additionally a horse does not have wheels, so although mass acceleration formula do apply, standard rolling resistance does not. This is a big thing to consider as a horse weighs a good part of a ton itself and so requires large amounts of mgh energy to climb a half tile slope.

So what is the problem with horses and hills? Simutrans Extended does not support "stamina" and hence it cannot accurately simulate organic convoys climbing hills. Power output of horses is currently averaged where as in real life they would be producing more when climbing hills and less when on flats. For horses to properly be simulated on will have to simulate energy consumption and variable power output.

[Vladki]

Acarlotii: the same problems were observed with diesel trucks. They were unable to climb a hill if they had to stop under it (bus stop or congestion).

[jamespetts]

Thank you for your thoughts on this (and my apologies for the delay in replying: I have been very busy in the last week).

I do not know a great deal about the physics of horses in particular, although I did find a source once which gave some information on what loads that a horse could pull (although I do not think that it dealt with gradients). The physics code was written by someone other than me, so I have not had much involvement with the details.

It is certainly possible that the physics of horses would need to be treated differently (I know that the physics of steam locomotives are treated differently, as steam locomotives are constant force machines whereas most other types of locomotion are constant power machines), but I am afraid that I do not know the details.

I have not noticed issues with motive power other than horses, although I should be very grateful for any feedback from anyone else as to whether they have (even if they have not).

Edit: I had not spotted that Dr. Supergood had responded when I posted the above, as I had not noticed that the thread had moved into a separate page.

Dr. Supergood's post seems to give a good analysis of the nature of the problem: (1) that we do not simulate stamina (this would involve quite a lot of additional complexity I imagine); and (2) that a horsepower does not take into account the amount of power that a horse needs to move itself. I wonder whether we could try to find the necessary data to fix the second issue (which should, with the necessary information, be straightforward to fix) and see the extent to which, having done so, the first problem remains significant?

Does anyone have any data such as to enable us to get a reasonably accurate idea of the extent of the adjustment necessary to rectify the self-haulage issue?

[ACarlotti]

I too had missed most of DrSuperGood's post - I read it before it was edited, at which point it was (I think) much shorter.

DrSuperGood: I think there is an error in your calculation. You assume that one (half height) tile is 62.5m, but for the physics engine I believe that is incorrect. As we discussed earlier in the thread, the current code uses a gradient of 4% for a half-height (non-road) uphill slope, and 8% for a full height slope, which corresponds to an increase in height over 125m of 5m. This would suggest around 2.5 minutes for a horse to climb a hill, but this is less than is observed without the temporary reduction in resistance for road vehicles.

The stamina issue could perhaps be simulated by having some reserve of 'power' which can be drawn upon for short periods of time (so that for higher than nominal power output can be attained for a period of time). This would also be relevant for steam locomotives, which can increase their power output for a short period by running down the boiler pressure. In both cases, this would help to deal with the effect of hills.

A horse will have some sort of resistance to motion; I do not know if this force can be approximated as a rolling resistance (i.e. independent of non-zero speed, and proportional to weight).

I think the primary thing to do now is to check that the current values allow for the horse pulling its own weight as well as that of any wagons, although if we can find out any more about the physics, that would be helpful.


As for the current code, I have been gradually working on understanding it. The algorithmic parts shouldn't be too hard for me to check; so far I've been msotly working out how the class hierarchy and inheritance work. It seems to be that there was an intention (back in 2009) of making some further changes to the division of code between classes; as it is, I think it is unnecessarily complicated, so I might see if it is possible to simplify the structure without hindering functionality or efficiency. If you know of any information regarding the class hierarchy (of convoy_t and its descendents) beyond the code and its comments, paricularly regarding the long-term intent, then that could be helpful.

[DrSuperGood]

DrSuperGood: I think there is an error in your calculation. You assume that one (half height) tile is 62.5m, but for the physics engine I believe that is incorrect. As we discussed earlier in the thread, the current code uses a gradient of 4% for a half-height (non-road) uphill slope, and 8% for a full height slope, which corresponds to an increase in height over 125m of 5m. This would suggest around 2.5 minutes for a horse to climb a hill, but this is less than is observed without the temporary reduction in resistance for road vehicles.

This is not made clear in game. In any case that is why I used a value of averaging 1 half height over 1km as I was aware there was some averaging going on, just not to what extent.

Stamina would be a mechanic that goes well with implementing fuel economy. A simple powered vehicle could be given 2 power values and an energy capacity value.

• The sustained power output, this is how fast stamina energy is recharged.
• Maximum power output, this is the maximum amount of power that can be drawn from stamina energy, trying to maintain speed.
• Stamina energy, this is the amount of energy stored by a convoy for deployment in short bursts.

Fuel energy is then the amount of sustained power used to recharge stamina. There would be a fuel multiplier, efficiency, and the cost per kwh of fuel is standardised based on fuel type and could be made to vary with respect to time.

Of course stamina model in real life is a lot more complex. However this might just be enough to have powerful horses for hill climbing in a realistic way.

[jamespetts]

Thank you both for your thoughts: this is most useful. The idea of a stamina mechanic is most interesting, although quite how it might be coded is another matter, as I struggle to understand the physics code myself as it is. If A. Carlotti is able to code this, that would be extremely helpful.

I should note that Dr. Supergood's suggestions for using efficiency, fuel burned per unit of time and cost per kwh of fuel (or rather, cost per unit of weight and kwh per unit of weight of fuel) are consistent with what I hope to do to implement more realistic running costs, and data to support these values has existed for some years in the physics balancing spreadsheet for steam railway locomotives (which so far is used only to produce power values from data about the locomotive, but is also intended to be able to be used to specify running cost and range).