Overhauled physics model

[Bernd Gabriel]

The existing method calculating convoy speeds (called "calc_acceleration") had left the path of pure physics far behind.

Some examples:
1) If the calculated new current speed exceeded the set speed, a mathematical operation reduced the new current speed. Although the convoy's mass could never changed it's movement that fast.
2) James wanted to give steam trains a more realistic acceleration and therefore added some computationally intensive code.
3) In calc_acceleration there is a comment: "...if delta_t is too large the calculation may get weird results...", which might have been meant to be related to integer overflows, but even without such an overflow the result will get weird: The used formular is reasonable only for small delta_t (= time passed since previous calculation).

James found a very illuminating page about the differences between steam and diesel locomotives at http://www.railway-technical.com/st-vs-de.shtml.
My wish to get back to the physical path arose from this page. If there are different physical processes, calc_acceleration should represent them.

The new calc_acceleration is a clearly arranged one, which only models the convoy physics and the driver controlling the acceleration force.
It works with the existing parameters such as power and friction factors, etc. and could even work in simutrans standard.

To view the acceleration results I added a new graph to the convoy info. It shows the convoy speed starting from 0 km/h in steps of 15 seconds according to the current weight, friction given by slope and curve of the vehicles, etc.

The attachment shows some acceleration curves calculated by the new calc_acceleration.
The complete screenshot (Size: 712KB) can be found at http://www.fast-function-factory.de/simutrans/simscr39.png.

If there are no concerns, both model and graph might become part of simutrans experimental 7.0.

[knightly]

Bernd,

Thank you very much for your hard work.

It works with the existing parameters such as power and friction factors, etc. and could even work in simutrans standard.

Do you mind to post a patch against the latest nightly of Simutrans Standard, so that Prissi and others can try out and take a look? Your work looks nice, and it will benefit more players if it can be incorporated in ST Standard's trunk.  Many thanks in advance!

Knightly

[prissi]

Well, I plaed a lot around and found quadratic functions (which are ultimatively needed) to give only unsatisfactry results for the feeling. As I am teaching physics at TU Berlin, I am well aware that the modell is not physical, but it gives visual nice results and can lead to reduced max speeds with overloaded engines (which is otherwise very hard to achieve, epsecially if this is not only good for rails. Not to mention that fliud dynamics and air have completely different regimes ... )

But I would like to see it. (Also the old formula was without floats, as floats were better avoided on old machines. That restriction has gone since then I thnik.)

[Dwachs]

3) In calc_acceleration there is a comment: "...if delta_t is too large the calculation may get weird results...", which might have been meant to be related to integer overflows, but even without such an overflow the result will get weird: The used formular is reasonable only for small delta_t (= time passed since previous calculation).

Imho, this quote is more related to the fact that one is integrating a differential equation here. Using too large time steps delta_t then may lead to large errors (difference between computed and modelled movement).

[jamespetts]

Bernd Gabriel,

thank you very much indeed for your work on this. It is very much appreciated. Sorry that I have not replied sooner: I have been somewhat busy of late, and the Simutrans time that I have had has been spent trying hard to track down weird bugs in the new industry closing/opening/upgrading model for 7.0 (on which I am still working).

To respond to Prissi's point about the appearance: since physics is intimately linked with economics, it is more important to have a (more or less) accurate physics model than to have something that looks visually appealing. Can I ask - does this new physics model work with Simutrans-Experimental's scaling system, such that vehicles accelerate in a realistic distance according to the scale set in simuconf.tab?

Also, in 7.0, I added a parameter "tractive_effort" to the vehicles' .dat files - this was in anticipation of future physics developments. Is this something that is ever likely to be utilised under your model, or should it be removed before 7.0 is released?

Thank you very much for your hard work on this,

James.

[Bernd Gabriel]

@Knightly:
I will prepare 2 patches for simutrans standard: 1st patch for the graph and 2nd patch for the model.

@Prissi:
The quadratic function is still there and the reduced speed for higher load, too. These basic parts do model real physics. I think, that the (yet unchanged) load depended top speed calculation could bear some fine tuning.

