News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

Measuring work and fuel consumption

Started by jamespetts, December 08, 2015, 12:31:28 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ACarlotti

Quote from: jamespetts on August 07, 2018, 12:07:09 PMthe 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

#72
Thank you for your thoughts.

Quote from: ACarlotti on August 07, 2018, 04:37:01 PMI 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.

QuoteIf 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.

QuoteThis 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.
QuoteI 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.

QuoteI 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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

Quote from: jamespetts on December 26, 2019, 12:51:28 AMthus 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?
ALLMYCONTENTISPUBLICDOMAINBUTNOEXPLOITATION

Simutrans - the open source Transport Tycoon Deluxe clone.

DrSuperGood

Quote from: Qayyum on December 26, 2019, 08:14:38 AMFor 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

#81
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Qayyum

#82
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.
ALLMYCONTENTISPUBLICDOMAINBUTNOEXPLOITATION

Simutrans - the open source Transport Tycoon Deluxe clone.

DrSuperGood

Quote from: jamespetts on December 26, 2019, 12:50:29 PMThe 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.
Quote from: Qayyum on December 26, 2019, 03:36:12 PMOne 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

Quote from: DrSuperGood on December 26, 2019, 05:37:45 PM
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?

QuoteOne 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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

Quote from: jamespetts on December 26, 2019, 06:33:23 PMAre 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.
Quote from: jamespetts on December 26, 2019, 06:33:23 PMHow 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

Quote from: Phystam on December 26, 2019, 06:44:13 AM
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Spenk009

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

Quote from: jamespetts on December 30, 2019, 11:04:25 AMGiven 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.

Quote from: Vladki on December 30, 2019, 09:39:44 PMAbout 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

Quote from: Spenk009 on January 01, 2020, 09:34:56 PM
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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

DrSuperGood

Quote from: Spenk009 on January 01, 2020, 09:34:56 PMMay 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.
Quote from: Ranran on January 02, 2020, 12:31:49 AMAlso, 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?

Ranran(retired)

Quote from: DrSuperGood on January 02, 2020, 01:05:19 AMThis 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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

Quote from: jamespetts on August 26, 2020, 06:13:48 PMand 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.

Ranran(retired)

I think in order for this to work well, we first need to completely separate the labor cost from the runnning cost.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

Quote from: Ranran on August 26, 2020, 06:56:41 PM
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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:


# 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:


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



# 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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.