Measuring work and fuel consumption

[jamespetts]

In the process of researching improvements to pakset data for steam locomotive physics (the previous extrapolations were incorrect, and resulted in power figures that were in some cases (especially freight and suburban locomotives) considerably too low), I have found data that suggests that there are orders of magnitude fluctuation in coal consumed per mile (as it was measured then; per km for Simutrans purposes) between slow freight trains and express passenger trains (figures for stopping passenger trains are harder to come by): there are various sources which I have not time to quote now, but a medium sized tank locomotive hauling a train of coal wagons up a hill could consume 95lb of coal per mile, whereas large express passenger locomotive hauling a 12 or so carriage passenger train may take less than 45lb of coal per mile.

This means that it is not possible to have a realistic balance by doing what I had previously planned to do, which is to use the existing per kilometre maintenance cost ("running cost") as a measure of fuel consumption. That will have to be reserved for the cost of general maintenance ("repairs" in the older literature), and a new system of charging entirely introduced for fuel consumption in addition to the fixed monthly cost (which was and is intended to reflect only the staffing cost of the vehicle: e.g, the cost of the driver's wages).

What will be needed is a third type of cost measured neither purely by distance nor purely by time, but by unit of work done. This will need, I think, to be in the form of fuel consumption per game month (which can readily be converted to consumption per hour, which figures are readily available or able to be calculated for multiple types of transport), which can then be adjusted by the amount of work done. It would be adjusted between an idle fuel consumption (which could be as low as zero for, e.g., an electric vehicle)  and a maximum fuel consumption figure, both specified in the .dat file, depending on the proportion of work that the vehicle has performed in any given unit of time compared to the maximum amount of work that could have been performed in that unit of time by the vehicle in question based on its characteristics (i.e., power rating).

The hard part will be measuring the amount of work done and storing this information in a way that can easily be utilised and does not consume excessive memory or bandwidth (as well as understanding the basic mathematics of how to calculate work from a convoy's weight, speed, current resistance and such other data as may be available). Also a challenge will be presenting this information to users in an easily digestible way. Adding to the complexity is the fact that the current physics engine in Experimental was written by neither I nor any of the Standard developers.

I should be very grateful for any suggestions in respect of these matters, as this will be a challenging but important thing to implement if we are ever to have a sensible and realistic balance.

[DrSuperGood]

Ultimately fuel consumption comes down to work done. Every tick a convoy moves it in theory does a certain amount of work. This is basic highschool physics.

The problem is the fuel economy, the conversion from work done into actual fuel and hence cost.

For example a car engine is most efficient around a certain RPM outputting a certain talk etc. Outside this range (eg an accelerating car) the efficiency decreases. To compensate cars use gear boxes which allow the engine to perform in its more efficient operating conditions while at slower or higher speeds. However the efficiency will still vary heavily, and it is the efficiency that converts work done into fuel used. This does not just apply to car engines, but also to steam engines, diesel engines and electric engines.

So where does work done go? The most obvious is acceleration, as to move an object needs to be given kinetic energy. With movement you have air resistance, and this is especially important with high speed trains and cars as it can account to significant losses of energy. Then you have friction/rolling resistance or whatever you want to call it which also loses energy. Since tracks are not flat you have gravity, which is mgh potential energy based on the change of height, gravity and mass. When a train is up to speed on a flat section of track the work done is simply the losses. If it goes up hill then it does more power per unit time in order to compensate for mgh conversion. When it goes down hill the opposite applies to the point the train may need to absorb work (break) to avoid over speeding. Obviously when a train is stopping it does not need to do any work, or it even does negative work if it features energy reclamation technology. If one gets all these calculations correct, and factor in efficiency you will have a work done which translates to a fuel volume and hence cost.

A big and unrealistic problem then is work done economy. There is such a term as driving economically and I can assure you what happens in Simutrans is anything but economical. What trains currently do in Simutrans is similar to what cars do in an overcrowded city. They accelerate to the maximum speed they can, and then break to stop when they have to. This constant acceleration (a lot of work done) and breaking (wasting all the work done) results in a lot more work being done. In real life trains avoid this, often slowing down instead of out right stopping and schedules are carefully engineered such that trains seldom needs to stop when moving at speed which reduces the total amount of work done. Currently if you had a slow goods train in front of a fast express passenger train then the express passenger train would constantly output full power to reach maximum speed until it encounters the reserved block of the goods train and then stops, repeating this every 1-2 signal blocks. With realistic energy economy this is very uneconomical and the express train would run up huge fuel costs because of its stupid behaviour. In real life the express train would slow to approximately the same speed as the goods train so that they pass the blocks at around the same rate so there is no need to stop. This runs up very low fuel costs since the train only has the low speed drag, rolling resistance and height changes to power.

[jamespetts]

Thank you for those reflections - that is interesting. I wonder whether a slightly simplified system might suffice: have three monthly rates of fuel consumption: (1) idle; (2) coasting; and (3) accelerating. I believe that the physics engine already distinguishes between accelerating and coasting for the purposes of determining whether to emit smoke graphics from deisel vehicles. The idle consumption could be used when stationary or braking.

To modify the work done economy issue, it might be worthwhile for players to be able to specify a maximum speed for each point to point journey in the schedule; I am planning on adding additional features to the schedule in any event.

[DrSuperGood]

To modify the work done economy issue, it might be worthwhile for players to be able to specify a maximum speed for each point to point journey in the schedule; I am planning on adding additional features to the schedule in any event.

Although this helps resolve the problem, it becomes yet another feature the player will have to spend countless hours dealing with when dealing with a large rail network.

It might be better in the end to simply cheat and give players free acceleration work. Instead the average amount of work done accelerating per km can be tagged onto the rolling energy costs. This will mean the running results will be approximately realistic even though the actual work done is not due to bad vehicle economy.

[Sarlock]

That would be simpler, and preferable, to a system that is mathematically complex and difficult to understand and convey to the player.  The player needs to be able to quickly calculate what the cost of each unit will be on a per km basis.  If they have to start to do complex calculations based on resistances, acceleration, etc, they will have a difficult time choosing which locomotive is the most effective choice for a given task.  All of the various impacts on operating cost can be approximated by using a base per km cost.  It isn't perfect, but it's close and for purposes of the game, sufficient.

I would add significantly more cost to the train cars and less to the locomotive, in order to better reflect the impact of weight on overall operating costs.  Running the locomotive by itself is far, far cheaper than when pulling 50 fully loaded cars.

Improving the quality of the simulation is great, adding more complexity for the player, less so.

[jamespetts]

Trying to average out the performance simply won't work because of the orders of magnitude difference between slow freight haulage and fast passenger haulage in fuel consumed per unit of distance. Trying to fix this by putting the cost onto the vehicles causes two fundamental and irresolvable problems: (1) there is no way of accounting for the different efficiency or power of the locomotives when doing this, which itself can entail orders of magnitude differences, so this will in many cases be orders of magnitude out; and (2) this would breach the fundamental balancing rule of Experimental that costs and revenues assigned to particular things should reflect the real life cost of those things. Breaching the second rule would make balancing impossibly difficult.

It should not be in principle too difficult to select railway locomotives or other vehicles with three fuel consumption rates (accelerating, coasting and idle), especially if there were a fixed ratio between each of them applicable to all vehicles of a certain traction type. That would then not in principle be materially more complex for a player than deciding where there is just the one figure: one would just compare the fuel cost with the power output, tractive effort, top speed, capital cost, maintenance cost and staffing cost (and, in the case of carrying vehicles, capacity, loading time, and, where applicable, comfort) in the usual way.

Players should not in any event have to get a calculator out to work out whether any given service will make a profit or not, as this sort of precision in prediction was never possible in real life. Part of the point of additional realistic complexities in Experimental is to force players to use realistic heuristic methods of estimating what the best solution is, rather than just calculating it mathematically as is possible (but much, much more tedious) in a simpler simulation. The balance is intended in most cases to be lenient enough to the player so that the player can make modest errors, choose moderately sub-optimal solutions, and still stay afloat, albeit be able to expand less quickly than a player making optimal decisions. Indeed, such a lenient balance is realistic in most cases, especially in the case of 19th and early 20th century railways, where many sub-optimal decisions were made by companies that remained profitable (but also in, for example, 20th century road transport, were sub-optimal decisions are easy to reverse quickly).

[Ves]

May is suggest that you add a description field to each vehicle. If you one could add descriptions for the player to read before buying a vehicle, the pakset author could write stuff like "this locomotive is good for hilly areas" or "this locomotive is very cheap but not suitable for shorter trips" etc.
Although the railways in the past did not have precise diagrams, some sort of prediction would they have, based on the experience.

Edit: to be clear, I meant that a nice way to tell the player what all the costs (three rates of maintenance, staff costs etc) would mean to your gameplay, a description field could conclude that nice!
Edit 2: Offtopic, such a description field could be usefull in many other ways as well: Conclusions of data, Historical comments, fun facts, descriptions of other details etc...

[Vladki]

I remember similar discussion in standard.  Something similar, yet much simpler (only power, weight and friction used for calculation), was proposed and dismissed as too complex to show to the player. Even en real life, when you buy a car you get fuel consumption in litres per 100km or miles per gallon. On the other hand, I would really like to see that a train coming downhill (or empty) has lower running cost than train going uphill (or full).

I really like the idea of showing a free comment to the player: e.g. this is a heavy freight engine (>8 waggons), this is a light passenger engine (<4 coaches), this EMU is usually run in a set of 2 powered and 3-4 unpowered coaches, etc.

To keep the user info as clear as possible, I would suggest using some average cost/kWh. This would tell the user the efficiency of the engine. Further decision would be based on top speed, power and traction force to decide which engine is more suitable. E.g. for an express train, the less efficient but fast and powerful engine is worth the money because it will be back in speed bonus, while for slow commuter train the efficiency will be the primary concern.

But anyway, I think it will be much easier to find cost/km than cost/kWh. I am not sure about the exact formula, as I don't really know what information is available. Dat file has: air_resistance, rolling_resistance, tractive_effort, power, gear, weight. What do we have in-game? current weight (including cargo), current speed, friction (uphill/downhill/curve), current power output? current tractive/braking force? acceleration?

[zook2]

1. Constant stop-and-go ruins fuel efficiency. But could a very quick & dirty solution perhaps involve using the monthly speed average which is already being calculated? For example, an engine rated as having a max. speed of 120 km/h (when pulling x tons, which is also already calculated) that gets an average speed of 80 km/h is probably being run quite efficiently, even though nothing is known about acceleration/deceleration cycles. The same engine getting only an av. of 20 km/h is either carrying iron ore across the Alps or constantly stopping somewhere.

2. I tried to find data on historical UK coal prices, but came up a little short. For what it's worth, here's some price data based on a real price index:
http://www.resilience.org/stories/2011-08-15/jevons-coal-question-why-uk-coal-peak-wasnt-bad-expected
That is probably important in this regard because relative costs of labour and coal changed a lot in 100 years of the steam train.

3. What's the thermal efficiency of a train's steam engine? I've read estimates of 5-10%, which means most of your coal's energy goes through the stack anyway - without contributing to the train's movement. In that case you'd need thermal efficiency ratings for a particular type, wouldn't you?

[jamespetts]

Thank you all for your suggestions. There are two distinct strands to this discussion: (1) the techincal question of how to calculate work done in order to calculate fuel consumption; and (2) a set of related gameplay discussions.

As to (1), I should be very interested in any further thoughts on this, as this has only been touched on briefly so far. I am wondering whether some calculation performed in step(), calculating current output, multiplying that by delta_t and storing it in a uint32 value in vehikel_t might be feasible? The three states idea above will probably not, on reflection, work well, as there is a difference between hauling a heavy load up a hill and accelerating a light load gently on the flat.

As to the other matters, a clear representation of the various costs might be to specify simply a minimum and maximum monthly fuel cost (based on idling and maximum work output respectively), and the player should be able to get the idea that, the harder that the vehicle has to work, the closer to the maximum that the cost is likely to be. A player who is not trying to calculate precisely in advance what it will cost to run a convoy (which should not generally be feasible in any event: see above on calculating) should need no more than this information heuristically to compare different vehicles for their suitability for any given task.

Average speed is not going to work because no account is taken in that calculation of time spent stationary; also, no account is taken of the load varying over the month (which is likely to be more important when convoy recombination is added as a feature).

Historical coal price data will be needed in due course to balance the costs of various coal burning vehicles, and to vary those costs with time when the inflation feature is added. The same is true of oil prices for diesel, petrol and jet engined vehicles, and electricity for electrically powered vehicles. Even the historical cost of horse feed will need to be investigated. The link is interesting, and is likely to be useful in the future.

The thermal efficiency of steam locomotives I have been investigating carefully of late in connexion with this very issue (and also to rebalance steam locomotive power in the pakset, which was not extrapolated correctly before). It varied considerably, but was never more than 8% or so in the UK at least (earlier locomotives being much less efficient than later locomotives; extrapolation suggests that early locomotives from the 1830s or so had efficiencies of less than 3%, and very small steam locomotives, such as narrow gauge or tram engines, had efficiencies of 1% or even less in some cases (assuming a constant rate of coal consumed per firegrate area, based on measured performance, the Ffestiniog Railway's Double Fairlie engine manages only 1.8% thermal efficiency compared to the near contemporary GNR Stirling 8ft Single, which manages 4.33% - this is in the early 1870s).

The idea of a description is an interesting one, and has been discussed before. It does, however, have a number of problems - not necessarily insurmountable ones, but ones that make me think twice before implementing it and question whether it is a worthwhile use of time compared to other projects. Firstly there is the problem of where the text would actually fit in the already overcrowded depot window. Secondly, there is the time that it would take to provide a useful description for each and every vehicle (and there are lots of them, and they are growing). Thirdly, there is the point that, given that these are all real vehicles, players can in most cases just perform a Google search to find out about the real life versions, which should give information as to how they were used, which, if the simulation is realistic enough, should suffice. Fourthly, working out what information to give is really not straightforward at all. Many vehicles of all types are capable of being used for multiple different duties in different circumstances. An express railway locomotive from the 1860s may be hauling secondary passenger trains by the 1880s, branch line trains in the 1900s and be a station pilot in the 1920s (as was the sole surviving example of the Midland Railway's 156 class). A railway locomotive designed mainly for freight might find use on suburban passenger services in some instances, or on secondary passenger services on steeply graded track. A road motor coach intended for long distance comfortable travel might equally be used to link a city centre with a nearby airport 15km away. A small jet aircraft might make short hops between an island and the mainland or long journeys on a minor route. Giving short descriptions is likely to mislead the player, and giving long descriptions is likely to confuse the player. The player may find a use for the vehicle that the pakset author had not anticipated.

[DrSuperGood]

Trying to average out the performance simply won't work because of the orders of magnitude difference between slow freight haulage and fast passenger haulage in fuel consumed per unit of distance.

Which is why you use the rolling work done. You then ignore acceleration completely, equivalently giving you free acceleration. However it is not free, as you factor in realistic work done while accelerating to an inefficiency applied to rolling work done. This means it is free for your trains to decelerate and accelerate all the time, but instead you are paying slightly more for the work done per km travelled. This avoids the need for highly complex features like speed limits.

Part of the point of additional realistic complexities in Experimental is to force players to use realistic heuristic methods of estimating what the best solution is, rather than just calculating it mathematically as is possible (but much, much more tedious) in a simpler simulation.

In real life tens of thousands of hours are spent planning railways. Every day dozens of people work on railway schedules. There are no "heuristic methods" of building railways. There never were as even the very early ones would have had thousands of hours spent planning.

People play because it is a game, not because it is several times harder to play than real life as you are one person. If Experimental was truly realistic, one person would struggle to even manage a single line.

One would have to cancel such complexities out with autonomous managers, planners, and other features. Which might end up making a line is as simple as specifying two points, seeing if long term projected profit is positive and pressing confirm.

[jamespetts]

Which is why you use the rolling work done. You then ignore acceleration completely, equivalently giving you free acceleration. However it is not free, as you factor in realistic work done while accelerating to an inefficiency applied to rolling work done. This means it is free for your trains to decelerate and accelerate all the time, but instead you are paying slightly more for the work done per km travelled. This avoids the need for highly complex features like speed limits.

This looks like a promising idea. Have you any suggestions as to go about calculating this; would something in step() be the thing, do you think?

In real life tens of thousands of hours are spent planning railways. Every day dozens of people work on railway schedules. There are no "heuristic methods" of building railways. There never were as even the very early ones would have had thousands of hours spent planning.

People play because it is a game, not because it is several times harder to play than real life as you are one person. If Experimental was truly realistic, one person would struggle to even manage a single line.

One would have to cancel such complexities out with autonomous managers, planners, and other features. Which might end up making a line is as simple as specifying two points, seeing if long term projected profit is positive and pressing confirm.

I do not think that it is quite as simple (or complex) as that. Railway schedules are particularly complex and do require great mathematical effort; but we have already found a balanced simplified way of dealing with those. Similarly, keeping ledgers in the Victorian times required a room full of clerks whereas now it can easily be done with a home computer and within Simutrans.

What at least Victorian railway engineers were not readily able to do was work out other than very approximately how much coal that a given train service that has yet to be introduced would actually end up using. The exact revenue and cost could not be predicted, but had to be estimated. Often, the estimates were wrong, and some lines were built that transpired to be only marginally profitable or even unprofitable. The same was true of canals. Players in Simutrans cannot expect to be able to count the tiles, look at the cost per tile per vehicle, work out a factory's production, look at the revenue per unit transported and get an exact figure as to profitability for a service that has not been built yet. Attempting to do so would make the game unremittingly tedious, and yet exactly this is possible (and confers a real advantage) when the simulation is simple.

[zook2]

There's a simulation tool for OpenRails that calculates tractive effort from loco specifications, if anybody should be so inclined...
http://openrails.org/files/OR_Steam%20Model_03_02_2014.pdf
and loco data:
http://orion.math.iastate.edu/jdhsmith/term/slindex.htm

Then there's some apparently real-life data on actual practices of running locomotives:
http://www.catskillarchive.com/rrextra/chapt25.Html
It seems that 33% higher coal use due to sloppy throttle-settings were not uncommon.

[jamespetts]

Thank you for those - I am actually already aware of the locomotive data and tractive effort calculators (I use a different one, but they do the same thing): see here for more details. As to the energy in coal, one must be careful not to use American sources, as they seem to have much poorer coal there than existed in the UK during the steam age (about a third less energy per unit of weight than the best Welsh coal), but I have already undertaken some detailed calculations on the energy in coal and the thermal efficiency of locomotives relative to their power output. Those calculations will go in the steam physics calculations spreadsheet on Github when I have finished the rebalancing.

Edit: One query about Dr. Supergood's suggestion of measuring work done, incidentally: does anyone have any idea as to a reliable way of calibrating this? The base figures that I have are the firegrate areas of various steam locomotives, and a range of figures as to how much coal that typical steam locomotives burnt per square foot of firegrate per hour, as well as information as to the calorific value of certain types of coal (and varying amounts of information as to what locomotives used what types of coal). I can thus work out a per hour (and therefore per Simutrans month) rate of fuel usage assuming that the locomotive is working hard during the whole time. Likewise for aircraft, one can often find the fuel consumption by time figure, which I assume is for cruising. Is there a sensible and consistent way to convert these per unit of time measurements into per unit of work done measurements without having to make arbitrary stipulations about average speed that it is the intention of this proposed system (i.e., by not making it per unit of distance) to avoid?

[zook2]

My understanding of the physics of combustion engines is rather limited, but since there aren't any takers yet, I'll give it a try...

You start with measured real-life fuel use of a loco type, therefore you know how much energy was fed into the engine per hour. And you want to calculate from that how much mechanical work was done.

But fuel use is dependent upon:
- actual operating practices (sloppy throttle setting, as in the link I posted above). This factor is unknown, but if the above link is correct, it could be as much as a third. You do not know how much it changed over the decades, due to better understanding of the technology, driver training etc.
- the route on which these engines ran. A route with many gradients requires the engine to do more work, thereby using more fuel. I guess this factor is also unknown and assuming that the locomotive is working hard during the whole time is an arbitrary stipulation by itself.
- rolling resistance is dependent on weight. You'd need to know how much weight these engines actually pulled when the fuel use was measured. Also probably unknown.
- actual average speed when fuel use was measured, as well as start-and-stop cycles.
- even the weather can change the thermal efficiency of an engine because in cold weather the engine radiates off more loss heat.

In other words, I say you'd need to have measurements of fuel use under standardized settings to calculate the actual work done.

[isidoro]

Not to mention a simple factor like wind...

[jamespetts]

Thank you for your responses: looking into the proper definition of work, it does seem as though Dr. Supergood's suggestion is a good one: I just need to measure force multiplied by distance, which can be done once per tile traversed, and can take account of hills and other things affecting rolling resistance. The unit produced is a unit of change of energy, which can then be multiplied by the thermal energy in the fuel and again by the efficiency of the engine to get a figure for the cost of fuel used. I just need to find a way of extracting the force required to move the load at any given tile in order to make this work.

[DrSuperGood]

I have just made a pull request that changes the running and monthly costs of all vehicles. This post will highlight the changes made and server as a centre for discussion/complaint about any of the changes made. Hopefully these changes will make it into the next nightly build.

For anyone interested in seeing the logic behind the balancing, the spreadsheet that was used to generate the numbers for automatic merger is available below.
https://www.dropbox.com/s/3u8nvwb7gdklbz1/Pak128%20Britain%20In.xlsx?dl=0

Practically all trailers/coaches now have as good as 0 per km cost associated with them. The logic behind it is that trailers, coaches and other unpowered vehicles that are pulled/pushed around by powered verhicles will practically never wear out from doing so. In theory there is a cost as they will eventually wear out, however due to the low cost of trailers (no expensive engines) and their simplicity it is so small that it cannot be represented accuratly after rounding. Instead of rounding up (0.01) I rounded to nearest so in most cases this is in the players favour. For people on the server game this means that your trains will cost a lot less to run as a lot of the per KM cost is now expensive coaches.

All vehicles that have a cost now have a monthly cost associated with owning them. The extent of this cost is based on how well the vehicle ages when not used as well as the initial cost of the vehicle. This is only really significant for some vehicles such as planes, ships and such. Usually it will be a few simupounds per month for coaches and such.

Ships are very roughly balanced. One may find they have the wrong crew numbers or are impossible to run profitable over similar selections. This is because many of the ships have estimate weights and powers associated with them as well as strange water physics (not sure how realistic it is). Such ships can be balanced on an individual basis if required.

Some attempt was made to balance aircraft. How balanced they are I do not know.

Since the balance spreadsheet started out several weeks ago, some of the more recent manual changes made to the pakset might not be present in it. Over the next few weeks I will try to improve my automation framework or find some other way to merge in these changes as well as add additional columns for more balance information such as capacities, traction, retirement, etc.

The power to cost logic is almost certainly unrealistic. Until a power usage metering, fuel and consumable weight system is added to Simutrans Extended it will remain so. What such a system would allow one to do is meter the actual power used to move a vehicle and from that charge the player a more accurate fuel running cost. The fuel system would mean different types of fuel have different costs and these costs can change with respect to time to represent improvements in production technology to recessions and resource scarcities. The consumable weight system means that as a vehicle that consumes fuel travels it will lose weight proportional to the fuel being expended meaning that the vehicle becomes more economical to run per km a feature critical for steam engines (water and coal used up on the move) and aircraft (fuel used up on the move). Such a system does not mean that if a vehicle runs out of fuel it becomes stuck.

For accurate wearing out and maintainance values a vehicle durability system is needed, similar to what pathways now have. I believe this has already been proposed as the "overhaul" system and is an up comming feature some time in the distant future. All vehicles would have durability. As they move some amount of durability is expended. Every month they exist some amount of durability is expended. Some fraction of lost durability can be recovered cheaply by servicing the vehicle in a depot. Only way to fully restore durability is an expensive "overhaul", which in the case of some vehicles like large passenger aircraft or ships this might be a large cost of a new one. If a vehicles durability runs too low then its performance may be effected, including reduced maximum speed and power. The use of depots for this only makes sense with the up coming scheduling and recombination features as then depots become an integral and mandatory part of a lines operation.

[Vladki]

So, if the per km costs for trailers are (almost) zero, it means that a 1 wagon train has the same per km cost as 100 wagon train ?
I think that until we have power consumption based running cost, we should assign some running cost to trailers as well.
Or did you calculate the running costs for engines to include a fully loaded train of maximum length it can pull?

In practice there are also maintenance tasks that have to be done after certain amount of km running. These should be accounted for too.
And until we have overhauls, they should be too split into per km or per month costs.

An idea for future overhauls and services - vehicles with neglected service could not only have their top speed reduced, but also comfort (passengers) or capacity (cargo) reduced.
And for the fuel consumption system, don't forget that vehicles differ in efficiency. Even thou they consume the same fuel, they have different consumption/kW.

[DrSuperGood]

So, if the per km costs for trailers are (almost) zero, it means that a 1 wagon train has the same per km cost as 100 wagon train ?

Yes. However that 100 wagon train is impossible due to engine/pakset limitations so I never considered it...

Or did you calculate the running costs for engines to include a fully loaded train of maximum length it can pull?

They assume the engine is having to provide maximum power. It is up to the player to optimize the power output with length. Something that occurs naturally at the moment.

In practice there are also maintenance tasks that have to be done after certain amount of km running. These should be accounted for too.

Which they are currently in the form of a per km cost. However this is too small that rounding eliminates it.

[jamespetts]

Thank you for this - I have now incorporated this. A better way of doing balance (subject to test based updating of this if Dr. Supergood should be so inclined) will have to wait until the balance critical features (vehicle maintenance and inflation) are added. There may be a number of further matters to discuss in relation to preparing for balance in due course that can learn from Dr. Supergood's experience at this interim balancing exercise, some of which Dr. Supergood touches on above (such as the issue of power usage), and it would be helpful in due course to have a thread discussing and analysing in detail (mathematically and based on empirical evidence, preferably with examples and modelling) precisely what dynamics it is necessary to simulate in order to achieve a realistic cost/revenue balance before the work on the balance critical features is completed, but I am currently very busy with professional commitments and only just about have time to merge this.

In the meantime, if anyone else would like to start that discussion, it would be very worthwhile. This is the first time that we have had even an approximate cost balancing for Pak128.Britain (either Standard or Extended), and I am very grateful indeed to Dr. Supergood for the large amount of work that this must have entailed. Even though this may well be some way different from the final balance once the features are implemented in due course, this is still a significant achievement and advance for the pakset.

[DrSuperGood]

inflation

I am not too sure that inflation would bring much to the table. Sure it is something that occurs in real life, but all it really serves to do is devalue any liquid capital a company owns. On top of that it would require being applied to practically every aspect that has a cost associated with it and in the end the game itself might be internally using normalized costs then adjusted for inflation. I would not say inflation is critical for balance, especially when compared with a better staffing system as well as an fuel consumption system.

In the meantime, if anyone else would like to start that discussion, it would be very worthwhile. This is the first time that we have had even an approximate cost balancing for Pak128.Britain (either Standard or Extended), and I am very grateful indeed to Dr. Supergood for the large amount of work that this must have entailed. Even though this may well be some way different from the final balance once the features are implemented in due course, this is still a significant achievement and advance for the pakset.

To give people ideas on the time spent, I recon at least 20 hours of work in total. About 4-8 getting everything set up and then the rest processing data.

The current balance numbers might be a bit too cheap for some vehicles. This is slightly intentional so that people can enjoy playing the pakset without finding it impossible to make money at certain stages. If particular vehicle combinations are too profitable one can adjust the values in future.

I was thinking of increasing the transport value of all freight by an order of magnitude. Currently freight generates so little money that on the server most players are not bothering with it and instead solely focusing on Passengers and Mail which are big money spinners. A large problem with freight at its current price is how little of it is available to transport.

[jamespetts]

It is probably better to err on the side of being too easy rather than too difficult in case of doubt.

In relation to inflation, this is important for two main reasons: (1) the planned way of simulating inflation allows the simulation of differential inflation, in which labour costs, fuel costs, ticket prices, materials costs and other things change over time independently of each other so that the changing relationships between these things can be simulated (which was important in reality, especially changes in labour costs); and (2) (less importantly but still significantly) general inflation will prevent players accumulating large cash stockpiles early in the game which retain their value until the later part of the game (allowing, e.g., an 18th century canal empire to fund a 21st century airline).

In any event, thank you again for all your work on this.

[DrSuperGood]

(1) the planned way of simulating inflation allows the simulation of differential inflation, in which labour costs, fuel costs, ticket prices, materials costs and other things change over time independently of each other so that the changing relationships between these things can be simulated (which was important in reality, especially changes in labour costs);

This has nothing to do with inflation. If one separates the parts then each of those can be made to change with time. Similar to how speed bonus works in standard, but expanded for all kinds of things like fuels, labour, etc.

This also might result in deflation in particular areas at certain times, as occurred in real life. For example during the oil crisis oil based fuel costs would rise significantly, but after the crisis ends the fuel prices decrease.

(2) (less importantly but still significantly) general inflation will prevent players accumulating large cash stockpiles early in the game which retain their value until the later part of the game (allowing, e.g., an 18th century canal empire to fund a 21st century airline).

Except this assumes a company keeps their capital liquid. Most companies, like rich people, invest most of their free money in assets which are more inflation proof. This is how many rich people are still living off the Rockefeller fortunes. As such their wealth retains similar value irrespective of inflation.

The only reason a cannel company would accumulate fortunes like my own company on the server is because the player who controls it lacks enough time to spend the money as fast as the company earns it. Something that is not realistic as years in real life are years as opposed to under a day.

[Spenk009]

The only reason a cannel company would accumulate fortunes like my own company on the server is because the player who controls it lacks enough time to spend the money as fast as the company earns it.

If you were to leave your company untouched until the 21st century, I'm certain that obsolescence increases, lost business to faster rivals, reduction of toll income, etc. would all factor in to reduce income and slowly bankrupt the company. It could be very interesting to see this, although difficult to make happen.



Dr SuperGood How would you like your feedback to the changes? I'm certain people are happy to share their savegames, write out their experiences and thoughts and/or show screenshots.

(Savegame: 6400*1280, yr. 1922, 435 towns, 4.7m pop, img)
Passengers: I've found that my company earns a lot more money (around 3x), many bus lines are now less unprofitable if they have passengers. Smaller railway lines over shorter distances are now profitable, larger lines have less of a pronounced bump in income (imo very good). My turbine channel ferries, which are usually filled with passengers have had no impact on profitability, however I'm trading them for turbine coastal ships to make use of the passenger numbers (the hefty monthly increase is hopefully worth it).
Goods: The system I use for goods is mixed trains across the map, connecting industries that are convenient or have high I/O. The trains are doing better although I still have trouble making lines profitable. Road and Naval sections incur losses. The goods network is neither complete nor well designed, so I doubt it's a representative of goods focused playing.

[DrSuperGood]

Dr SuperGood How would you like your feedback to the changes? I'm certain people are happy to share their savegames, write out their experiences and thoughts and/or show screenshots.

By feedback I generally mean weather the balance changes are working or not. Or if you encountered some vehicle that is abolutly broken gameplay wise either positivly or negativly.

I balanced almost everything (I think 3 vehicles were added during that time which were not included in the spreadsheet) in the pakset. However I have tested only what is currently available on the server. Hence I cannot guarantee that something is broken or not, especially with the many modern trains or hovercrafts.

Goods: The system I use for goods is mixed trains across the map, connecting industries that are convenient or have high I/O. The trains are doing better although I still have trouble making lines profitable. Road and Naval sections incur losses. The goods network is neither complete nor well designed, so I doubt it's a representative of goods focused playing.

I think goods need their prices doubled or even tripled. The quantities they are available in, especially early game, is so low that it is always better to focus entirely on passengers.

[jamespetts]

In relation to the prices of goods - these are all set relative to passengers using historical data, so it would not be right to double or triple the prices. Work does need to be done at some point to improve the balance between producer and consumer industries, however.

[DrSuperGood]

In relation to the prices of goods - these are all set relative to passengers using historical data, so it would not be right to double or triple the prices. Work does need to be done at some point to improve the balance between producer and consumer industries, however.

The problem is that in real life you often had cargo ships and trains full to the brim with goods. Hence why they were so cheap to transport as there was so much of them. Passengers were logically more expensive to transport as you could not fill a bulk wagon or hold with them as they need space to breath and even accommodation and food on longer trips. Simply running 2-3 Australia to UK trips with a clipper carrying grain could pay for the clipper and then some!

Problem is in Simutrans Extended Pak128 Britain, good luck filling even a horse drawn cart with product! This is why it should be tripled or more. To make up for the fact that there is practically nothing to ship around. Where as with passengers you can load a ship to 1/4 capacity or even more, with goods you are lucky to load it to even 1/100 capacity early game (pre 1900 as on the servers currently). In the 1900s practically every town should have at least 1 coal distributers that takes large volumes (many tonnes) of coal. Coal mines should literally be filling train loads of coal every month.

What about deferring transport until there is a practical volume of good? Well the in transit limit does not allow for that! That is if one can even get a factory to work at all because a city has grown so large that it cannot get sufficient employment on either a plant or an end consumer.

[jamespetts]

This is a somewhat backwards way of looking at things, rather of the "we couldn't fix your brakes so we made the horn louder" school of engineering. The proper way of dealing with these difficulties with the industry is to fix the underlying problems, rather than interfere with the currently correct prices.

[Spenk009]

Midland Class 2441 and Class 1632 are introduced at different times, but are available to the same date and have fairly similar properties. Previously they were the same running cost/maintenance, but now the latter is 1/3 of the price of the former. Is this an intended change?

[DrSuperGood]

but now the latter is 1/3 of the price of the former

That would likely be as the result of it being introduced later when coal is cheaper and possibly having more efficiency. You can check the spreadsheet for details of where the values came from.

[jamespetts]

You can find my calculation of the fuel efficiency of all steam engines in the Steam physics calc.ods document in the sources folder: thus might be helpful for calculating running costs (it is intended to be used for this purpose when the balancing features are introduced).

[DrSuperGood]

You can find my calculation of the fuel efficiency of all steam engines in the Steam physics calc.ods document in the sources folder:

When I checked them the problem is that they assume the trains are running at their maximum speed. Hence with train speed increases the cost per km decreases, but in a realistic way. However if someone dumped a whole lot of heavy coaches on the train to force it to run well below its maximum speed the result is they get effectively cheap power from the engine.

As a result under such a model it is entirely pointless to use anything but the fastest locomotive as even pulling slow trains is done more efficiently by them than the dedicated slower locomotives. The only time a player might refrain from using such a fast locomotive is if the cost to buy it cannot be afforded, and even then they have to think in the long run due to it having a payback time.

This is why the model I used has the cost per km directly proportional to the power output. This is not realistic however it means that cheap small slow engines have a purpose for hauling appropriate stuff compared with the fastest always being the best.

As mentioned earlier for correct fuel costs a fuel system is needed. The game can then calculate the fuel costs based on actual work an engine does. This would mean that putting a lot of coaches on a fast train to make it slow or running a train with few coaches fast would use the same amount of fuel per unit time as both situations are using the full power of the train. However care must be taken with such a model and ships as a lot of the ship weights appear incorrect or guesses and I do not think ship physics is completely accurate.

[jamespetts]

That is a very useful analysis. Careful consideration to how to treat this issue will be necessary in due course, starting first, perhaps, with an analysis of whether adopting a realistic system would make a significant difference. We do need to address these issues before completing the balancing features and it is very useful that Dr. Supergood has had a go at interim balancing now so that we can see what features are necessary for balance.

In terms of ship physics, we may need to look into this in more detail. Does anyone have any data against which the ship physics can be tested? The main thing about ship physics that is different from the physics of other vehicles is the "rolling" resistance (i.e., resistance in the water).

[DrSuperGood]

In terms of ship physics, we may need to look into this in more detail. Does anyone have any data against which the ship physics can be tested? The main thing about ship physics that is different from the physics of other vehicles is the "rolling" resistance (i.e., resistance in the water).

This also has to be done with Aircraft since again they use different physics than a train or road vehicle.

Another reason for a fuel system is that it allows fuel costs to vary with time. For example coal would start out quite expensive in the 1840s due low scale mining and usage but by 1880 it would be considerably more cheap per kj of coal due to the large scale mining and transport occurring. This is important because it means running a more powerful locomotive that uses more coal per unit time would be more affordable at the times it happed in real life. This also is important for modern transport simulation as a big factor with transport today is fuel economy, with year on year rising fuel and energy prices encouraging the use of more economical planes, ships and trucks.

[jamespetts]

It was and is certainly planned to have a system in which fuel costs changed with time using the inflation system (different types of costs inflating/deflating at different rates).

As to aircraft and ship physics - on reflection, I am not sure how important that these actually are in economic terms in the game. Unlike with trains, where there are locomotives that can pull an indeterminate number of carriages or wagons and it is important for the game engine to make sure that players cannot get an unrealistic effect by using weak vehicles to haul heavy loads), aircraft and ships are singular units. Because they tend to go long distances (and, in the case of ships, go very slowly), the rate of acceleration is of minimal importance. What is really important for aircraft and ships therefore is just the top speed, at which they will be travelling most of the time. In principle, it should be much easier to balance the physics for these than for rail vehicles (and, to a lesser extent, road vehicles).

[DrSuperGood]

the rate of acceleration is of minimal importance. What is really important for aircraft and ships therefore is just the top speed, at which they will be travelling most of the time. In principle, it should be much easier to balance the physics for these than for rail vehicles (and, to a lesser extent, road vehicles).

With powered ships the current speed (not maximum speed) is extremely important when it comes to economics. In recent times container ships have been going slower on average as reducing speed a knot or two results in huge fuel savings for the same distance. For the same reason cruise ships often run well below their maximum speed as it results in huge fuel savings. This was especially important back in the days of steam ships as running at full power would burn coal very fast resulting in huge fuel costs as well as short maximum range. The player should only be paying for fuel that is used, not the full power of the ship.

With aircraft the weight of the plane, including fuel on board, is critical for their economics. A long distance flight with an aircraft will cost on average more per km than a short distance one as more energy is expended lugging fuel. In fact a long distance flight that has just taken off is unable to land until most of its fuel has been expended as planes are not designed to land reliably/safely at that weight. Like with boats, the current speed of an aircraft is also important for economics with slower often being more efficient. This is why passenger planes have been running slower over the decades, to reduce fuel costs.

I do not know how much weight effects the economics of a ship. Often ships require extensive ballast if their cargo holds are empty for ship stability, hence I imagine weight having little effect on ship economics.

This means that a speed cap feature is required between hops in line management. However even with such a feature one needs to calculate a fuel cost for ships and planes that is appropiate for the speed they run at. If a correct physics model is not used, one which energy used can be metered, then one would need to work out a mathematical model for each plane and boat to come up with reasonable fuel consumption estimates per km travelled.

[jamespetts]

I have been wondering about a speed cap feature: that should not in itself be excessively complicated to implement. However, one significant problem of a speed cap feature and also a weight dependent running costs feature is how to communicate the running costs to the player when the formula for calculating them is very complex. Have you any idea of a sensible and clear way of explaining these running costs in the user interface (and also of researching the relevant running costs for ships)?

For aircraft, fuel consumption is often available as an hourly rate based on that aircraft's standard cruising speed. I have not found any more in-depth data than that. One of the difficulties of making the formula for calculating fuel costs more complex is that one needs more detailed research data, which are not always available. Certainly, so far as I can tell, for aircraft they are not readily available. Would it not be better to have ships' and aircraft's maximum speed to be their normal cruising speed and calculate fuel consumption on the assumption that they are travelling at this rate? Aircraft circling at airports already have a feature to reduce their per km cost on account of their lower speed in this situation.

For steam engines, my calculations in the spreadsheet (the correct name of which is steam-physics-calc.ods - the previous file name was given from memory) give the kilograms of fuel consumed per hour per square foot of firegrate area, the calorific value of the fuel, the thermal efficiency of the locomotive and the resulting power. There are actually two ways in which the calculations are done: for the rows highlighted in yellow, these are calibrated engines, where the thermal efficiency is calculated backwards from the power, and the power is set by testing in-game performance against recorded real world performance (adjusting for gradients using a formula where necessary). The white rows are non-calibrated engines, whose efficiency is supplied manually based on a reasonable guess as to the efficiency of a locomotive of that sort in the relevant era and taking into account any reports about what is known about the locomotive and whose power is calculated from the efficiency and from the calorific value of the sort of coal known to be used by the railway company for which it worked. Neither of those calculations rely on making any assumptions about speed.

Assumptions about speed would be necessary for converting the data currently in this spreadsheet into a range or fuel consumption per kilometre, however. The original plan was to do this on the basis of an assumed average speed as a fraction of the multiple speed (perhaps 2/3rds). Do your calculations suggest that the actual average speed of trains varies so much that this would create real economic distortions in the game? If so, I should be interested to see these calculations.

Another thing to bear in mind if one has a non-fixed fuel consumption per kilometre is that not only will the running costs vary with this, but so will the range of those vehicles whose maximum range is determined by fuel capacity (e.g. aircraft and steam locomotives - but not, e.g. horses). This would require a whole other layer of complexity.

Given the intractable complexity of varying per km fuel consumption, do we perhaps need to do some modelling to calculate the real significance of this in an in-game setting to determine whether this is necessary, and, if it is, precisely how much depth is required for this?

[DrSuperGood]

I have been wondering about a speed cap feature: that should not in itself be excessively complicated to implement. However, one significant problem of a speed cap feature and also a weight dependent running costs feature is how to communicate the running costs to the player when the formula for calculating them is very complex. Have you any idea of a sensible and clear way of explaining these running costs in the user interface (and also of researching the relevant running costs for ships)?

How are they done in real life? The idea would be to give a player a fuel expenditure estimate in the form of currency. This estimate need not be perfect, even in real life they never are, but close enough so that a player can see that running his trains 10km/h slower top speed might save him about X currency. For weight one can factor in fuel weight as well as average freight/passenger weight. This estimate could be shown at a line management level when the player is selecting the vehicles to use for that journey (part of the new recombination system), and also when selecting a vehicle for the current hop. Actual fuel costs could be charged when a train arrives at a stop (refuels) as that would probably simplify calculations no matter how the system is implemented.

Sure if the vehicle gets a passenger spike it might use more fuel than the estimate, but the owner really should not care as more passengers means more revenue. Like wise if there is bad traffic congestion resulting in much reduced economy (breaking is wasted energy for most vehicles) the player would understand that his fuel costs are higher than estimates and would likely try to optimize traffic flow.

In line management one could also show the actual fuel expenditure for a hop. This could be as simple as logging how much over or under the estimate was spent between a particular hop so as to factor in different vehicles servicing the same line. Again this can be calculated at stops, so is processor friendly. This could even be shown as a percentage over/under, which would be enough for a player to notice there might be a problem or maybe a line is running more efficiently than expected.

In real life fuel consumption is often not a direct concern when planing a route. For example trucking some freight between to depots it is unlikely that fuel consumpution was estimated beyond the km distance between the stops and the average km per liter of fuel. When it is calulated, it is usually rule of thumb estimates, often overly cautious. To save on fuel economcy companies generally use rule of thumbs that have been calculated by engineers and accountants. For example they might order their entire shipping fleet to run a few knots lower to save fuel. The amount acutally saved will approximatly be what is expected, but obviously will deviate from the estimates as nothing in the real world is perfect. Exception is aviation industry because fuel is a huge cost and running out of fuel has catostrphic results, there estimates will likely be more accurate and factor in even weather but they still have to run on the side of caution with reasonably excessive fuel.

For aircraft, fuel consumption is often available as an hourly rate based on that aircraft's standard cruising speed. I have not found any more in-depth data than that. One of the difficulties of making the formula for calculating fuel costs more complex is that one needs more detailed research data, which are not always available. Certainly, so far as I can tell, for aircraft they are not readily available. Would it not be better to have ships' and aircraft's maximum speed to be their normal cruising speed and calculate fuel consumption on the assumption that they are travelling at this rate? Aircraft circling at airports already have a feature to reduce their per km cost on account of their lower speed in this situation.

Problem is cruise speed varies based on economics. If fuel is cheap and passengers want to pay a premium to get to their destination then cruise speed is higher. In real life passengers often want to pay as little as they can and fuel is expensive so cruise speeds are lower. The issue is due to air density and weight, since the more dense the air is the larger the drag losses are but the easier it is to keep a heavy plane flying as well as the more efficient the turbo fan jet engines are. Drag losses go up with speed. This is why planes need to fly very high above sea level to achieve such high speeds such as 920 km/h since otherwise the noses and engines of the plane would literally overheat if at sea level due to the drag. However turbo fan engines rely on combustion as well as air flow to provide thrust, and as such the higher the altitude they are operating at the lower their efficiency becomes. Cruise speed is thus determined by cruise altitude which is determined by economics. Many modern planes are capable of cruise speeds much faster than they are operated at.

give the kilograms of fuel consumed per hour per square foot of firegrate area

That makes a lot more sense now! I thought it was kg per hour in total...

However again this depended on how much work (steam) the locomotive was using. If they were pulling a light train slowly they would not need to burn the maximum fuel to produce the maximum steam. For example if a steam engine was in a station for an extended period it is unlikely much coal had to be shoved in it while parked there. Of course coal has delayed burning so the fireman/men would start shovelling coal in before it departs so the boiler is up to pressure, but that is just how they worked. Additionally some fuel is needed to keep the fire running, a sort of standing loss. In any case even with steam engines there would be economics for running a train slower. This can be as simple as running at a slow speed in crowded track sections where trains often had to stop, something one experiences daily in real life commuter trains.

Assumptions about speed would be necessary for converting the data currently in this spreadsheet into a range or fuel consumption per kilometre, however. The original plan was to do this on the basis of an assumed average speed as a fraction of the multiple speed (perhaps 2/3rds). Do your calculations suggest that the actual average speed of trains varies so much that this would create real economic distortions in the game? If so, I should be interested to see these calculations.

Trains that ran slower might have a longer range. A train that can go 300km at 100km/h might make 500km at a slower average running speed. This is especially the case with early steam ships as they had poor fuel efficiency and capacities. To be honest I am unsure with steam trains, since drag only becomes a problem at higher speeds so this might not effect early steam trains that much. With ships this happens at a much lower speed due to the density of water. Like wise with aircraft at cruise altitude this happens at a much higher speed due to reduced drag from low density air.

Another thing to bear in mind if one has a non-fixed fuel consumption per kilometre is that not only will the running costs vary with this, but so will the range of those vehicles whose maximum range is determined by fuel capacity (e.g. aircraft and steam locomotives - but not, e.g. horses). This would require a whole other layer of complexity.

Unlike real life a game can be more forgiving as it is less complex and accurate. As such if loaded fuel estimates and ranges are wrong and result in a vehicle technically running out of fuel on a journey one might overlook it and not punish the player at all next to charging them the extra fuel spent with possibly some penalty percentage.

For some vehicles a speed against range graph could be shown, eg planes. For trains one might also show a weight against range graph for a certain speed (selectable).

Given the intractable complexity of varying per km fuel consumption, do we perhaps need to do some modelling to calculate the real significance of this in an in-game setting to determine whether this is necessary, and, if it is, precisely how much depth is required for this?

Even if the model ends up not that complex or deep, in any case a better model than currently exists is required for realistic vehicle operation and running costs. To put in in perspective the reason aircraft cruise speed has become slower is it saves the airline companies millions every year, even if the aircraft could cruise much faster at a different altitude by design.

[jamespetts]

The UI suggestions relating to graphs and estimates seem to require a truly gargantuan amount of work for the UI alone - would you be interested in coding this? Any UI elements beyond the very simple are very hard indeed to code in Simutrans because of the nature of the codebase.

I note that you seem content to simplify away range depending on actual speed and work but not per kilometre costs. I am not clear why you are taking a different approach to these things in this instance.

For aircraft, there is very little variation in the speeds at which a given model of aircraft actually routinely cruises. There is a degree of discretion for an airline operator to select a lower cruising speed and save some fuel (as there is for ships), but would it really be a major issue of this choice was made at the pakset design level rather than the player level? I should note that already the aircraft speeds are based on their cruising speeds not their maximum speeds.

In relation to modelling, what I meant was actual calculations based on real life data done now to determine whether the work/speed variance in relation to fuel consumption is significant enough (compared to using an estimated average for each powered vehicle type) to be worth simulating in the game given the amount of additional work that would be involved and therefore the many additional months before this feature would be available. Have you done any calculations of this sort; do you have any data from which such calculations can be made?

[Vladki]

This seems to be heading for too much complexity. I think before we start touching fuel consumption related stuff, we should first check and fix all other physics related stuff - acceleration, slopes, corners. Especially slopes seem to be a problem at the moment - with some vehicles being underpowered even to climb one level up.

In real life fuel consumption for a trip is estimated by using long time averages (or manufacturer specs). These average numbers should take into account usual cruising speed (for ships and planes), usual weight of cargo, some mix of going uphill and downhill, etc. In all specs I have seen the consumption is in liters / 100 km or liters / hour (or miles / gallon). I have never seen liters / Joule. Well you can find J/kg for different fuels, but that is the heat you get from burning them, not the mechanical work you get by using the fuel in engine. I don't think that the efficiency ratio for different vehicles would be easy to find. Maybe some approximate values for certain types of engines, but those would be very broad ranges. Efficiency also varies with RPM of engine.

Even if you would be able to find those values, it would be very confusing for players. Now we have two easy numbers: $/km, $/month. For full physics we would have:
$/kg (or liter) of fuel, J/kg of fuel, efficiency % of engine - well this can be put together to get $/J.
And how is a player supposed to calculate the $/km ?
Take into account weight of the train, energy needed to accelerate to full speed, friction (at varying speeds), distance.
You have to check how often it has to slow down and accelerate again due to corners, and how much it goes up or down hill.
Also how much fuel it uses while running idle (loading cargo).
All this can't be calculated before the engine is bought. One has to assemble the train, and set up schedule. Only then we can calculate price of each hop of the route.

If this complex model is ever implemented, I would suggest that each convoy, would have it's own counter for fuel consumption, so that player could make estimates based on really measured values.
And the depot window should show approximate value taken either from real world specs (for common cruising speeds/altitudes, usual length/weight of train, excluding special record setting events, etc), or values obtained by playing the game.

[jamespetts]

Vladki has a point that a fuel consumption based system is likely to be difficult for players to understand and engage with - this is why we need to undertake modelling to check whether it is strictly necessary if we are to have a workable balancing system using real life numbers or whether using (as discussed above) an average speed would be close enough to suffice.

[DrSuperGood]

I have never seen liters / Joule.

This is covered by chemistry.

but that is the heat you get from burning them, not the mechanical work you get by using the fuel in engine

That is covered by engine efficiency.

Efficiency also varies with RPM of engine.

Which is why gearboxes are used, to try and keep the RPM of an engine within its optimum range.

And how is a player supposed to calculate the $/km ?

They are not. The game should give them an estimate which is reasonably accurate.

The problem with per km costs is it does not factor in the actual amount of work done. A fast powerful train pulling a lot of coaches might move very slowly but it is doing the same amount of work as if the train was pulling few coaches very fast. A more accurate measurement would be cost per hour since then a slow train or fast train using the same power will result in the same cost. However this is not accurate itself since if the train is not using all its power then it should not be billed as using all its power, as would be the case of a powerful locomotive pulling a few coaches slowly. Fuel can also be saved by running trains slower than their designed speed, eg making sure they do not exceed the minimum speed maximum of trains traveling the same congested line.

[jamespetts]

Dr. Supergood - do you have any data as to the variation in fuel consumption per kilometre for, say, railway locomotives for the purpose of modelling?

[DrSuperGood]

This article covers many points relating to energy efficiency. It includes mentioning that drag on aircraft is directly proportional to weight (due to converting forward motion into vertical lift to keep the plane from falling) and hence weight is directly proportional to fuel consumption with aircraft. It also covers that one of the biggest energy expenditures on urban railway lines is breaking, being as much as over 40% of the total energy usage. It also mentions the energy of different fuel sources. Also mentions that train fuel economy can vary greatly between different stretches of the same route.
https://en.wikipedia.org/wiki/Energy_efficiency_in_transport

Here is a paper which covers efficiency related concepts specifically for trains. In the section of Dynamic train movement a simulated train was used to demonstrate how energy consumption for the same journey varied with both train weight and train speed. It is worth noting that due to the higher loadings in the simulation, the train velocity decreased which itself raises energy efficiency, hence why it looks like heavily loading the trains becomes increasingly more energy efficient. A second graph goes on to show the effect of maximum driving speed on energy consumption by keeping the weight of the simulated train constant. A section also discusses fuel cost implications. A table shows that in their simulation of 20km at a 2% gradient moving 100t cost 14€ of energy while 2,000t cost 120€ of energy. It also makes mention that energy is a huge cost, often greatly exceeding the cost of line rental for a distance on a real network.
https://hrcak.srce.hr/file/122021

How one could model this I am not sure. One could try pre computing efficiency metrics for each hop of a line using some kind of simulation model. One could also try using a physics system and metering the energy used. In any case in real life this stuff does make a big impact to economics.

As far as player usability goes it would likely be similar to real life energy efficiency, often after thought or something that occurs towards modern times. If a player is noticing huge expenditure on energy they might look to optimize energy efficiency such as lowering the maximum speed on low traffic lines or decoupling coaches that often sit mostly empty. As fuel costs rise towards modern times the player would have to increasingly look to save energy, including removal of inefficient rolling stock, flattening/straightening of lines, optimizing signals, lowering maximum speeds, etc.

[jamespetts]

What we really need to model is the extent to which fully dynamic fuel efficiency calculation in so far as it can be implemented produces different results in game to static, averaged fuel efficiency per vehicle. For aircraft, for example, one would have to calculate, not only passenger loading, but luggage loading and the fuel weight necessary for the flight, which then reduces during the flight - a fantastically complex thing to calculate in itself. What is really necessary to understand is not whether these things are significant in reality in general, but rather whether they are so significant that it would be impossible to have any workable balancing using (averaged) real life figures without using dynamic rather than static fuel efficiency computation.

There is a difference between the game being simplified and not fully simulating some real-world dynamics such as varying fuel consumption, but being accurately balanced within those simplified parameters, and the game being unbalancable (or only balancable in a way that means that, even within the simplified range of things simulated, the optimum thing to do is often significantly different in game than it would be in reality) because of not simulating those additional dynamics. It is necessary to discern which is the case before progressing with balancing features.

It is not immediately clear to me precisely how one would go about modelling for this comparison - any thoughts on appropriate formulae/algorithms would be welcome.

[DrSuperGood]

What we really need to model is the extent to which fully dynamic fuel efficiency calculation in so far as it can be implemented produces different results in game to static, averaged fuel efficiency per vehicle. For aircraft, for example, one would have to calculate, not only passenger loading, but luggage loading and the fuel weight necessary for the flight, which then reduces during the flight - a fantastically complex thing to calculate in itself. What is really necessary to understand is not whether these things are significant in reality in general, but rather whether they are so significant that it would be impossible to have any workable balancing using (averaged) real life figures without using dynamic rather than static fuel efficiency computation.

With trains it is pretty obvious such a system is required. A train pulling fewer coaches or a lot of empty freight coaches should cost significantly less per km than the same train pulling a lot of coaches or full freight coaches. This is required to give a lot of economic sense behind having smaller trains with fewer coaches.

For example take a bulk train running coal from a mine to a dock along a flat stretch of rail. Currently moving the train costs the same in both directions. In real life it costs considerably more to move the train full of coal to the dock than it does to move the empty train from the dock back to the coal mine.

However coal mines are seldom on a plain, especially in the UK, and hence in real life the mine might be at a considerably higher altitude from the dock. Now in this example the same bulk train is running coal from a mine to a dock downhill. Due to gravity there is a huge energy saving on the previously energy intensive mine to dock route which now might require almost no input power (nearly free) depending on how steep the gradient is. On the other hand the dock to mine journey now requires considerably more energy to cover lugging the empty trucks up the gradient so is more expensive energy wise. However since the empty bulk trucks are only a fraction of the weight of the full bulk trucks the net result of this line configuration is that less energy is needed to move the coal and so considerable amounts of money are saved.

Currently in Simutrans and Extended this is impossible to simulate as the trains cost the same per km irrespective of how much of their power gets used. Trains will also always try to accelerate to the maximum speed they can, even if it does not make them arrive any faster as they are scheduled to run behind slower trains so end up waiting at signals. Now I am not saying that it needs to be simulated every tick with a phsyics model. However some system needs to be in place that allows the player to limit maximum speed and depending on maximum speed and how much weight a train is lugging the running cost of the train goes down.

[jamespetts]

It does not really assist much to state that it is "obvious" or that the difference is "huge". What we need are numbers. In particular, what we need to know is not just whether there is a difference in fuel consumption between running full and empty or running on the level or uphill, but rather whether it will make a significant difference to how the game plays out and what strategy is optimum for the player in all but edge cases if we actually simulate these things dynamically rather than taking an average of level and uphill, loaded and unloaded, etc.. It is this latter aspect that is critical - this is what tells us whether the extra complexity is worthwhile (and also, if it is, in precisely what way and to precisely what extent, so that we can work out what simplifications may be workable in simulating this).

Let us take some specific examples to work with for the purpose of modelling. I suggest that we model three specific examples: (1) a freight train; (2) a passenger train; and (3) a passenger jet airliner.

Starting with the freight train, let us use for these purposes the LNWR DX Goods of 1858 as the locomotive, and imagine that it is hauling 25 wagons of coal (each with an 8t load) with a 7.5t brake van at the end of the train. The tare weight of such a train is 149.5t, and the payload is 200t, making the loaded weight 349.5t. The rolling resistance empty is 0.284kN and full 0.664kN. The locomotive's power is 167kW. My estimate of its thermal efficiency is 3.8%; it burns 31.75kg of coal per hour per square foot of firegrate area to produce the 167kW output, the coal having a calorific value of 8.12 kW/kG. The firegreate area is 17.1 sq. ft., so the total coal consumption is 542.9kg/hour. The train's maximum speed is 56km/h, which, being a slow freight train, it is likely to achieve for perhaps about 80% of its journey. Taking 80% of 56km/h gives us 44.8km/h, which would then be the basis for the average speed for the purpose of fuel consumption calculation for the averaged method. At 44.8km/h and 31.76kg/hour, that gives us 542.9kg/44.8km, or ~12.1kg of coal per km.

Turning to a passenger train, we can start with some real world data reproduced here showing that the LNWR "Precedent" class had an average coal consumption of 33.2lb/mile. This would work out as 16.6kg/mile or 10.4kg/km. It is instructive to compare this with the extrapolated figures for this class of locomotive. This locomotive has a power of 204kw and I have estimated a thermal efficiency of 4.5%. It is estimated to have consumed 32.75kg of coal per square foot of firegrate area per hour, and has a firegrate area of 17.1 square feet, giving a total hourly consumption of 560kg/hour of coal. The locomotive's maximum speed is 130km/h, but it is unlikely to sustain this for long in practice, so I will estimate an average speed of 65km/h (half the maximum speed). At this speed, 560kg of coal would be consumed per 75 km, giving a per km consumption of 8.6kg/km. To get 10.4kg/km as from the historical data, the average speed would have to be estimated at about 54km/h. (This might be a good way of calibrating the average speed if we were to do it in this way).

As for a passenger aircraft, we will take the example of the Boeing 707. According to this source, this used approximately 1,200 gallons of fuel per hour, or 4,542l per hour. The Boeing 707-120 has a capacity of 137 passengers in ordinary configuration. Its tare weight is 84t and its loaded weight is 93.59t. It is given a power of 43,200kW and has a range of 5,037km. Its maximum speed in game (i.e., its deemed cruising speed) is 885km/h. At this speed, it will burn 4,524l of fuel per km, equivalent to 5.11l of fuel per km.

The above are all calculations based on the averaging method that I was planning to use (the final step, omitted here, being to convert the per km fuel consumption figures into per km costs using historical pricing data for the relevant fuel types).

Can you set out some specific worked examples (with figures as above), being not edge cases, for these three vehicle sets in which a dynamic system would make a real difference to the actual average per km cost paid by players in different situations, each realistically likely to occur in game, such that these differences would not simply be irrelevant by virtue of being averaged out over time and that players would have a real incentive to make substantially different choices in a dynamic than an averaged static system?

[DrSuperGood]

I am having trouble coming up with the needed examples. With aircraft it seems that there can be around 10-15% variances in fuel cost with range and like wise with weight however I cannot easilly find a mathematical model for this that would fit with your example aircraft (the one shown was for a different model of aircraft).

My estimate of its thermal efficiency is 3.8%; it burns 31.75kg of coal per hour per square foot of firegrate area to produce the 167kW output, the coal having a calorific value of 8.12 kW/kG. The firegreate area is 17.1 sq. ft., so the total coal consumption is 542.9kg/hour.

I am a bit unsure of how you came up with "31.75kg of coal per hour per square foot of firegrate area". I would imagine the amount of coal one needed to burn was based on how much work the train had to do. I recall hearing that firemen would have to shovel in extra coal in the run up to a hill to make sure there was enough steam to climb it. Sure that would define the maximum power of the steam engine, but not how much fuel it is burning unless you assume all power is being used.

Now be aware I did not do advanced physics so what I am about to say might not be correct...

For simplicity sake let us say this train runs at 44.8km/h along a 44.8km stretch and ignore acceleration/deceleration losses (more important with commuter services, probably trivial for a freight train). This means that time is 1 hour (3600 seconds).

Rolling resistances...
Loaded -> 664N
Unloaded -> 284N

The total work done...
Loaded -> 664N  * 44,800m = 29,747,200J
Unloaded -> 284N  * 44,800m = 12,723,200J

This means that the power used to move the train during that time is...
Loaded -> 29,747,200J / 3,600s = 8,263W = 8.3kW
Unloaded -> 12,723,200J / 3,600s = 3,534W = 3.5kW

Something looks very wrong with these values, they are so small that a tiny 20kW train train could manage it. You did say rolling resistance so I am guessing this does not factor in aerodynamic drag, another huge loss for trains. As this train is slow it should not be that much, but who knows...

The density of air at sea level is 1.2kg/m³ according to wikipedia. UK being an island with trains often running near sea level means this is reasonable. The velocity is 44.8km/h, as mentioned above, which is ~12.4m/s. I cannot find a decent drag coefficient for an old steam powered freight train however some site state that a "passenger train" is 1.8 and a "Rectangual box" is  2.1 so 2.5 seems a good estimate to factor in the complex shape of a steam engine and rough surface of open coal trucks. Apparently for frontal surface area a value of 10m² is commonly used for trains, so lets go with that.

Drag Force -> (1/2) * 1.2kg/m³ * 12.4 ^ 2 * 2.5 * 10m² = 2,306N

This is considerably larger than the rolling resistance, not something we can ignore.

The total work done...
Loaded -> (2,306N + 664N)  * 44,800m = 133,056,000J
Unloaded -> (2,306N + 284N)  * 44,800m = 115,942,400J

This means that the power used to move the train during that time is...
Loaded -> 133,056,000J / 3,600s = 36,960W = 37kW
Unloaded -> 115,942,400J / 3,600s = 32,206W= 32kW

Now this value makes more sense. The empty train will be using 32kW of coal while the full train 37kW of coal.

Since you calculated the 542.9kg/hour to produce 167kW that means the train will consume...
Loaded -> 542.9kg/hour * 37kW / 167kW = 120kg/hour
Unloaded -> 542.9kg/hour * 32kW / 167kW = 104kg/hour

In per km fuel costs...
Loaded -> 120kg/h / 44.8km/h = 2.68kg/km
Unloaded -> 104kg/h / 44.8km/h = 2.32kg/km

Or in savings when moving the empty coal train over the full coal train...
Savings = 1 - 2.32kg/km / 2.68kg/km = 0.134 = 13.4%

Firstly this calculation shows that the train in the given conditions would be using well under half its potential coal consumption since only a small amount of its power is needed to keep the coal trains moving. Secondly it shows that running the empty train is 13.4% cheaper per km than when pulling the full train. It also shows that most of the power is being used to combat airodynamic drag, possibly due to how bad I am at calculating this sort of thing (maybe the number was smaller in real life? or larger?). It is also possible the rolling resistance numbers are wrong, I do not know for sure.

This does sort of make sense. The train only needs most of its power when accelerating or when climbing a hill. There are practical limits to the load it can hall based on these conditions.

Now this does not factor in accelerating the train to 44.8km/h. This uses the trains extra power but is technically an energy cost hence would have a cost in kg of coal associated with it.
Loaded -> 1/2 * 349,500kg * 12.4m/s ^ 2 = 26,869,560J
Unloaded -> 1/2 * 149,500kg * 12.4m/s ^ 2 = 11,493,560J

Assuming 30MJ per kg of coal (https://en.wikipedia.org/wiki/Energy_density) with 3.8% efficiency...
Loaded -> 26,869,560J / 30MJ/kg / 0.038 = 24kg
Unloaded -> 11,493,560J / 30MJ/kg / 0.038 = 10kg

Is this cost significant? it is between 1/10 and 1/5 of an hour of running, more so when loaded than unloaded.

I will look into the second rail example later.

[ACarlotti]

One brief thing to note is that I believe the physics engine currently uses only the air resistance of the leading vehicle, ignoring any resistance along the side of the train or caused by the gaps between vehicles. While the resistance to the leading vehicle is more significant than that to any other individual vehicle, this does not necessarily mean that subsequent vehicles can be ignored. Indeed, I think over a long container trains the overall effect of subsequent vehicles is rather significant. (I do not have any figures for this right now, but the RAIB report about a wheelchair striking a freight train due to air movement overcoming the brakes comes to mind.)

[jamespetts]

Dr. Supergood - thank you very much for the calculations. I have not had time to review them in detail as yet, as I have been very busy this week, but some initial thoughts pending your second rail example.

Firstly, I suspect that there is an error somewhere apropos air resistance: between rolling resistance and air resistance, rolling resistance is by far the most significant. Air resistance is trivial at low speeds, and minor at moderate speeds. It is more significant at higher speeds, and significant enough that streamlining makes a difference at >90mph (but below that speed, streamlining has no significant effect in real life). I am not sure where the error is in the calculations (one or more off by orders of magnitude error(s)?) as I did not write the physics code.

Secondly, for the purposes of discerning the economic (rather than purely physical) significance of different fuel consumption rates, we have to compare not just loaded and unloaded fuel consumption, but dynamic calculation of fuel consumption (as you suggest) against static averaging of fuel consumption (as originally planned) to see whether this differs significantly in significant enough ways in enough cases to justify the additional complexity that this would entail. For example, taking your figures of 37kW vs. 32kW (I pause to wonder whether we should really be measuring energy, i.e. kWh, rather than power (kW)) for loaded vs. unloaded, what we need to do is to compare, not 37kW with 32kW, but rather the average of the two, 34.5kW being applied at all times as against the figure being calculated dynamically and varying between 37kW and 32kW.

Of course, on a flat journey, this would make no difference at all: the loaded trip in one direction would consume 37kW and the unloaded trip 32kW, and the two would average out to 34.5kW, which would be exactly the same result as if the average 34.5kW had been applied to both trips individually. One case that you mentioned where this might make a difference is with a heavy freight load that is higher in altitude than its destination. This is indeed the case, but I am doubtful as to the actual significance of this in gameplay terms, both in terms of the magnitude of the numerical significance and the frequency with which it is likely to be encountered in game. The pakset will have to be balanced so that flat journeys make a profit in any event, so it it really important that players would not be able to make extra profit from a downhill run?

Another perhaps more significant consequence might be that players have more disincentive than they would have in reality to use more powerful vehicles where less powerful vehicles would do; but I am still not sure of the real practical significance of this in magnitude terms, nor whether a simple dynamic power calculation would get this right: after all, players should not have an incentive (as they do in Standard often) to use the most powerful vehicles for everything.

A. Carlotti - as to side drag: this is an interesting thought. I did not write the physics code, and given its complexity and my lack of knowledge of the details of physics, I should be reluctant to change it; I also do not know any figures for calculating side drag so as to be able to modify the code even if i were inclined to do so.

[ACarlotti]

I think it is currently impossible to produce accurate (or close to accurate) running costs for all four combinations of:
1. A diesel locomotive with high energy costs
2. An electric locomotive with low energy costs
and:
a. A short train of (say) 2 coal wagons
b. A long train of (say) 20 coal waggons

Clearly replacing 1b with 2b should lead to a greater reduction in running costs than replacing 1a with 2a, but at present these two replacements cannot produce different reductions in costs.

So this suggests that some account of actual energy consumption is needed in the long run.

A. Carlotti - as to side drag: this is an interesting thought. I did not write the physics code, and given its complexity and my lack of knowledge of the details of physics, I should be reluctant to change it; I also do not know any figures for calculating side drag so as to be able to modify the code even if i were inclined to do so.

I think I would feel comfortable working on this at some point in the future, but I would anticipate this being multiple years away given my other priorities.

[DrSuperGood]

Firstly, I suspect that there is an error somewhere apropos air resistance: between rolling resistance and air resistance, rolling resistance is by far the most significant. Air resistance is trivial at low speeds, and minor at moderate speeds. It is more significant at higher speeds, and significant enough that streamlining makes a difference at >90mph (but below that speed, streamlining has no significant effect in real life). I am not sure where the error is in the calculations (one or more off by orders of magnitude error(s)?) as I did not write the physics code.

I suspect the value you provided for rolling resistance is incorrect. Possibly it excluded the rolling resistance of the steam engine which would be higher per ton than the coaches due to pistons and levers being attached to the wheels.

Even at 44.8km/h air drag starts to become significant if you are moving a box at those speeds, which might actually be more aerodynamic than a steam engine due to all the discontinuities on the surface as well as strange protruding shapes. Sure the calculations might not be completely accurate, I have a feeling 10m² might be too large for the front cross section of a steam engine. At 89.6km/h drag is 4 times as much as at 44.8km/h and the power needed to overcome drag is 8 times as much. Hence the values do seem kind of reasonable.

I think all the "but below that speed, streamlining has no significant effect in real life" talk refers to everything now days being streamlined in the first place and hence below those speeds the drag is minimal that improving streamlining further has limited effect. Some modern cars have a drag coefficient of ~0.25 with tiny front cross section, where as something like a steam train would be ~2 (this might be wrong) with a much larger front cross section. This means that for a car the drag forces at 44.8km/h are insignificant where as for the steam train they are considerably more significant.

I am not sure where the error is in the calculations (one or more off by orders of magnitude error(s)?) as I did not write the physics code.

This has nothing to do with the physics code. I literally went to Wikipedia and read up all the formula. The formula states that for a doubling in speed the force exerted by drag increases by 4 times and the power required to overcome drag by 8 times.

https://en.wikipedia.org/wiki/Drag_equation

Secondly, for the purposes of discerning the economic (rather than purely physical) significance of different fuel consumption rates, we have to compare not just loaded and unloaded fuel consumption, but dynamic calculation of fuel consumption (as you suggest) against static averaging of fuel consumption (as originally planned) to see whether this differs significantly in significant enough ways in enough cases to justify the additional complexity that this would entail. For example, taking your figures of 37kW vs. 32kW (I pause to wonder whether we should really be measuring energy, i.e. kWh, rather than power (kW)) for loaded vs. unloaded, what we need to do is to compare, not 37kW with 32kW, but rather the average of the two, 34.5kW being applied at all times as against the figure being calculated dynamically and varying between 37kW and 32kW.

Problem is that the average could vary in so many ways... Raising the speed of the train would raise the average due to additional drag. Adding more coaches would raise the average due to additional rolling resistance. Using a vehicle with a better drag coefficient, eg, a smaller steam engine, might lower the average due to less drag losses.

[jamespetts]

I think all the "but below that speed, streamlining has no significant effect in real life" talk refers to everything now days being streamlined in the first place and hence below those speeds the drag is minimal that improving streamlining further has limited effect.

No, I recall reading this in relation specifically to steam engines: this is why so few steam engines were ever streamlined: it made virtually no difference to the speeds at which all but the fastest steam engines would ever run.

Problem is that the average could vary in so many ways... Raising the speed of the train would raise the average due to additional drag. Adding more coaches would raise the average due to additional rolling resistance. Using a vehicle with a better drag coefficient, eg, a smaller steam engine, might lower the average due to less drag losses.

And this is precisely what needs accurate calculation: we need to know, empirically and numerically, whether the difference in the average for fuel consumption differs sufficiently to make a real difference to what players have an incentive to do in enough different situations that are realistically likely to arise to make the enormous extra complexity of dynamic calculation of fuel consumption and consequent delay of many months or even years in the code being balance ready worthwhile.

[Vladki]

I'd like to confirm, that the current code in simutrans for air friction uses only the first vehicles values.

And I must confess personally, that standing at a platform 1-2 m from the edge while a fast (160 km/h) train is passing by is not a good idea. However I spoke to a guy who works near the tracks, and said that there is huge difference in the blow between non-streamlined engines (boxy shape), and streamlined (pendolino and similar). But the biggest blow was from the engine, the rest of the train made much less turbulence.

[DrSuperGood]

And I must confess personally, that standing at a platform 1-2 m from the edge while a fast (160 km/h) train is passing by is not a good idea. However I spoke to a guy who works near the tracks, and said that there is huge difference in the blow between non-streamlined engines (boxy shape), and streamlined (pendolino and similar). But the biggest blow was from the engine, the rest of the train made much less turbulence.

This is because the front shape causes most of the air displacement and hence most of the drag. The rest of the train is directly behind the front of the train so rides in the displacement it made so produces little drag.

That said train length does increase drag in the form of turbulance between coaches and surface friction of the sides of the coaches rubbing the air. This is most noticable with long mixed freight trains where the height of the freight coaches might vary such that the displacement fades away between them. Yes there are real life energy savings to be had by correctly ordering your freight so that similar height coaches are next to each other and ordering them from tallest in the front to shortest in the back.

Drag forces occur at every speed. Even at low speeds one can still have savings by reducing the drag coefficient. Just at very low speeds the power required is so low it can be considered trivial compared to other losses. For example a human has a drag coefficient of around 2, making us not much more aerodynamic than a box. However at common walking speeds of 5 km/h with the small front cross section of a human the result is minimal drag loss, so small one will not even notice it. However start to ski or cycle around and these drag losses are huge, so large that professional athletes have to adopt special poses and wear special clothing to reduce their drag coefficient. Let us not even talk about swimming and how bad the human body is at doing it due to this...

44.8km/h is not slow. The same shape moving at 89.6km/h would have 4 times the drag force and at 179.2km/h 16 times the drag force. I know that at 179.2km/h drag is a huge problem for steam engines, hence one can expect it to be 1/16 less of a problem at 44.8km/h.

[jamespetts]

It would be ideal if we could simulate non-frontal drag; but this is taking us rather a long way from the real issue of this topic, viz. precisely what features are actually necessary for balancing. As to drag generally, I know that Bernd Gabriel did use realistic values for drag (he had initially used too high a value to get realistic acceleration, which caused problems with light, low powered vehicles; we then realised that he had not accounted for transmission losses, so we used the "gear" values to account for these in all but steam engines where power is measured at the drawbar in any event, and then reverted to the realistic drag coefficient values, which we use now); but also that, at lower speeds, drag is relatively trivial. A cyclist will experience significant air drag at 32km/h, but a tram (for example) will have, proportionate to its power and other resistive forces, only relatively minor air drag at the same speed. When the drag coefficient was initially set too high in order to compensate for failing to take account of transmission losses, it was the low powered, light vehicles where this caused problems by making them too slow. A small proportion (the side drag) of a relatively minor part of the overall physics (the air drag) is not likley to make a major difference to the overall balance, certainly not enough to warrant delaying balancing until this can be done or changing what other balancing features are added just to take account of this.

Dr. Supergood - have you completed the aircraft analysis to which you referred above? It will be very interesting to see this, and, in particular, not just the loaded vs. unloaded calculations, but rather the static averaged vs. dynamic fuel consumption calculations. I will in the meantime see if I can find any historical sources on practical variance in fuel consumption, although what I have seen so far has strongly tended to be averaged fuel consumption for rail vehicles in particular (see the "snippet of relative pricing information" thread for the details of this that I have digested from various sources).

[jamespetts]

Some more thoughts of a miscellaneous nature. Firstly, average speeds: in this post, I set out average fuel consumption for some 19th century steam locomotives and calculated that, for the LNWR Precedent class, the average speed would have to be in the region of 54km/h to match the calculated/extrapolated fuel consumption/power/thermal efficiency figures.
Looking at actual average speeds for trains in game: in a saved game from 1860 (from the Bridgewater-Brunel server), average speeds for passenger trains ranged from 35-58km/h, with most in the 40-50km/h range. Only Dr. Supergood's express trains with the LNWR "extra large bloomer" locomotives exceeded an average of ~52km/h.

By 1904 (the current date for the server game), train average speeds have increased, but not by a great deal: now, they are mostly between 50-60km/h, with extremes at 25km/h for urban rail and 67km/h for express trains (e.g. Bay Transport's Northern Frontier Express).




Looking at the "Snippet of relative pricing information" thread, the following posts deal with historical sources showing fuel consumption using either average speeds or giving a simple per kilometre/mile figure without indicating the speed:

https://forum.simutrans.com/index.php/topic,6521.msg85675.html#msg85675
https://forum.simutrans.com/index.php/topic,6521.msg98733.html#msg98733
https://forum.simutrans.com/index.php/topic,6521.msg129252.html#msg129252
https://forum.simutrans.com/index.php/topic,6521.msg147771.html#msg147771
https://forum.simutrans.com/index.php/topic,6521.msg157715.html#msg157715
https://forum.simutrans.com/index.php/topic,6521.msg157721.html#msg157721
https://forum.simutrans.com/index.php/topic,6521.msg140571.html#msg140571
https://forum.simutrans.com/index.php/topic,6521.msg160790.html#msg160790
https://forum.simutrans.com/index.php/topic,6521.msg166768.html#msg166768
https://forum.simutrans.com/index.php/topic,6521.msg169046.html#msg169046

The following posts give some indication of the fuel consumption per unit of power (but this might simply be extrapolated from coal usage at an average speed)
https://forum.simutrans.com/index.php/topic,6521.msg85675.html#msg85675
https://forum.simutrans.com/index.php/topic,6521.msg113258.html#msg113258
The following posts give some indication of dynamic fuel consumption
https://forum.simutrans.com/index.php/topic,6521.msg151288.html#msg151288 (aircraft)

(Incidentally, this post gives at least one source for the amount of coal burnt per square foot of firegrate per hour on a steam locomotive).

Thus, there is far more information available regarding averaged fuel consumption than dynamic fuel consumption. Using a dynamic fuel consumption model therefore requires a known accurate means of extrapolating from the static, averaged figures that we have which is also sufficiently simple to implement to be workable.


In relation to implementation of a dynamic system, if this should prove necessary, one possible way of doing this is to assume that a vehicle is using its full power and thus maximum fuel consumption whenever it is accelerating or travelling at a speed limited by its power, and calculate a percentage of currently used power (and therefore fuel) when it is travelling at a speed limited by something other than its power (the convoy's or the way's speed limit, signals, etc.). This percentage could be displayed simply to the player and the player could therefore easily understand how much power is being used.
However, there are some serious issues that need to be considered before even this scheme can be implemented (if indeed it can). Firstly, there is the question of how to calculate this. I have no idea what the formula should be, save that increasing power increases with the square of increasing speed. The physics engine is quite computationally intensive because it uses a fixed point system implemented using integral values (because floating point precision cannot be kept in snyc over a network with clients compiled for different platforms). Any per-step calculation involving square roots for all vehicles might significantly harm performance.
Secondly, there is the question of how to get the data for the maximum fuel consumption. As above, almost all the data are for average fuel consumption. There are some data for aircraft's maximum fuel consumption, but road, rail and water vehicles have no equivalent data.

Thirdly, there is the vexed question about what to do about deceleration and idling. If we are modelling actual, dynamic fuel consumption, we have to assume a minimum fuel consumption for when the vehicle is decelerating; but this also requires one to assume that this minimum fuel consumption is maintained when the vehicle is, e.g., stuck behind a signal or in a traffic jam. This is not consistent with the existing per km cost system and so would require further complexity, possibly removing fuel from the per km cost system entirely and making fuel consumption time based - but this would then be far, far more complex to implement (and also harder to explain to the player). This would also make it even harder to get good fuel consumption figures against which to calibrate it, especially for internal combustion engine vehicles whose economy is typically measured in miles per gallon or litres per kilometre.


In any event, I shall look forward in due course to Dr. Suergood's aircraft calculations and any calculations showing whether there is a serious balance difference between static and dynamic calculation of fuel consumption.

[ACarlotti]

It seems to me that the example I gave in this post (with the added proviso that all four trains travel at the same speed for most of their journey) is sufficient to demonstrate a need to charge for fuel consumption (or some equivalent measure).

This could perhaps be as simple as adding a running cost to powered vehicles which is charged proportional to the motive power they apply, although I think it would be more sensible to introduce some of the following sets of variables (many existing variable included for completeness):
Fixed:

• Monthly Running cost
• Distance Running cost
• Weight

And per fuel type (could also be specified once for all types for compatibility):

• Maximum power
• Maximum force
• Minimum power (could be negative for regenerative braking back to grid, or positive to represent an idling engine while decelerating)
• Fuel cost (per unit of energy)

A separate proposal I think I made elsewhere:

• Energy buffer capacity (e.g. for battery-fuel hybrids, or to simulate steam locomotives building up energy before a hill, or horses being capable of working harder to climb a short hill
• Buffer max charge rate

[li]Buffer max power output
[/li][/list]

Fuel weight: Modelling this precisely would probably require a refuelling system to be implemented, but I don't think this is necessary. Even for aircraft, where almost half the gross weight can be fuel on long-haul flights, the extra weight doesn't seem to affect fuel consumption much, based upon this graph for a 777.  Furthermore, I think a realistic refuelling system is incompatible with Simutrans, since most transit vehicles refuel only overnight, or sometimes off-peak, whereas Simutrans has no concept or day/night or peak/off-peak. That's not to say that fuel capacity is unimportant, but it can be mostly simulated using the existing range feature (or perhaps planned maintenance features for something like horses requiring an overnight rest). This does ignore some subtleties such as aircraft having a greater range with a smaller payload, but I don't see any reason to implement that as a feature. This is related to the lack of stabling sidings/depots in Simutrans.

All of the above features, along with an increase in the number of electrification types, are sufficiently interlinked that they should probably all be at least accommodated, if not implemented, in a future modification/reworking of the physics system. They all seem computationally feasible to me (with the probable exception of fuel weight and refuelling); the main issue (as with all things) is having time to develop them.

[DrSuperGood]

I have no idea what the formula should be, save that increasing power increases with the square of increasing speed.

Power increases by the cube of increasing speed as covered by the drag formula. This is because the drag force increases by the square of speed but work is force times distance and power is work over time and speed is distance over time. Hence power to overcome drag increases by the cube of speed.

This is why reducing speed even a small amount for both ships and trains can have significant energy savings. This applies to ships especially due to the higher density of water than air so their hulls in the water produce a lot of drag at anything but the lowest speed (why ships are so slow in general and why hovercrafts are so fast).

Even for aircraft, where almost half the gross weight can be fuel on long-haul flights, the extra weight doesn't seem to affect fuel consumption much, based upon this graph for a 777.

In retrospect I agree. Averaged statistics are probably fine for aircraft. At most a landing/takeoff charge could be added to make short distance flights more or less economical with some types of aircraft to achieve a similar graph shape with averaged values.

[jamespetts]

Thank you for your thoughts. I can only reply briefly now as I am in a train, but one very significant thing that must be considered is that fuel economy is not constant for any given engine but rather varies with speed and load. A high power engine running at a low load will be less efficient than a high power engine running at a high load or a low power engine running at a low load.

See here for discussion: https://physics.stackexchange.com/questions/195479/engine-fuel-consumption-vs-power

This makes it much harder to produce a satisfactory formula for this,as one cannot simply calculate a single jule per watt figure for each vehicle.

[jamespetts]

To add to the previous post in a little more detail: given that fuel economy per unit of power output is not consistent at different levels of power output, the only way in which a dynamic system for calculating the contribution of fuel consumption to running costs is likely to be more realistic than a static averaged system (the latter of which would use data from sources that would already have taken into account by averaging the vehicle's differing fuel efficiency at differing levels of power output) is: (1) to have data about the relationship between fuel efficiency, current power output and maximum power output for different sorts of vehicles; (2) develop an algorithm to simulate this relationship which is accurate enough to make the overall fuel consumption significantly more accurate than for a static averaged calculation but fast enough not significantly adversely to affect game performance; and (3) find a clear, simple and precise way of communicating this relationship to the player using the UI.

At present, I do not have any idea as to where even to begin on any of these three things. For (1), which is where one would have to start, one would need to have, at the very least, multiple data points for each of the following types of engine: (1) reciprocating steam engines; (2) reciprocating internal combustion engines; (3) jet engines; and (4) electric motors. Each of those data points would, in turn, comprise a multi-point graph showing the relationship between power output and fuel efficiency at any given level of power output. I am afraid that I have no idea where one can find such data. Does anyone else have any ideas for where such data might be obtained?

The non-constant relationship between fuel efficiency and power output is potentially significant in other ways, too. Given that it appears that the way in which this relationship is non-constant is that (as one might expect) engines with a high maximum power output are considerably less efficient when being used at a low level of power output than engines with a low maximum power output (at least for internal combustion engines and probably also steam engines - it is not clear whether and if so to what extent his applies to electric motors), a static, averaged system is likely to be less wrong than it would be if this relationship were constant. Importantly, an algorithm that assumes a constant relationship would not give players any incentive to use lower powered vehicles where the higher degree of power is not necessary, whereas both the dynamic system with the dynamic efficiency to power ratio and the static averaged system would give players such an incentive. This is of particular importance, since, without such an incentive, vehicle choice becomes far less meaningful, and whole swathes of lower powered vehicles become more or less useless, which is the exact opposite of the purpose of Simutrans-Extended. Thus, for practical purposes, a dynamic system that assumes a static relationship between power output relative to the maximum and fuel efficiency is likely to be more wrong than a static averaged system. Only a double dynamic system (one that both changes both fuel consumption and fuel efficiency with power output) is likely to be better than a static averaged system.

The bottom line seems to be this: unless there are people able and willing to assist with both data and algorithm, I do not think that a dynamic model is feasible, as an overly simplistic dynamic model is likely to be worse than a static model, and one that is not overly simplistic is likely to be very, very complex indeed and require extensive research data which are very hard to obtain. Is anyone in a position to assist with this?

[DrSuperGood]

There are different tiers simulation to consider. At present I would say using averaged efficiency with dynamic power. This would still mean that moving an empty freight train or a train with few coaches saves over a full freight train or one with many coaches. Like wise lower speeds would give savings due to less drag than higher speeds. It would also remain simple enough to calculate in real time I hope because the maths involved for energy efficiency with speed often become quite complex and use non trivial functions. There may be cases where running very slowly is too economical as a result, however one must remember that a competitor just has to run slightly faster and the line loses all business so in practice I do not see it being abused that much out of desperate or miser people. Running fast will never be too economical due to drag, even if in real life the engine is more efficient than it should be at those speeds.

[jamespetts]

There are different tiers simulation to consider. At present I would say using averaged efficiency with dynamic power. This would still mean that moving an empty freight train or a train with few coaches saves over a full freight train or one with many coaches. Like wise lower speeds would give savings due to less drag than higher speeds. It would also remain simple enough to calculate in real time I hope because the maths involved for energy efficiency with speed often become quite complex and use non trivial functions. There may be cases where running very slowly is too economical as a result, however one must remember that a competitor just has to run slightly faster and the line loses all business so in practice I do not see it being abused that much out of desperate or miser people. Running fast will never be too economical due to drag, even if in real life the engine is more efficient than it should be at those speeds.

As explained in the previous post, single dynamic fuel consumption is likely to produce a worse (or, at best, equally bad) degree of realism than static averaged fuel consumption in terms of what players actually have an incentive to do. For the reasons already given, only double dynamic fuel consumption is likely to give any improvement in realism (so far as player incentives are concerned, which is the important thing to consider) over static averaged fuel consumption.

[ACarlotti]

Have you taken into account that higher monthly or distance-based maintenance (/staffing) costs, higher weight and higher rolling resistance will also tend to penalise using an overpowered vehicle?

[jamespetts]

I doubt that a higher powered vehicle would need more staff than a lower powered vehicle: a steam engine of any size still needs just one driver and one fireman; a huge articulated lorry needs the same number of drivers as a van; a large double decker 'bus needs the same number of drivers as a small single decker 'bus (there were some differences with very small minibuses which could be driven by people with van licences at one point, but that does not scale with power). Higher weight may be significant in some cases, but may well not be particularly significant in others (and weight will certainly not scale in a linear fashion with power in any event), and of course, a higher powered vehicle would almost always have a better power to weight ratio than a lower powered vehicle or else it would be of no use at all compared to the lower powered vehicle. Aside from higher weight, it is not clear why more powerful vehicles are likely to have higher rolling resistance.

The only real co-acting incentives against using higher powered vehicles where lower powered vehicles would suffice are weight and capital cost (and the latter more importantly than the former); but I am doubtful that these will produce the same incentive patterns in practice as a system involving more accurate fuel efficiency.

It really does not seem likely that a singly dynamic fuel consumption system will be any more accurate than a static averaged system (although of course we have not tested this empirically; but I am not sure that we have the data with which to do so at this stage; does anyone have any data with which this can be tested? The trouble is, of course, that the very data necessary for this testing are the same data as we would need to implement the doubly dynamic system in the first place).

[DrSuperGood]

a steam engine of any size still needs just one driver and one fireman

The late stage steam engines I thought required at least 2 firemen at any given time, with express services like the Mallard requiring replacement firemen on standby (4-6 firemen in teams of 2 swapped out using a corrodor tender). This is because a fireman can only shovel so much coal per hour for so long. Now if the standby firemen should be getting paid when not shovelling coal is another question.

Replacement firemen were also parked at stops along the way for some stopping express services. As such even if only 1-2 firemen were on the locomotive at any given time, one might still need many more employed to man the engine with them being swapped out at stops.

Obviously staff management and swapping is an extremely complex system. As such having averages might be better. For sure more powerful steam locomotives would average more staff to run.

a higher powered vehicle would almost always have a better power to weight ratio than a lower powered vehicle or else it would be of no use at all compared to the lower powered vehicle

Not true at all. Power to weight ratio has to do with performance, a metric only cared about when speed is critical such as motor racing or express services. What drives the use of large vehicles is efficiency, the cost per ton per km hauled.

Aside from higher weight, it is not clear why more powerful vehicles are likely to have higher rolling resistance.

Depends on type of vehicle. In the case of road vehicles the rolling resistance is not linear with weight as more weight causes the tires to deform more and hence generate more rolling resistance when moving along the road than stiff wheels like rails will.

Mostly larger vehicles are more efficient from a drag loss point of view. This is why it is a lot more economical to move long coal trains rather than short coal trains even though rolling resistance loses are less with short coal trains. Exception is with aircraft where on top of normal drag losses they are also subject to parasitic drag to generate lift force, in which case weight efficiency is a major design consideration.

[jamespetts]

The late stage steam engines I thought required at least 2 firemen at any given time, with express services like the Mallard requiring replacement firemen on standby (4-6 firemen in teams of 2 swapped out using a corrodor tender). This is because a fireman can only shovel so much coal per hour for so long. Now if the standby firemen should be getting paid when not shovelling coal is another question.

Only two classes of locomotives, both on the same railway (the LNER) were ever fitted with corridor tenders: the A3 and A4 class. Those locomotives hauled very long distance expresses between London and Edinburgh, some of them with few or no stops. The journey would take in excess of a working day, and therefore both driver and fireman would be changed using the corridor tender. No other railway in the UK ever used corridor tenders.

Replacement firemen were also parked at stops along the way for some stopping express services. As such even if only 1-2 firemen were on the locomotive at any given time, one might still need many more employed to man the engine with them being swapped out at stops. Obviously staff management and swapping is an extremely complex system. As such having averages might be better. For sure more powerful steam locomotives would average more staff to run.

I am not aware of any situation in which, in the UK, the fireman was changed when the driver was not changed. Do you have any sources for this? (Changing both crew was fairly common on longer runs, of course).

Not true at all. Power to weight ratio has to do with performance, a metric only cared about when speed is critical such as motor racing or express services. What drives the use of large vehicles is efficiency, the cost per ton per km hauled.

Do you have any significant examples of where the power to weight ratio declined with increasing power for land vehicles?

Depends on type of vehicle. In the case of road vehicles the rolling resistance is not linear with weight as more weight causes the tires to deform more and hence generate more rolling resistance when moving along the road than stiff wheels like rails will.

Surely heavier road vehicles would just have higher pressure tyres?



The idea of dynamic fuel consumption requires very great complexity and additional time. In order to make the degree of sacrifices necessary to implement this, I need to have a high degree of confidence that this will be significantly better than a static averaged system in terms of how the game plays in practice (i.e., player incentives in non-edge cases). It is not at all clear at present (and, indeed, it seems from what I have found so far unlikely) that this will be the case unless the fuel efficiency be dynamic as well as the fuel consumption.

This source gives some indication of the relationship between load and power consumption for internal combustion engined road vehicles; I have great doubt that we will find anything for steam engines, although I suspect that the graph is most similar to the diesel engines given, as the fire would have to be "forced" to produce maximum power output, resulting in much unburnt material being ejected through the chimney. I do not know the position for electric motors. Information on the relationship for electric motors can be found here. If anyone can come up with a workable algorithm to use the information in this graph in a way that interacts with the variables that we already have in the Simutrans engine, that would be most useful.

As I think that I have indicated above, the only way that I can think of making dynamic fuel consumption workable is by making fuel consumption time based rather than distance based, as we then have to take into account idle loads. We would then have to take account of the fact that some engines can be switched off in some cases of sufficiently long stops (giving a zero idle load), and that others cannot. We would also have to take into account the fact that for some vehicles (such as horses), their food consumption would not vary much with load (perhaps that could be simulated with a very high idle load - an animal's resting metabolic activity is far greater than the difference between resting and exercising metabolic activity). We would then have to come up with a way of converting miles per gallon and equivalent distance based fuel consumption data into time based data. We can probably do this for aircraft without much difficulty as we have hourly fuel flow figures for many aircraft, and we can do this for steam engines as we have hourly coal burn statistics already, but I do not know how we could do this for road vehicles.

If anyone can think of a means of overcoming all of these challenges, I should be very grateful to know.

Edit: I think that I have mentioned this briefly above, it it is worth making clear here: if we do not get the dynamic relationship between power output and efficiency right, then the average fuel consumption actually experienced by players in the game is likely to be significantly wrong. A static, averaged system will already have taken the dynamic relationship between power output and energy efficiency into account in giving the averages. Thus, this is another reason that the only real options are either double dynamic energy costs or static, averaged energy costs.

[jamespetts]

The time to resume work on the vehicle maintenance features is now approaching, but it is necessary to reach a final resolution on this issue before it does.

So far as I can discern from the discussion so far, the position is that, whilst fully dynamic fuel consumption would be ideal, if not done properly so that the fuel efficiency as well as fuel consumption varies with power output, this could easily be no better than, or even worse than, a static averaged system for fuel cost as was originally planned.

Given the very great amount of additional work likely to be involved in dynamic fuel cost calculation, it is necessary to have a high degree of confidence that such a system would (1) be workable; and (2) be preferable in the form implemented to a static averaged system. This would mean (1) devising a workable algorithm to vary not just fuel cost but also fuel efficiency with power output; and (2) finding enough data for relevant types of vehicles to enable the actual in-game figures to be based on real life data, or extrapolations or interpolations there-from.

At present, I do not believe that it is possible to implement a workable dynamic system within current known constraints, as I do not know anywhere where I could find what a suitable formula could be or find enough data.

If anyone would like to propose a workable scheme, I should be grateful if this could be done, at least in outline, soon (preferably within the next week or so), or else I will have to continue as originally planned with a static averaged system.

Thank you all for your input on this idea so far - it is appreciated.

[DrSuperGood]

To a large extent vehicle maintenance should not heavily couple with fuel economy. For now simply implementing vehicle maintenance would solve some of the above mentioned problems with accurate vehicle life costs.

Accurate fuel and running costs can be visited at a later time. Unfortunately it is the sort of feature that may require some experimentation and testing before results are satisfactory.

Although the mathematics involved are quite simple, and could potentially be estimated and still good enough, the problem is getting actual realistic data. Drag was a huge problem with steam engines but no one has shoved one in a wind tunnel because the importance of drag is a very modern concept, post dating the fall of wide spread steam usage. Aircraft do have fuel efficiency variances based on distance and loaded weight but these seem to be quite small so might be worth averaging away. Ships do have variances in fuel efficiency based on their speed they travel at, however how much of a variance is probably unknown for early steam ships, especially since they were hybrid sailing ships and in real life arriving on time often out does the difference in fuel economy.

There are different tiers of system that could be implemented, possibly individually. It may be found that some are sufficient that others could be ignored. In any case at some stage they will have to be looked at since averaging just will not work due to allowing players to exploit extreme cases that abuse the averaging or exposing them other extremes that unfairly punish them.

Ultimately at least the following needs to be looked into and modelled in some form or another.

• Aero/hydrodynamics and the ability to limit maximum speed. Slower means lower drag which means some savings. This would mostly apply to ships and early trains, with others possibly able to use averages instead. Most of the energy cost of ships is due to this.
• Acceleration and deceleration costs. Accelerating heavy vehicles uses a lot of energy which ultimately is wasted when breaking. This would mostly apply to trains and road vehicles as they are considerable masses that may be subject to regular acceleration and deceleration, especially within inefficient networks. Most of the energy cost on some underground networks with short distance stops is likely due to this. This can be ignored with ships because ships have very low top speeds and generally travel long distances without stopping and often take advantage of coasting so averages would suffice.

The following features probably do not need to be investigated and instead could be modelled by averaging or other easy to implement mechanics.

• Dynamic maximum range of vehicles. Technically maximum range varies with speed, weight and the amount of breaking performed. However simulating fuel would likely annoy players and becomes hugely complicated.
• Fuel efficiency of aircraft. Although the data will be available somewhere due to how much money is involved with aircraft and air transport being a recent invention, the gains from it are likely minimal over using averaging. For ranges that an aircraft would have extremely poor economy in real life (huge aircraft short distance) one could apply a minimum permitted flight distance or a constant takeoff/landing charge.

[jamespetts]

Thank you for your thoughts.

You write that a static averaged model "just will not work": can you elaborate on this? Are there any non-edge cases in which significant anomalies in what players are incentivised to do are likely in a static averaged model compared with a model that is dynamic both as to fuel consumption and fuel efficiency?

As written, the difficulty is: (1) a single dynamic model (i.e., one in which fuel consumption changes with power output but fuel efficiency does not) is likely to lead to worse fidelity to real values than a static averaged system; and (2), while a double dynamic model (i.e. one in which both fuel consumption and fuel efficiency changes with power output) is likely if implemented properly to lead to the highest fidelity of fuel consupmtion, this is likely to be too difficult to implement for three reasons: (a) the inherent complexity of finding a workable algorithm; (b) the computational intensity on large maps; and, most importantly of all, (c) the inability to find enough data with which to calibrate this. Without overcoming each of these three difficulties, I cannot see any possibility of attempting to implement a dynamic system being anything other than worse than a static averaged system.

The purpose of my last post was to state this conclusion and invite suggestions as to how those three problems might be overcome. If they cannot be overcome, then a static averaged system is the only practical option.

I should note, however, that fuel consumption for some types of vehicles (e.g. steam trains) is a relatively small part of the overall running cost (Ahrons estimated it around 12% in the 1850s), so a slight lack of fidelity in fuel consumption is unlikely to lead to any significant alteration in player incentives in any event.

(To put this discussion in context: the planned vehicle maintenance features include splitting maintenance/repair costs and fuel consumption for vehicles, having both based on real life data in so far as they can be found, and having different rates of inflation apply to both during the course of the game, the fuel consumption figure being based on historical fuel costs and the maintenance figure being based on historical staff costs/wage levels).

[ACarlotti]

the difficulty is: (1) a single dynamic model (i.e., one in which fuel consumption changes with power output but fuel efficiency does not) is likely to lead to worse fidelity to real values than a static averaged system;

I don't believe this can be true. If the dynamic model is used in the code, then it would still be possible to use the current static costs by setting all the dynamic (i.e. new) costs to zero. We are not throwing away the existing cost mechanisms, merely adding new ones that can be used in parallel. If there are any cases where a completely static model truly is better than the simple dynamic model, then we can continue effectively using that.

This get-out might not work for trains, but I think trains are where the simple dynamic system will give the greatest improvements over the static system. Indeed, I don't think you have responded to my scenario in reply #34 (cost savings due to switching to a more efficient locomotive should be greater for longer/heavier train).

I think the best way forward is to modify the code to allow for dynamic running costs, and then try them out. If it does turn out to give worse operational costs, then we can revert to the current model without any further changes to the code (perhaps even leaving dynamic costs as an option for other paksets).

[jamespetts]

Thank you for your thoughts.

I don't believe this can be true. If the dynamic model is used in the code, then it would still be possible to use the current static costs by setting all the dynamic (i.e. new) costs to zero. We are not throwing away the existing cost mechanisms, merely adding new ones that can be used in parallel.

It is a little more complex than that: the current code does not distinguish between maintenance cost and fuel costs. The plan is to have maintenance costs and fuel costs separated and then governed by different rates of inflation; so the code needs to be updated in any event.

What I was referring to in the passage quoted was not so much the need to replace parts of the code, but rather the fact that, without modelling both dynamic fuel consumption and dynamic fuel efficiency, modelling dynamic fuel consumption alone is likely to lead at least in many significant cases to less accurate average fuel consumption than simply modelling average fuel efficiency. There are some particular problems with this: firstly, it is fairly easy to find averaged fuel consumption data for a range of vehicles, but very difficult to find such data in a way that correlates these data with power output.

Secondly, there is a particularly important aspect to dynamic fuel efficiency which in reality has a very significant impact on vehicle selection, which is this: a high power output vehicle will tend to be much less efficient at lower power outputs than a low power output vehicle. Not simulating this fact may well render useless a large range of low power output vehicles that are useful in reality precisely because they have better fuel efficiencies at their intended, lower power outputs. One of the things that I am especially keen to avoid is the situation that exists with Standard in which players have an incentive always to use the most powerful vehicle for everything. If there is no cost to using an overpowered vehicle, it would be difficult to avoid this. Even peripheral means of incentivising the use of lower powered vehicles (higher capital cost and weight) are likely to be insufficient in a significant number of cases, particularly with rail vehicles where these factors are likely to be less significant in many cases. In reality, there was a reason that huge heavy freight engines were not also used for suburban passenger work.

If there are any cases where a completely static model truly is better than the simple dynamic model, then we can continue effectively using that.

There are two problems with using a case by case approach to determine when it is better to use a static rather than dynamic fuel consumption system: firstly, it is likely to be difficult to work out which vehicles fall in which cases, and secondly, it is likely to be very confusing for players for fuel consumption to vary with power output in some, but not all, cases. The first problem in this case exacerbates the second.

This get-out might not work for trains, but I think trains are where the simple dynamic system will give the greatest improvements over the static system. Indeed, I don't think you have responded to my scenario in reply #34 (cost savings due to switching to a more efficient locomotive should be greater for longer/heavier train).

My apologies for not having dealt fully with this earlier. For ease of reference, I quote the relevant parts below.

I think it is currently impossible to produce accurate (or close to accurate) running costs for all four combinations of:
1. A diesel locomotive with high energy costs
2. An electric locomotive with low energy costs
and:
a. A short train of (say) 2 coal wagons
b. A long train of (say) 20 coal wagons

Clearly replacing 1b with 2b should lead to a greater reduction in running costs than replacing 1a with 2a, but at present these two replacements cannot produce different reductions in costs.

So this suggests that some account of actual energy consumption is needed in the long run.

The comparison is valid, but the real question is whether a dynamic system can be implemented in which the overall adverse effects of implementing it  are less than the sub-optimal state of the improvement in energy costs of upgrading from diesel to electric in the above example being less differentiated than they would be in reality.
The biggest problem is the lack of effective data available as to dynamic fuel consumption and its relationship with power output; if, for example, a particular 'bus is recorded as having an average fuel efficiency of 4 miles per gallon, how can that datum be used to calibrate a dynamic system? As somebody who needs to be able to balance the pakset, I have to have a reliable way of extrapolating from fragments of real life data, and I see no way of doing that with the available data for a dynamic system.

The second biggest problem with a single dynamic system is that described above as to the perverse and unrealistic incentives created by having non-dynamic fuel efficiency. In practical terms, those adverse effects would appear to create incentives that deviate more significantly from reality than the incentives created by there being insufficient difference between energy cost savings of high and low power output situations.

I think the best way forward is to modify the code to allow for dynamic running costs, and then try them out. If it does turn out to give worse operational costs, then we can revert to the current model without any further changes to the code (perhaps even leaving dynamic costs as an option for other paksets).

The trouble with this approach is that that modification to the code would take a truly gargantuan amount of work (the physics engine is fantastically complex and I did not write it, so I have little understanding of how it works), so there has to be a very, very high chance that this will be very significantly better than a static averaged system to justify doing this work. I would also need to be very confident that it would be possible to get sufficient real life data to calibrate a dynamic system at least as well as a static system could be calibrated before coding for this.

What I had suggested in a post some time ago was dry run testing - mathematical extrapolation of various cases without modifying the code to test in principle whether either of the three theoretically possible systems, being (1) static averaged; (2) single dynamic; and (3) double dynamic would be viable.

As stated,  unless we can actually find a way of overcoming the three obstacles to a dynamic system, being
(1) the difficulty in creating a workable algorithm for a double dynamic system, or alternatively, the perverse incentives generated by a single dynamic system;
(2) the possibly excessive computational load of having to calculate fuel consumption dynamically; and
(3) (probably the most problematic of all) the lack of data enabling a dynamic system to be calibrated,
the only sensible way forward that I can see is to implement the static averaged system.

Edit: Incidentally, an additional thought in relation to the issue raised in post no. 34: in most cases, a player hauling a small load would be more likely to choose a low powered locomotive over a high powered locomotive capable of hauling a large load. Thus, in the situation where the player is using locomotives with different maximum power outputs in each pair of the four cases given, the fuel cost saved by the player will be greater in moving from the high powered diesel locomotive to the high powered electric locomotive than from the low powered diesel locomotive to the low powered electric locomotive.

[ACarlotti]

You raise many good points; I should also try to remember that you have experience of developing a pakset that I do not. If it should turn out that static averaging isn't sufficient, then I could at some future point try implementing a dynamic system. But at the moment I have enough other things to do that I wouldn't want balancing to wait for me to have time to rework the physics engine.

[jamespetts]

Thank you again for your thoughts on this. One of the important considerations is to work within the resource limits that we have available in terms of data and time, which can make a significant difference to what the optimum solution is.

One thing that might be worth bearing in mind for future reference is that it is likely that any good dynamic system for fuel consumption would have to change fuel consumption completely from a distance based measure (which is most suited to a static averaged system) to a time based measure, which would involve discarding any distance based measure data and starting again, so it would only make sense for anyone to implement such a system if good data for all types of mechanical transport are available for this.

[jamespetts]

I am reviving this rather old topic as I have been looking into steam engine physics calibration again. This issue has been discussed more recently, I think having forgotten about this earlier thread, but I cannot now find the more recent thread: if anyone knows where I might find it, I should be grateful if he/she could let me know so that I can merge the threads.

The more recent discussion was to the effect that, because I could not find any data for the non-linear relationship between power and energy consumption, and a linear relationship would be of no use because it would obliterate the strong incentive that exists in reality not to use overpowered/oversized vehicles for tasks, thus removing nearly all incentive from players to use all but the most powerful vehicles for every possible task, there was no way of implementing such a system.

I think that I have now found some data on this, at least for steam locomotives, here: see the lower graph on page 15 of the .pdf. This is a complex U shaped curve, and there is only one data point for one locomotive. It is thus likely to be difficult to know what the start and end points will be.

If anyone has any sensible ideas about how to model this (and where to obtain more data), that would be most useful.

[jamespetts]

I have found the more recent topic and merged it.

I note that, even if I have data for steam locomotive fuel efficiency with workload, I will still need data for internal combustion engines on road, rail, air and water as well as electric motors to be able to do anything with this.

[DrSuperGood]

thus removing nearly all incentive from players to use all but the most powerful vehicles for every possible task

Part of this should be purchase and running cost. If one wants an engine to move a few coaches then spending a huge amount on a high speed express engine does not make sense. Like wise such complex high power engines cost more to maintain and may need more full time staff to operate.

The other part should come from the natural property that the larger more powerful locomotives waste more energy accelerating themselves and dealing with their own rolling resistance. This is part of the efficiency on top of the conversion efficiency curves.

[Phystam]

For resistance:
According to physics, running resistance consists of 3 terms as follows:
R= C + D*v + E*v^2,
where C is rolling, D is viscous, E is inertial resistance.
Currently, the parameters C and E are implemented. Generally speaking, the low-speed area and high-speed area is good approximations, but the mid-speed area is not.
D term is very important for the mid-speed area, so I think that we have to implement it first.

[Qayyum]

For steam engines, would boiler pressure be a good measure to calculate how much force a locomotive with a set number of carriages can take, assuming the gradient is zero degrees?

[DrSuperGood]

For steam engines, would boiler pressure be a good measure to calculate how much force a locomotive with a set number of carriages can take, assuming the gradient is zero degrees?

Boiler pressure along with piston area and an efficiency constant directly determines the maximum output force at low speeds, assuming the locomotive was engineered properly to have sufficient weight on its driving wheels. At high speeds steam engines are power limited, which is based on grate size and other characteristics of the firebox to water heat exchanger. The remaining force for acceleration is whatever is left after gradient, drag and rolling resistance forces are applied.

[jamespetts]

Thank you all for your replies. I think that I have found a possible workable solution to this issue. The possible solution is in two parts, and further work is required in particular in relation to the second part.


The first part - calibrating for speed

The most fundamental problem is that per km fuel consumption requires a speed to calculate, but that speed can vary enormously from an express passenger train to a slow mineral train. Generally, the higher speed given for calibration, the less units of fuel used per kilometre even if actual power output is the same. Thus, if things were calibrated without taking this into account, players may have perverse incentives to use vehicles designed for higher speeds because they would appear to be more fuel efficient even though, in reality, a lower speed vehicle would be more efficient and suitable for the task in question.

The solution requires understanding how I have calculated power and efficiency for steam locomotives in the pakset (the efficiency calculations are not yet used in the game, but will be when the appropriate features are added; however, the range feature already exists, and if I were to use range, efficiency would be necessary). What I have done is, for a sample of the locomotives that are in Pak128.Britian-Ex, obtained data as to their top speed with a given load, corrected for the effect of any gradient prevailing at the time that the top speed was obtained, and then worked out what level of power would be necessary for that locomotive to haul that load in-game on the flat using the game engine itself (by adjusting the power multiplier percentage), and then set the power to that amount.

I then calculate the efficiency for the locomotive by taking the firegrate area, the calorific value of the coal or coke that the railway that used it was likely to have used, a figure for the amount of fuel burnt per area of firegrate per hour, and combining those in a formula to get a figure for the overall thermal efficiency of the locomotive (i.e. the amount of chemical energy in the coal that translates to mechanical energy available for haulage). This tends to be around 4-7%. The spreadsheet in which I do so is here. The yellow rows represent locomotives calibrated for power.

Since yesterday, I have added columns for per kilometre fuel consumption, fuel capacity and range, and have been going back through the list using real life coal consumption figures for the locomotives in question and adding these. I have also added a "calibration speed" column next to the top speed column as the average speed to use when calculating per kilometre fuel consumption. (One of the complexities is that fuel consumption calculations require average speeds whereas power calculations require top speeds with a given load; ideally, one would have figures from the same run - the average and the top speed - with the same load both used to calibrate the fuel consumption, but it is not always possible to get matching data). One of the consequences of this exercise is that I have found that I had under-estimated the fuel consumption for many later steam locomotives, and thus over-estimated their efficiency, which I will have to correct (and have been correcting for some of the locomotives for which I have data). The green cells represent instances where I have real world data for fuel consumption.

To get sensible values for locomotives for which I do not have data, I extrapolate from those for which I do by using the firegrate area and likely calorific value of coal consumed, together with an estimate of the efficiency and fuel consumption rates based on similar locomotives for which I do have data, together with things known about the locomotive in question (e.g. that it was heavy on coal or similar).

The trouble comes when attempting to compare fuel consumption per kilometre between locomotives whose power was measured at different average speeds. To illustrate the problem, suppose we have a locomotive which can reach a top speed of 100km/h with load X. If its fuel consumption is 10kg/h, then its per km fuel consumption would be 10 / 100 = 0.1.

However, suppose that the same locomotive, when hauling a load of Y, can reach only 50km/h. The power output and thus hourly fuel consumption is the same, but it is hauling a heavier load at a lower speed. Its fuel consumption per km would therefore be 10 / 50 = 0.2 - twice as much as when hauling the lighter load at a higher speed.

The solution is to use the mathematics of the above illustration in reverse to back-calculate the per km fuel consumption for any given load by reference to a fixed calibrated load:speed ratio. The game engine can calculate the maximum load at any given speed (I think - I am not sure how easy that it is to get this information from the physics engine, which I did not write - the maximum speed at any given load is given in the depot window). So, if we have per km fuel consumption data that has been calibrated with a load producing a maximum speed of N, and the vehicle is in fact operated with a load producing a maximum speed of P, the actual fuel consumption should be the base fuel consumption multiplied by N and divided by P. So:

nF = (oF * N) / P

where nF is the new fuel consumption and oF is the original (calibrated) fuel consumption. Note that the figure of N must be the maximum speed obtainable with the load in question for any given fuel consumption, not the average speed, even though we also need the average speed to calculate the fuel consumption. Note also that, for these purposes, we need to compare the maximum theoretical speed achievable on the basis of the power and load only, ignoring any speed limit inherent in the vehicle.

Thus, what we need to do is to add a parameter in the .dat files that gives a maximum calibration speed for the fuel consumption, which will then be compared with the data above to give a sensible fuel consumption rate. Where no value be specified (or zero explicitly specified), this will need to result in the disabling of this feature and the use of the base figure (oF) at all levels of loading.


The second part - adjusting for non-maximum power output

The above formula will give sensible figures if we assume that the vehicle in question will be making full use of its power output at all times while in motion. This will be the case when it is accelerating and when it is travelling at the maximum speed allowed by the power and load combination, but will not be the case when decelerating nor when its speed is limited by something other than physics (such as a vehicle or way speed limit).

The case of deceleration is a difficult one, as, if we use start to stop timings to calculate our average speed for the purpose of fuel consumption data, that implicitly includes deceleration, and we must not therefore take deceleration out of account. Ideally, therefore, we would not use start to stop average speeds, but use the highest speed attained during the run as our calibration speed, but these data are not always available. Using the highest speed attained during the run makes sense so long as this is indeed the maximum speed limited by physics. Quite what to do when only averages are available is difficult to consider at this stage.

Edit: On reflection, deceleration is not as much of an issue as it first appears: because vehicles travel more slowly when accelerating than they do when at their maximum speed, the per kilometre fuel consumption, calibrated by the maximum speed, is excessively generous to the player. However, if the same fuel consumption be maintained during deceleration, this should be evened out effectively. Thus, there is no need for any adjustment in relation to deceleration: during deceleration, the fuel consumption should be the same as it was immediately before deceleration, whatever that might be, based on the formula to be described below.

In any event, if we assume that we have available data for the maximum physics limited speed at a given load from which we have calculated a power output, and we use that speed as our calibration speed, then we can detect whether the vehicle is either at that maximum speed or accelerating and, in those cases, consume the full amount of fuel per km calculated by the formula outlined in stage 1. However, where the vehicle is maintaining a speed less than the maximum speed that it is physically capable of reaching with its current load, one can then apply a proportionate reduction in fuel consumption.

The simplest formula would be simply to take the current speed as a proportion of the maximum physical speed and apply that proportion to the fuel consumption so that, if a vehicle is not accelerating nor decelerating and travelling at 50% of its maximum physical speed, its fuel consumption would be 50% of what the stage 1 formula gives us.

However, we know from this source that that is not how efficiency works, for steam locomotives at least; below a certain percentage of load, efficiency reduces considerably, so we cannot simply apply this as a linear proportion.

Interpreting the graphs in that paper (see the lower graph on page 15 in particular) is not easy. We see a U shaped curve for coal consumption as against horsepower output - at the maximum possible power output, efficiency is low because the engine is being "forced", emitting large quantities of unburnt fuel out of the chimney. At very low power outputs, efficiency is low because there is a lower limit to how much coal per unit of time can be burnt on a firegrate of any given size so as to keep the fire going enough to produce any steam at all.

If we use the system described in part I, we simplify reality somewhat by ignoring the possibility of "forcing" a steam locomotive, except for steam locomotives that were so underpowered that they were effectively always forced, in which case, we assume constant forcing. In any event, we assume for these purposes maximum efficiency at maximum power. What we need to extract from that graph is what level of power, in proportion to the approximately maximum power output within the maximum efficiency range, is the minimum level of power before efficiency starts to decline drastically. We can see on the graph that the maximum efficiency range is between approximately 4 and 8 drawbar horsepower per hour (ignore the non-metric units: it does not matter what the units are for this purpose, as we only need a proportion). Higher than 8 and lower than 4 efficiency declines drastically. This suggests that - very approximately - efficiency starts to decline below 50% of maximum (efficient) power output.

Quite how to model this is another matter. The simplest solution would be to impose a minimum limit of 50% on per km fuel consumption (that is, 50% of the figure produced as a result of stage 1). This might be somewhat harsh on players who run things at lower speeds.

Another possibility would be to have a hard limit, but allow this to be set per vehicle in the .dat files - I imagine that electric traction, for example, will scale much better in efficiency at lower power outputs than steam or internal combustion engine traction, whose fires/engines have to be burning/turning over all the time.

Another possibility would be some sort of formula to model a falloff in efficiency, either standardised for all vehicles, differing per type (steam, electric, etc.) or set by a few data points in the .dat files. However, what that formula/those formulae should be and how to calibrate it I currently do not know.

I should note that we currently have something very similar (albeit much more crude) for circling aircraft: their per km cost is halved during the time that they are circling to take account of the fact that they will be using less fuel. This mechanism would be replaced by this if implemented.

At this stage, I am provisionally inclined to go for the cut-off specified in the .dat file with a default of 50% unless anyone has any good ideas for formulae.

Some general issues

One complexity in all this is aircraft. Aircraft data generally show fuel burnt per hour and their maximum cruise speed, but their actual maximum speeds are almost never given and may not be obtainable without damaging the airframe and therefore destroying the aircraft.

Thus, it may be necessary to apply the stage 2 formula even if the stage 1 formula is disabled, as it might have to be for aircraft. Alternatively, one might possibly use a system whereby the fuel consumption calibrated by reference to a proportion of the maximum load rather than the maximum speed, but quite how this would work at this stage I am not sure.

Likewise, I am not sure how one might find suitable data for use for road or water vehicles for this, and this will require consideration.

There is also the issue of range. Currently, range is calculated statically: vehicles simply have a single range specified in their .dat files and that applies at all times. However, where range is based on fuel consumption (as it is for almost all vehicles aside from horse powered vehicles), this presents a problem, as range becomes potentially variable depending on load. In reality, this is of importance for aircraft in particular. However, I am not sure at this stage how best to deal with this: a dynamic range system is potentially difficult to implement and difficult to communicate to players. Any thoughts on this subject would be appreciated.

[Qayyum]

I wish steam locomotives are actually efficient. Nevertheless, here is my version of steam locomotive.

Was thinking of optimal fuel consumption. Optimal speed, optimal force.

[DrSuperGood]

The simplest formula would be simply to take the current speed as a proportion of the maximum physical speed and apply that proportion to the fuel consumption so that, if a vehicle is not accelerating nor decelerating and travelling at 50% of its maximum physical speed, its fuel consumption would be 50% of what the stage 1 formula gives us.

I think at high speeds, traveling at half the speed uses much less than half the power due to how drag works.

One complexity in all this is aircraft. Aircraft data generally show fuel burnt per hour and their maximum cruise speed, but their actual maximum speeds are almost never given and may not be obtainable without damaging the airframe and therefore destroying the aircraft.

One could in theory calculate aircraft per tile cost at time of take off based on their weight and the distance to destination and maintain that for the rest of the flight.

Of course this does not solve the problem of getting the data in the first place.

[jamespetts]

I think at high speeds, traveling at half the speed uses much less than half the power due to how drag works.

Are you able to suggest a workable algorithm to use here?

One could in theory calculate aircraft per tile cost at time of take off based on their weight and the distance to destination and maintain that for the rest of the flight.

Of course this does not solve the problem of getting the data in the first place.

How would calculating it in advance assist?

[DrSuperGood]

Are you able to suggest a workable algorithm to use here?

I do not have suggestions. Just it is something to consider for high speed trains where most of the energy is lost due to drag.

How would calculating it in advance assist?

Aircraft mechanics is very different from other vehicles. Stopping/starting is not really an issue for aircraft since they fly at their cruise speed between destinations and only stop after landing. Aircraft also always fly at their maximum speed, unless they are waiting to land or are taxing on a runway. Using specific calculations for aircraft might avoid the difficulties that trying to have 1 algorithm fit all would have with these situations.

For example aircraft on a journey would have 3 different costs, the cost of taxing, the cost of cruising and the cost of circling. Cost of cruising and circling would vary based on the range of the flight and the weight of the flight.

[Spenk009]

For resistance:
According to physics, running resistance consists of 3 terms as follows:
R= C + D*v + E*v^2,
where C is rolling, D is viscous, E is inertial resistance.

D = .5 * air density * velocity² * drag coefficient * Area
The Class 43 HST at maximum operating speed:
,5 * 1.2 * 55,5² * 1,6 * 7,1 = approx. 21000N
A is W9's 9 ft 0 in (2.74 m) by 8 ft 6 in (2.6 m) simply made to an area
v is 200km/h divided by 3.6 to get u as m/s
(This is Force in Newtons, Phystam's equation is in Power if I've understood it correctly). But as the HST has a continuous output of 46kN at "speed", the value looks reasonable if C = 0.6 and the remainder of torque is applied for acceleration. I just wanted to mention this for the physics to emphasize how substantial drag is at high speeds.

Water, road and air vehicles are more prone to influence from these in my opinion, as they experience higher density, smaller engines and higher speeds.

[jamespetts]

Drag and related concepts are simulated in the physics engine itself; but I did not write this, it is complex, and I do not know how the code works. I thus do not have any ready way of extracting values from this for use in the calculation of fuel consumption.

[Spenk009]

I had originally intended to reply in the thread here, but this is probably better suited to this thread.

Given the discussions here, there may be some merit to allowing players to limit the speed of vehicles in the schedule, but this will need careful consideration.

May I suggest limiting the power in the schedule? If given the option to limit the power in percentage of total convoy power or percentage of top speed [power reduced accordingly to reach the new top speed]). There is a relation to power efficiency that can be generalized and extrapolated accordingly. In combination with the quoted post by vladki, if a delay is registered the convoy allows for a set delayed max power or automatically uses 100% of its theoretical power.

About the schedules. I think it would be enough to improve the current system with two changes
- flag if the latest departure time slot was used or not (probably we already have this to show green/cyan colored lines that miss their slots?)
- way to adjust the tolerable delay, and let trains depart if they are within tolerance, and the previous slot was not used.

[jamespetts]

I had originally intended to reply in the thread here, but this is probably better suited to this thread.
May I suggest limiting the power in the schedule? If given the option to limit the power in percentage of total convoy power or percentage of top speed [power reduced accordingly to reach the new top speed]). There is a relation to power efficiency that can be generalized and extrapolated accordingly. In combination with the quoted post by vladki, if a delay is registered the convoy allows for a set delayed max power or automatically uses 100% of its theoretical power.

I am not sure that this really makes sense as a simulation of something that a real life transport company could do; how could one tell the driver of a steam engine or a pilot of a jet aircraft to use only up to 80% power, for example?

[[C] Ranran]

If there are vehicles with different performances in the line and the performance of convoy is different, it may be convenient to limit the performance and make it the same performance.

Also, setting a low speed limit for lines where the vehicle has a high top speed but never reaches the top speed of convoy due to the low speed of the track, thereby reducing fuel consumption, is probably a more realistic simulation.

[DrSuperGood]

May I suggest limiting the power in the schedule? If given the option to limit the power in percentage of total convoy power or percentage of top speed [power reduced accordingly to reach the new top speed]). There is a relation to power efficiency that can be generalized and extrapolated accordingly. In combination with the quoted post by vladki, if a delay is registered the convoy allows for a set delayed max power or automatically uses 100% of its theoretical power.

Full power output may be needed to accelerate the vehicle to a reasonable speed. A player may wish to pay for acceleration losses for rail capacity reasons but not want to pay for the large aerodynamic losses for higher speeds. Additionally if the speed of a line is regulated well enough then the acceleration losses are minimal as the train will usually just break once when approaching the next stop.

Also, setting a low speed limit for lines where the vehicle has a high top speed but never reaches the top speed of convoy due to the low speed of the track, thereby reducing fuel consumption, is probably a more realistic simulation.

This should make no difference as once it is at top speed it stops burning power to accelerate and so becomes more economical anyway?

[[C] Ranran]

This should make no difference as once it is at top speed it stops burning power to accelerate and so becomes more economical anyway?

When thinking about powering time, fuel efficiency is greatly affected by the distance between stations. It depends on powering time, not on tiles or distance. So it may be difficult to simulate it faithfully due to computational load issues. That's not what I want to mention this time.

In general, the fuel efficiency data declared by the maker is not always the same depending on the actual usage. It only shows average data under certain circumstances for normal use.
Even when using average data regardless of the distance between stations, reducing the maximum speed should save fuel.
Because, as this graph shows, the powering time varies greatly. Instead, the time spent driving at a constant speed will increase, but overall fuel economy should be saved.


If it is running at maximum power instead of coasting, acceleration should continue to the equilibrium speed. In many cases, the maximum speed of the vehicle is lower than the equilibrium speed for other reasons. I mean, maintaining the top speed is not always the max power.

The maximum speed of the locomotive and the maximum speed of the wagon are often mismatched. If it has lots of wagons connected and the balancing speed is low, it will need to run at full power, but it will be lazy if it pull a few wagons at low speed.

[jamespetts]

Returning to this topic after some time, as some consideration will be needed in relation to implementing this in conjunction with the vehicle balancing features, especially since I have recently implemented to the solution to the other major issue that had to be addressed before we could return to this, being reversed vehicle graphic alignment.

Returning to what has been discussed so far and where we left off in early January, I agree with Ranran that, if we are to limit anything, it really needs to be top speed and that limiting power does not make sense. Limiting speed to save fuel is done in reality on occasions; I have heard of it being done for ships and aircraft, and I suspect that it will have been done for rail and road vehicles, too, but I am not sure.

Can I ask whether anyone else has any observations and/or data relating to the two stage formula approach that I set out on boxing day 2019? This will need to be implemented in the vehicle branch, I think, once that be brought up to date with the latest master branch, which will be a very substantial amount of work.

[Sirius]

and I suspect that it will have been done for rail and road vehicles, too, but I am not sure.

At least Deutsche Bahn did some power saving training to their train drivers, which on local trains is basically accelerate as fast as possible (within an upper limit of something around 1.2 m/s²), then coast as long as possible and finally use regenerative braking down to a rather low speed, where mechanical brakes will hand in.
Schedules usually have some spare time, so trains in time won't accelerate to their maximum speed.
Delayed trains might accelerate to maximum speed, keep that speed up the whole time and brake later, which might involve rheostatic or mechanical braking.
Some trains even have technical systems that assist in this.

1. It totally makes sense and is perfectly realistic to limit max speed.
2. The system should consider that players might want to set a higher speed limit to delayed trains. What exactly that "delayed" means is another feature, but it should definitely be designed with this in mind.

[[C] Ranran]

I think in order for this to work well, we first need to completely separate the labor cost from the runnning cost.

[jamespetts]

I think in order for this to work well, we first need to completely separate the labor cost from the runnning cost.

That is certainly planned - the labour cost is based on a per unit of time cost, so, to an extent, this is already implemented.

[jamespetts]

Some more detailed thought needs to be given to the implementation of this in light of the discussion regarding the implementation of staff cost here.


Specifying fuel consumption

First of all, it would be helpful to adopt a similar system to that designed in respect of staff cost described in this post on the above linked thread so as to avoid the need for very labour intensive calculation of fuel costs adjusted for inflation.

Thus, I suggest a fuel.tab file which would give the per unit cost of fuel in Simucents in each year. Again, for ease of coding, this is likely to need to be a number. Thus:

Code Select Expand


# Coal, per kg
1=1750,150,1800,100,1850,70,1870,60,1890,60,1900,50,1920,70,1940,75,1950,80,2000,70

# Petrol, per centilitre
2=1890,25,1900,20,1920,25,1930,26,1940,50,1950,40,1960,42,1970,45,1973,90,1980,80,1990,85,2000,90,2008,95,205,85

# Electricity, per kw
3=1890,40,1900,35,1920,36,1930,30,1950,30,1960,32,1973,40,1980,40,1990,45,2000,50,2020,55


Then, each powered vehicle would have a fuel cost set as follows:

Code Select Expand


# Example for a steam locomotive
# Coal, kg/km at calibration_speed
fuel[1]=10
calibration_speed=75
minimum_fuel_consumption_at_speed=30


Code Select Expand


# Example for a small early 'bus
# Petrol, cl/km at calibration_speed
fuel[2]=20 # Equivalent to 14 miles per gallon, or 0.2l/km
calibration_speed=50
minimum_fuel_consumption_at_speed=15


As with the staffing cost, this would integrate the fuel consumption data with an inflation system so as to reduce duplication of work and the need for labour-intensive inflation back-calculations at the time of implementing these data in the pakset.


Existing maintenance cost

The existing runningcost= parameter would be retained to represent maintenance (described as "repairs" in the older literature), and likewise the existing fixed_cost for any maintenance that varies by time rather than by distance (although it is hard to find any data on this).


Range

Once we have a system that explicitly gives fuel consumption, we can in theory extract these data and use them for range.

However, doing so is likely to lead to very great complexities that it is difficult to solve, and, unless anyone can come up with an elegant solution to these complexities, I am minded for the present not to implement dynamic range, but rather to continue with the fixed range system in place at present.

The difficulty is that a dynamic range system is too unpredictable for players meaningfully to be able to interact with, and also to be able to do anything sensible with the limit: we cannot stop a convoy from leaving a stop to go to its next stop on the ground that it is out of range unless we know in advance what the range is, which we cannot do if this can be calculated dynamically based on actual speed, which can change depending on the traffic on the route.


Speed limitation

This would be something to add to the schedule features, and would give a convoy an additional possible speed limit.