Could you find some acceleration equations for ships and aircrafts for simutrans? BTW: Is a maglev an aircraft?

@James:
a) Please keep the tractive_effort. I'm still thinking about a way to use the gear as gear instead of a multiplier of power. In the new model the gear is used to calculate the start-up force of non steam-loco engines and ignores the gear for higher speeds. When the gear plays its correct role, the tractive_effort becomes the power multiplier. Some useful vehicle params would be: "drag coefficient * reference area", "roll resistance", maybe "start-up force" instead of gear.

b) In the first instance the new model is a 100% replacement of the existing calc_acceleration. The mapping to simutrans distances is a different chapter. At the moment an average train of about maximum weight, that still allows the trains maximum speed, accelerates to top speed in about its own length.

[jamespetts]

Bernd,

thank you for your reply, but I am confused by what you write about tractive effort: tractive effort is torque - how could it be a power multiplier? It is probably best to leave gear as a power multiplier, and use tractive_effort in a realistic sense, otherwise things could get very, very confusing.

[wlindley]

But -- Does the graph actually show Velocity (i.e., Speed; equals change in location, delta-x, if x is location), or Acceleration (equals change in *Speed*, delta-delta-x)?

When the train is at full speed, Acceleration should be zero.  If train is slowing, Acceleration should be negative.

(The change in acceleration is called "Jerk" and is delta-delta-delta-x -- this is what you feel on an electric train that starts suddenly.  It could also describe railway officials who tell you photography is forbidden!)

[prissi]

It is very difficult to comment on anything without seeing a line of code or an equation.

The current model uses a constant accelleration with a quadratic drag. This mimics the model of a steam engine (or most other engines) with a constant force (aka "tractive effort" which is in kN) and air drag only. It was implemented in such way that the engines present in the pak64 at that time behave reasonable (as you can see from the comments).

The errors made:
For higher speeds this force is reduced to something limited by the power of the vehicle and acceleration is no longer linear. For small speed the drag is not quadratic but linear.
(Neglecting static friction for starting.)

The exact turnover depends strongly one the vehicle, its shape and the friction with the ground. Airplanes are mostly constant force (since the engine thrust is usually given in kN) with quadratic drag, so they should behave more or less like the current formula. Ships are more difficult, as the have different regimes depending on speed. But in general quadratic drag is not a bad approximation (since the index of drag is not constant for ships), but acceleration should be constant power. For trains the friction is mostly proportional to speed (and incline) and acceleration is first constant force and then constant power. (Here the current formula is quite bad despite most visially pleasing, but any linear drag gave pretty bad results and never results in lower speeds of overloaded engines, since acceleration is also linear there.)

Thus the current formula with constant force could be extended by a constant power regime which kicks in at a certain turnover point (which is unfourtunately quite vehicle dependent) and needed to be determined by some thrust (or tractive effort or how due you call it). One could calculate acceleration via TE or power and the weaker wins.

[Spike]

I think here we face the question again - do we want to model reality, or just create a game?

I remember trains accelerated faster and reached top speed always in old Simutrans versions. I'm sure I could get that again if I want, with giving them a higher gear value. Something like that is on my plans for pakHajo.evolution if I ever get back to that.

But other than this personal preference of mine, it seems Prissi's approach works "good enough", and therefore I don't bother how realistic it is.

This doesn't mean that I think the new formula is bad. I just think, we don't really need to bother about those formulas since we have something that works good enough.

Maybe it'd be a good idea if Simutrans experimental picks this up, since it's geared much more towards a deeper simulation of such details than Simutrans standard is?

Just my 2 cent.

[jamespetts]

Hajo,

this is for Simutrans-Experimental The reason for having more accurate physics is that physics are intimately linked to economics. The idea is that good vehicle choice for particular situations becomes important, and that that choice can be made on realistic grounds.

[Spike]

*looks around*

Oh, I was confused about which part of the forum this is 

In that case, it's quite alright to explore new formulas. I keep my message above, though, since if I ever get back to Simutrans, I'll head for a simpler Simutrans version, with only the most essential features, and very simple rules. But this is unlikely to happen within the next few years - if ever. So don't someone worry about it.

Edit: felt compelled to say, that I appreciate the work on Simutrans Experimental. It's not my cup of tea, but I see it as a very interesting and valuable addition to the Simutrans project. Please keep up the good work, and don't get irritated if I say my own wishes head into a different direction. Variety is good, and currently it seems Experimental spawns a lot of new ideas, which is even better!

[prissi]

The main problem with real formula is, that in simutrans distances (and times) do not (and cannot) match reality. Trams taking a days for the five stations to central station would never been something anybody would ride in reality ... Same goes for trains accelerate and brake within on or two tiles as in reality. Or, if a tile is like 100m (following the vehicle sizes), then the largest maps are something like 300km and nothing to simulate europe or the world.

[KrazyJay]

Matching reality is not always what's good for a game. Nobody would play games where it takes 12 hours in real life to see a plane fly 10,000km. It's always been solved by using multiple scales. When it comes to differences in traction and acceleration between steam engines and other engines, I think Simutrans Exp. is a great platform to give it a try!

[prissi]

Incidentally the formula used in standard exactly matches stem engines ... but they are nevertheless handicapped anyway by their low power, so an additional handicap would be rather annoying to most players.

[jamespetts]

The main problem with real formula is, that in simutrans distances (and times) do not (and cannot) match reality. Trams taking a days for the five stations to central station would never been something anybody would ride in reality ... Same goes for trains accelerate and brake within on or two tiles as in reality. Or, if a tile is like 100m (following the vehicle sizes), then the largest maps are something like 300km and nothing to simulate europe or the world.

Simutrans-Experimental uses by default a scale of 250m/tile to obtain a good balance. There are, of necessity, different scales (in distance: one for graphics, one for measured journey distances/times; and in time, one for the journey times and one for the passage of years). The real difficulty with a model that is distant from reality is that the choices that make for a successful outcome in the game become more different from those choices that would make for a successful outcome in reality the further from reality that the game model is. For me, at least, the game is more fun the more closely that the choices that a player makes (1) ends up producing by itself a realistic transport network; and (2) provide success in the game to the same extent as in reality. That is what makes a simulation game fun - for me, at least. That is the aim of Simutrans-Experimental.

[jamespetts]

I have just to-day had time to test this. I have not looked at the acceleration graph in detail (although found it a little confusing at first glance - what does the horizontal axis represent, exactly? For other graphs, it represents months), but the acceleration for steam trains seems considerably too fast. In the demo.sve of Pak128.Britain-Ex, the express train was able to accelerate to full speed in a really very short time indeed - about half that required for the current physics engine in Simutrans-Experimental (tweaked from Simutrans-Standard). Was this intended? If so, it is not correct: it would take a steam train of that weight considerably longer (assuming 250m/tile) to accelerate to that speed in reality.

[Bernd Gabriel]

I noticed, that the new model makes engines stronger. With the old model I mostly used Tigress 1 to pull my 15 cars/1800 tons oil trains at 120 km/h. 2 "DB BR185" pull 9 cars only :(.

Until now I found only 1 acceleration info about a real steam loco (AFAIR it was a simple passenger loco built around 1900), which said, that this loco reached its end speed (about 50-60 km/h?) within 90 seconds and about 1.3 km. In the 250m/tile simuworld after about 5 to 6 tiles. This complied with the results of the new model for comparable engines.

I didn't follow any game specific strategy. I just put together the physics without compromises and watched the results.
The model may lack a vehicle specific drag coefficient. A steamer's one is about 2 times greater than a TGV/ICE's ones.

The new model needs to adjust some gear values in the 19th Century pak. I might have been a bit too generous there due to the humble power yield of the old model. My ambition is to adjust the engines to fit the originals' capabilities (preferredly with gear 1.0). I found a book with a lot of information about how many tons at which inclination angle the (german) engines were build to pull.

This leads me to the next idea: At the bottom of the depot frame, where the details of the vehicle under the mouse is shown, we could show a little graph, that shows the maximum speed (y-axis) at certain convoy weights (x-axis) on flat way. A second curve in the same graph shows the (lesser) max speed at slopes.

[Spike]

I noticed, that the new model makes engines stronger. With the old model I mostly used Tigress 1 to pull my 15 cars/1800 tons oil trains at 120 km/h. 2 "DB BR185" pull 9 cars only :(.

This is utterly wrong. Really. I know a lot changed while I was away from Simutrans, but I can only express serious protest here (against the old physics model)!  (I don't play pak64, so I'm not really aware of all the problems there, only respond to the facts told in Bernd Gabriels message).

The Tigress series was meant to be superfast futuristic rail engines, that were invented to counter the uprising competition of maglev technology. In my times the base Tigress was 450 km/h I think, and there was no limit for train length that would have hindered it down to 120km/h (OTOH it was not projected as a freight engine ... I had painted matching passenger and mail cars, but I might have allowed to connect other cars for the fun of it, I just don't remember).

It is a shame to cripple a engine of mine like that! I protest and expect rectification in one of the next pak64 releases. I can dig out the old and original data, but I'm certain that the Tigress was above 400 km/h top speed and I want that back!

I know the new model makes engines go below top speed with long trains but I don't care. Make it so that this engine is _really_ powerful. Maybe put introduction date to 2050, but the TGV recently reached 574km/h top speed, so it's not that futuristic actually.

[skreyola]

The Tigress series was meant to be superfast futuristic rail engines, that were invented to counter the uprising competition of maglev technology. In my times the base tigress was 450 km/h I think, and there was no limit for train length that would have hindered it down to 120km/h

It's not the weight. One oil tanker car limits it to 120k/h because that's the car's max safe speed.

[Spike]

Ok. At least something. I was shocked for a moment.

Edit: Sorry for the drastic words above. I'm somewhat itchy sometimes about certain attributes of my former work, and may overreact if I think I need to defend those.

Edit 2: If the Tigress is still that mighty, no need to take action in response to my message. I still keep it, to show that I had certain ideas with some of my designs, and want those ideas preserved.

[skreyola]

I have also, as a player, had that "What?" reaction to the top speed of some goods trains, forgetting that the cars have a max speed, too.

[Bernd Gabriel]

Ok. At least something. I was shocked for a moment.

I didn't want to shock anybody ...

I love Tigress and Pantheress and they still run 338-448 km/h with the appropriate passenger and post cars!
I prefer them over any other engine, because they are the only ones, which can to pull 8-tile trains in single traction.

[jamespetts]

Bernd Gabriel's new physics model is now incorporated into Simutrans-Experimental 7.1: see here more information about that release.

Bernd and I would be very grateful for any feedback on how this new physics model works: there are some things that need fine tuning (at present, the automatic calculation of power from tractive effort in the case of steam locomotives produces figures for power that are too high, so power should still manually be added for steam locomotives).

An overview of what this physics model changes over the physics model in Simutrans-Standard follows:

• There is now a "tractive_effort" parameter as well as a "power" parameter in .dat files. Only one needs to be specified; the other can be left blank and will be calculated automatically. The automatic calculation will be different for steam locomotives than others.
• There is now an "acceleration" graph in the convoy window
• Hill drag is cumulative, meaning that consecutive hill tiles act as if they were a steeper hill, encouraging players to build gentler slopes
• The physics model is generally based more closely on real-world physics rather than a compromise specific for the game
• Acceleration is based on Simutrans-Experimental's variable scale, so that, with a scale of 250 meters per tile, vehicles will take twice as many tiles to accelerate to any given speed than with a scale of 500 meters per tile
• There is a specific value for air resistance, allowing for future changes in code easily to add streamlining as a parameter in .dat files which affects physics (although this has not been implemented yet

Any feedback on the new physics model should be added to this thread. I should be very grateful for people to look into this, as getting physics right is important for economics and game balance.

[Colin]

Edit: Sorry for the drastic words above. I'm somewhat itchy sometimes about certain attributes of my former work, and may overreact if I think I need to defend those.

Edit 2: If the Tigress is still that mighty, no need to take action in response to my message. I still keep it, to show that I had certain ideas with some of my designs, and want those ideas preserved.

Dont worry Hajo, If you ever look at any of my sve's you will see that I have a love affair with the Tigress. All my major cities are connected with multiple super fast Tigress engines, each pulling 12 passenger carriages.

[jamespetts]

One other thing to consider with physics for steam locomotives is this: unlike diesel and electric locomotives, where their maximum possible (rather than maximum permitted) speed is determined by the effective power to total resistance at any given speed ratio, steam locomotives have an additional handicap at higher speeds: they actually become less efficient as the speed increases. Very briefly, this is because, as the piston travels faster in the cylinder, there is less time for fresh steam to enter the cylinder, and, more crucially, less time for exhaust steam to leave the cylinder, resulting in back pressure in the piston that increases with speed.

Perhaps a simple way to model this would be to reduce the power of steam locomotives by X amount for every Y amount of speed at which they are travelling above a certain threshold of speed, perhaps 90% of their listed maximum speed. This is more or less what I had done in my original physics modifications.

[Bernd Gabriel]

That's the cause, why the steamers do not continue to produce the constant force at higher speeds. They reached their maximum power production.
And that's why faster steamers have larger wheels to reduce the piston frequency.

[jamespetts]

I thought that the cause of steam locomotives not producing constant force at higher speeds was the limit in the amount of power produced by the boiler, and that the inefficiencies in steam exhausting at higher speeds is an additional factor which reduces the effective power at higher speeds. Is that not correct?

[Bernd Gabriel]

A steam engine has an efficieny factor of about 8%. Assuming the given simutrans power figures were power input figures and not power production figures most steamers won't move at all. Thus I see no reason to reduce the power no matter if it is limited by steam shortage or piston pressure matters.

[jamespetts]

Ahh, perhaps I have not been as clear as I ought to have been: apologies. The idea is not to reduce the power generally, but only at higher speeds, because a steam locomotive, unlike a diesel or electric locomotive, is less efficient at higher speeds, and thus produces less output power compared to when it is travelling more slowly. This is in addition to, not part of, the dynamics of switching from constant force to constant power at a certain (lower) speed. It is only when steam locomotives travel relatively close to their top speeds that this effect is seen.

[Bernd Gabriel]

I understood, that you want to reduce the power by 10% for the highest 10% of steamers top speed.

But can we see the effect of 10% and does this tiny effect justify the additional maths?

What happens is that steamers accelerate a little (not even 10% compared to a generally reduced power) faster and at the end of the acceleration curve, where it is already flattish, the train needs yet longer to reach its top speed.

Each time when we calculate a maximum speed resp. maximum load preview, we have to check, whether this is a steamer and we have reached the threshold speed and eventually reduce the power and calculate again and in the end, you won't see a noticealbe difference to a generally reduced power.

[jamespetts]

Ahh - so the issue is whether the difference in performance would be significant? Could that perhaps be tested?

[mjhn]

The problem I  have seen with the new physics model is that while long trains behave sensibly (an 8 car intercity 125 can reach 199km/h), some of the shorter convoys have major problems (a class 153 is restricted to only 83km/h, and some of the modern road vehicles can hardly move when fully loaded). On the other hand the same power to weight ratio with greater totals has no problems, with three class 153s coupled together reaching 120km/h. This seems unlikely behaviour, and could be due to an excessive air resistance factor.

[Bernd Gabriel]

mjhn,

the disproportionately lower power (resp. force) of weaker engines was caused (among others) by very little force values sometimes rounded down to yet smaller values.
This should be fixed with experimental release 7.2.

Additionally you will get a better preview of max/min speed @ min/max weight (see pictures).

As the pictures show, there is still a penalty for weaker engines. I've checked it and air resistance actually is the cause for it.

[Spike]

I want to point out that with higher RPM diesel engines become less efficient, too, but maybe less than the steam engines.

Some types of electrical motors also become less efficient with higher RPM, but this depends much on the construction and motor control, so it might be irrelevant for trains.

For diesel and steam engines I was under the impression that it's less the power output that limits the top speed, but gear factors and max. useable rpm of the motor.

So I'm confused why people always try to calculate top speed based on power.