News:

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

Estimating vehicle acceleration

Started by freddyhayward, November 22, 2019, 01:53:23 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

freddyhayward

I mentioned in this thread (https://forum.simutrans.com/index.php/topic,19362.msg182594/topicseen.html#msg182594) that it would be useful if the depot GUI could show how long it takes a given convoy to reach arbitrary speed increments (or, the acceleration at such increments). Choosing suitable vehicles currently involves a lot of guesswork and confusion (as evident in that thread).
QuoteThe actual performance of vehicles needs to be simply communicated somehow. It is too difficult to mentally calculate it using force, power, weight, gear, etc, especially for new players. Something like:
50km/h: 12-15s
100km/h: 32-36s
150km/h: 72-84s
etc etc until top speed (e.g. 160km/h): 80-96s
Or perhaps a graph.
Of course, this would have to be estimated at runtime based on vehicle statistics, and a look at the physics code has only made me more confused. Does anyone else have an idea of how this could be done?

Phystam

Will acceleration curve (km/h v.s. kg/t graph) for the convoy helps us?
We need another graph window, but maybe it is similar to financial graph window, isn't it?

Ranran

Probably a simple implementation is a display of power-to-weight ratio.

freddyhayward

Quote from: Phystam on November 22, 2019, 10:07:41 AM
Will acceleration curve (km/h v.s. kg/t graph) for the convoy helps us?
We need another graph window, but maybe it is similar to financial graph window, isn't it?
I had in mind something like this: https://eversholtrail.co.uk/fleet/class-158-freight-same-category/

Quote from: Ranran on November 22, 2019, 10:46:25 AM
Probably a simple implementation is a display of power-to-weight ratio.
That would certainly be an improvement but would still leave quite a lot of confusion, because acceleration at different speeds will vary based on gear (0.0 - 1.0), power (kW), tractive effort (kN), rolling resistance (-kN) relative to weight.

Spenk009

Quote from: freddyhayward on November 22, 2019, 11:14:53 AM
That would certainly be an improvement but would still leave quite a lot of confusion, because acceleration at different speeds will vary based on gear (0.0 - 1.0), power (kW), tractive effort (kN), rolling resistance (-kN) relative to weight.

Not if you calculate the values for the assembled convoy. If the player desires, they can build several configurations and cycle through the assembled convoys in the depot window. They would be able to see the values and curve.

Two curves would be handy, showing both full and empty. (Maybe just ignore changes in vmax for curves and gradients)

DrSuperGood

Quote from: Ranran on November 22, 2019, 10:46:25 AMProbably a simple implementation is a display of power-to-weight ratio.
This only really applies to high speed acceleration and when rolling resistance and drag is not significant. At lower speeds the acceleration is limited by tractive effort (force the train can apply without the wheels spinning).

Ideally one would want a graph for this that shows acceleration (Y) against speed (X). A slider would control the train weight between empty (0%) and overcrowded maximum (100%) which the user can set based on what load they expect the train to operate at. This allows one to visually see the effect of limited tractive effort, drag and rolling resistance. Where the graph is close to 0 acceleration one can assume that the train will not normally reach such operating speeds, even if the rolling stock it is made from are ratted to be capable of that speed.

Mariculous

QuoteOf course, this would have to be estimated at runtime based on vehicle statistics, and a look at the physics code has only made me more confused. Does anyone else have an idea of how this could be done?
Why? We should try to understand the implemented physics. Once we did this, we can calculate theoretical data for completely empty and completely full trains, assuming a gradient of 0° and nothing stops our train moving (i.e. no red signals).
This data will be fine to roughly compare vehicles and is much more meaningful than data that is affected by external factors that have nothing to do with trains potential acceleration.

Considerations if we really want exact data for a train on a line
If we really want to know the exact acceleration data for a given vehicle on a given piece of track, taking this data from vehicle statistics would be pretty useless due to the follwoing reasons:
1. We want to know how a vehicle will perform before purchasing and test running it.
2. We would get data for some specific loads but what we really need to know is the worst case and sometimes also the best case, especially when planning schedules it is very important to know the exact time frames in which a vehicle could be at a given track, instead of "when a vehicle was at some test runs at a given track".
3. "real" simuworld scenarios suffer from further aspects. It will greatly falsify acceleration data gathered from test runs when the train reached it's target speed much later due to a level crossing or a red signal that stopped or slowed it down.

This given, I don't think that an acceleration graph based on vehicle statistics will be pretty useful. Additionally, a low tractive effort, high power train climbing up a long hill at, slow speeds, which reaches 160 km/h for a very short time after that hill, would look better than a train that doesn't reach 160 km/h at all due to bad power but will climb that hill faster due to higher tractive effort.

The complicated approach
If we really need (meaningfull) acceleration data for a given piece of track (and different vehicle loads), we need some planning tool where we can select a specific section of track and simmulate a given vehicle with a selected load on that track section.
We could also draw an acceleration curve, a speed curve, a way curve or whatever for a given vehicle, all of these have kind of useful information.
I guess a way graph would even be the best to show what we are interessted in: How long do we need to travel along that track. However, a speed graph could also be kind of useful. Acceleration graph... Well I don't think it's useful to be honest.
However, I don't think it's worth the effort and apart from the way graph too complicated to understand.
I guess this is the only way to get meningful acceleration data, but I don't think we need it as it's overcomplicated, will decrease usability even further for no reason, as there are better alternatives.

The alternative approach
In fact, we don't really care about acceleration itself, it's just a good measure to roughly say which train would be good for a line.
What we are really interessted in is optimizing travel times (and costs) of a line.

So what I suggest is the follwing two things:
1. Show "accelerates to <selectable speed> in ... seconds" in the depot for a given train, to get a rough overview of acceleration of a train.
2. Show calculated travel times for full and empy trains (maybe also not overcrowded full times) in between stations in the "times history" window.
For lines with mixed vehicles, we should maybe add one column for each vehicle type or simply pick very worst case (slowest train, completely overcrowded) and very best case (fastest train completely empty).
We could optionally add
3. Show a way/time graph  (x way, y time), speed/time grpah, acceleration/time graph or speed/acceleration graph for a given vehicle at a given line, but as I said, I don't think it's worth the effort.


Additionally, it would be nice to get train stop time data in that window for both, actual last 3 trains and vehicles min/max loading time, but that's yet another thing.

Also, we should add a selectable speed to the brake distance of a train "brakes from <selectable speed> in ... km", as sometimes, e.g. when using slower tracks than trains maximum speed, we are interessted in the braking distance of the train at tracks maximum speed.

Btw. the curve in the paper is a speed/time curve, not an acceleration/time or acceleration/speed curve.

freddyhayward

Freahk, perhaps I have been unclear, since a speed/time graph is exactly what I was intending, and I am not suggesting that line, track, curve or gradient factors be considered at all. What I am suggesting would be similar to number 1. of your "alternative" approach. Selectable speeds would work provided they are persistent among all vehicles capable of that speed (i.e. the setting is not reset when viewing other convoys). I would prefer to display uniform increments leading up to the maximum speed. This could be expressed in a single line of text, or easily converted to a graph.
Say using 50km/h increments on a 160km/h capable train:
Acceleration: reaches 50km/h in {min}-{max}s, 100km/h in {min}-{max}s, 150km/h in {min}-{max}s, 160km in {min}-{max}s
or a 75km/h capable bus:
Acceleration: reaches 50km/h in {min}-{max}s, 75km/h in {min}-{max}s
or a horse-drawn carriage:
Acceleration: reaches 10km/h in {min}-{max}s

Ranran

#8
The reason why I thought the display of power-to-weight ratio is simple is as follows.

1) The GUI should be available for all vehicle types.
Perhaps on ships and airplanes, acceleration is not important (except for obvious errors).
Therefore, the display of the graph is an obstacle for unnecessary vehicle types, so it is desirable to hide it by a separate window or collapse or disable for specific vehicle types.


2) Difference in electric motor and engine characteristics
There is a big difference between a electric motor and an engine, and in the real world, an accurate (constant) acceleration cannot be obtained for an engine.

This graph is an f-v graph showing the acceleration force of DMU and EMU.


Light blue is an express DMU, red is an express EMU and green is a commuter EMU.

In the case of an electric motor, a constant acceleration is maintained up to the rated speed, and the acceleration decreases from there.
In the case of an engine, the maximum torque is obtained at a speed close to 0, but the acceleration force decreases as the speed increases.
(Actually, theoretical values cannot be obtained at ultra-low speed due to idling of wheels)

Are these differences simulated by the current Simutrans extended?
If so, the graph display above is the best solution.


There are further differences in the real world:
Since the red EMU uses field weakening control, the rotation speed is increased at high speeds. Because this is for express use, high speed performance is important.
Many modern AC motors increase the high-speed performance by controlling the current.
Therefore, higher acceleration is maintained up to the higher speed than the rated speed calculated by the power and TF.
Also many diesel engine vehicles can shift gears in several stages. This is a characteristic that steam locomotive does not have.


At first glance, the current Simutrans-Extended behaves like a simple DC motor car.
In the case of a electric motor, the rated speed is determined by the balance between the tractive force and the output, but this value can now be confirmed on the depot dialog even for the diesel vehicle.
(So I supposed that Extended does not simulate the characteristics of a diesel engine, but I don't know if this is correct)

If it doesn't correctly simulate the engine characteristics as I guess, I think it is sufficient to display acceleration and rated speed.
If the engine characteristics are simulated correctly, the acceleration graph is the best tool to understand the difference between an electric motor and an engine.



I agree with Freahk that the display of acceleration is not as important as it is.
If the player doesn't know the actual rail car acceleration data, he doesn't know how much acceleration is desirable.
I think the point to be achieved is (1) Check if the conditions for reaching the maximum speed are met, and (2) Make it easier to compare the performance of multiple convoys.
This is because it is desirable that the convoys with different configurations on the same line have close run times.
Also player will also not want to lose performance when replacing vehicles.

EDIT: I apologize for the wrong name. The automatic translator automatically reinstates the spell.

Ranran

#9
Well, I forgot to write one important thing. (´・ω・`)
It is a unit issue.
In Japan, km/h/s is used for vehicle acceleration.
But as long as I check at some English website (Excluding USA), the British may prefer the m/s/s notation.
If so, I hope to be able to switch the display with setting like date display when displaying acceleration. Americans will also require a different notation.  :-X

Mariculous

m/s^2 is the most common I guess, at least in Europe.
It is also the SI unit for acceleration.

@freddyhayward so it was a missunderstanding, srry about it.
However, for the given reasons I don't think that only adding this acceleration data is sufficient. It works well to rouggly compare vehicles but what we really want to know is the expected time in between stations of a line. We should add calculated values to times history window and add such a window with only calculated times for trains in a depot if the train vas a schedule set up.

Ranran

Brake performance also affects the running time between stations.
A vehicle with good braking performance can run at high speed for a long time.
Generally, in the real-world railway industry, simulation is performed using a run curve.
http://www.notchman.net/manual/ntwme/UsingRunningCurveWindow.html

However, the v-t graph may be easy for players to understand.
In the v-t graph, you can see acceleration and deceleration from the tilt, and you can see the running time on the horizontal axis.
However, since current graphs only connect 12 to 24 horizontal axes with dots, it may be difficult to create such a complex graph.
Also as mentioned above, the acceleration force is not constant.
I don't know how the acceleration slowdown beyond the rated speed is implemented, but it is probably possible to estimate the travel time between stations. I guess that some calculation is currently used to slow down the acceleration force.

The estimated run time display is very useful even if it is only text, not graph. This should also take into account changes due to load weight, that is the maximum loading case and the no loading case are calculated.

Is it better to select the distance and display the calculation result like the fare calculation in the goods list dialog?

Mariculous

#12
QuoteIs it better to select the distance and display the calculation result like the fare calculation in the goods list dialog?
Could also work and should be kind of informative to get a fair overview of vehicles. I guess distance/speed is a slightly better measure than time/speed as we most often know rough distanaces in between stations of our line, so we can roughly guess how long in meters it can accelerate until it has to start braking down, whereas guessing how long in time they can accelerate untik they have to start braking down again is much harder.
Maybe it is even better to set a distance and calculate the maximum speed the train can reach at this distance including accelerating and braking down. If it can reach max speeed, instead display the distance at which it will travel at that maximum speed.

However, I still think the core feature when it comes to comparing train performance still is travel times so setting up schedules will be much easier than it is today.
Also, when knowing travel times, it will be much easyer to decidet if a vehicle is a good replacement for an older one, maybe even if it's worth to revise lines schedules when using the new trains.

That given, we should really add a travel time table for trains in the depot that will show calculated travel times at min load and max load for the train at a selected route, as this will give as all these informations in a very intuitive way.
For convinience, we should also add calculated min and max load travel time to the times history window so if delays appear for a line, we can immediately see where it appears most often and how much delay it is.
At some very highly ferquented tracks it could even be desired to have multiple trains using the same time window, so some of these will be delayed according to planbut that's not a problem if we choose waiting time at the next scheduled station high enough to compensate this.

Calculated travel times would also give us a measure for train punctuality:
A train is punctual when its travel time was lower than or equal to the calculated max load travel time, which could be used to inform the player about lines that were not punctual in last month, while the less strict "was missing schedules last month" doesn't kick in.
This can be pretty useful to seek the cause of "missing schedule" of another line.
If Line A is often unpunctual but does not miss schedules (due to high buffer times in schedule), if line A trains and line B trains are sharing a piece of tracks, our line A trains will eventually break out line B trains. For line B this could mean it's missing schedules now directly due to the delay of line A or, which is even harder to track down, it gets behind a punctual train of line C at another piece of track, but line C is using much slower trains than line B, so we get a huge delay for it caused by a line that itself was unpunctual but didn't miss a schedule.

Times in between waypoints would give very useful information to the player especially for long distance trains that don't stop too often, running in mixed service with slower trains at some tracks. To ensure trains can get their sechedule, we have to ensure these fast trains won't be braked out by slower train, so we need to know the time window in which the faster train and the slower train will enter that piece of track (given trains are punctual for sure)

Phystam

It's an interesting idea. I started to add the feature to estimate the journey time between two stops as an additional entry of times_history feature.
Times_history has two different features: the history of a line and the history of a convoy. A line (schedule?) can have plural types of convoy. Therefore the feature for a line is not so simple. I recommend that we introduce it only for the times_history of a convoy.
Additionally, when a convoy has been constructed with a schedule, it is very convenient and helpful that we can check the estimated times at the depot window.

Mariculous

#14
Great!

I totally agree with you about convoy travelling times, including adding these to vehicles in a depot.
However, I don't really agree with you about lines travelling times for the following two reasons:

I would argue that lines with multiple different vehicles don't appear too often and it can be very helpful to see actual travel times of the last few vehicles of a line compared to calculated best case travel times to detect sections of track that need improvements in signalling or in schedules.

For mixed convoy lines I would argue that it is still pretty useful to get a quick overview of lines calculated max load travel times as this is the time that is most important for schdules.

That given, we should
- for convoys add empty and full load calculated travel times to the table
- for lines add the best empty travel time and worst max load travel time of all convoys of that line to the table.

This will give us an exact time frame for travel times for convoys, which is important to see if a vehicle can provide lines requirements, and lines, which is important when scheduling a line within the whole network.

When you are already workng at that window, could you also try to add statons loading+reversing times (not waiting for schedule or waiting for free tracks times) to the table?
This is yet another veeeeeery important aspect of schedules which admittedly varies pretty much, but some statistics about it would be very helpful for schedules.

Phystam

What I want to do is:
1. make a function to get acceleration/deceleration distance/time (d_a(v), d_d(v), t_a(v), t_d(v) ) as a function of velocity (m/s).
2. get a distance (d_st) list between two stops
3. if d_st > d_a(v_max) + d_d(v_max), d_st - (d_a+d_d) is a distance that the vehicle runs at v_max. thus calculate t_max = (d_st - (d_a+d_d))/v_max and t_a+t_max+t_d should be the estimated time.
if d_st < d_a(v_max) + d_d(v_max), look up the velocity at which d_st = d_a(v) + d_d(v). thus calculate t_a(v)+t_d(v) should be the estimated time.
4. store the calculated data to ... schedule_t ?
5. get the stored data from times_history window.

1. and 3. have been cleared, but the data structure is not so simple. For instance, I expected that there is a function to obtain the distances between two stations/stops, but it is not in schedule.h...

Mariculous

If I understand you right, you want functions to calculate
1. the time it takes to accelerate from 0 to v
2. the distance a vehicle will travel at that time
3. the time it takes to brake down from v to 0
4. the distance a vehicle will travel at that time.
5. a list that contains actual distances of vehicles path along existing ways in between stations of the schedule.

I don't think it's that simple.

Let's start with 5. as this seems to be unclear to you?
To get the distance in between stops, you will first need to calculate the route for a given vehicle in between two given koords.
I guess you can use the vehicle_t::calc_route function for this but also make sure to have a look at the implementation of route_t::calc_route.
I thought the route would give us some kind of information about allowed max speeds, which are influenced by
- ways Vmax, including level crossings and tunnel/bridge/elevated ways,
- curves
- signs or signals that have a speed limitation
- additional special cases like token blocks requirement to stop there.
However, route itself doesn't seem to contain that kind of information but I am quite sure it was somewhere in the code. Maybe it was only at rail working method/signalling related code. Sadly I should already be sleeping for 2 hours now and won't have time to look at this again this weekend.
If you find this piece of code I am quite sure you will be able to build a list of max speeds along the route between two stations and then you can calc travel times in between these sections.

That being said, 1., 2., 3. and 4. (I guess these are methods of a convoy?) need to get a further v0 argument as we don't always start at 0 km/h.
An additional useful sideffect is that this will also allow us to easily calculate travel times in between waypoints.

I guess storing travel times in the schedule is a good idea if recalculating it is pretty computational intense or happens pretty often.
The first is hard to tell before it's implemented the second is not the case if travel times are only used for the times_history window. In case it is shown as some kind of "line was frequently delayed last month", not storing this could further decrease month change performance.
However, in neither case I would agree to persistently store that data. It should not be that computational intense to dramatically slow down map loading, when calculating it at that time.

Ranran

QuoteI don't think it's that simple.
Indeed.


Quote1. make a function to get acceleration
The travel distance can be calculated by the area of the v-t graph, but it should be noted that the acceleration is not constant as I already mentioned.
When the current speed is faster than the rated speed, the acceleration decreases gradually. This is a feature already implemented in extended.

You can check it in the following part of the depot dialog.

I think that most common players don't understand the meaning of this speed value correctly. And the simutrans's "gear" is not a gear, but that value is closely related to the actual gear.

Even for vehicles with the same power output, the difference between for high speed and for low speed can be produced. This is one of the great feature of extended. ;)


The acceleration of the above vehicle decreases as shown in this graph when it exceeds 48 km/h.


The decrease in acceleration draws a curve like a blue line instead of a straight line in the real world. If the implementation was done that way, the distance calculation would be more complicated.
I don't know how this formula is implemented in Extended, but you will need to find it in the code.
Since the rated speed is determined for each powered vehicle, not for each convoy, it may be quite complex when considered in convoy...

Also it should also be noted that the rolling resistance and air resistance affect in extended. Increasing speed will increase these effects and further reduce acceleration.
For these reasons, I believe that there is no vehicle that has a fixed acceleration in extended.

I assume that there is a function that determines the acceleration force (propulsion force) from values such as power output, tractive effort, gear, weight, and running resistance, and that acceleration is controlled. (I don't have time to see the code so I can't confirm ...)
I think it may be necessary to use that function to convert the propulsive force at each speed into acceleration.



About schedule delay:
Some way types may have less delay, but roads tend to be slower than estimated time.
Also, if there are elevation differences or curves, there will be a delay, and including it in the calculation will be more complicated.

Mariculous

I unexpectedly found a few minutes to have a look at it again and immediatley found the code that seems to perform convoy movement:
https://github.com/jamespetts/simutrans-extended/blob/master/simconvoi.cc#L1245

Calculating the integral of the speed function physically totally makes sense and should roughly work.
However, calculating it can be quite complicated as vehicle movement in extended is also complicated as you have already mentioned.
It should be simpler and more precise in the simutrans world to simmulate our convoys movement steps along the route, for sure without checking if the way is free.

Maybe acceleration and deceleration times can be implemented even without repeatedly moving the simmulation convoy as it seems that the convoy knows how many steps it has to go
sint32 sp_soll; // steps to go
but I don't know what happens after that number of steps. Is it the number of steps to the next change in accelaration/deceleration/constant speed or whatever? I don't know and can't dig deeper now.

I'll be back for this on monday afternoon.

Phystam

Yes, I know about the acceleration is given by non-constant tractive effort: it is considered as a constant value until a velocity, and then it decreases like c/v function.
The tractive forces have been already calculated in vehicle_desc_t::loaded(), and we can get the tractive forces for each tractive vehicles as a function of velocity.
Using it, we can integrate it and obtain distances/times array as a function of velocity.

Phystam

Sorry for my double post.
The most important thing is to simulate the expected times without moving the convoy. The sync_step() function is for moving convoy; the function is maybe not for the "virtual" convoy to estimate the travel time. And I think that that function has too high calculation cost to estimate the travel times. It is okay if the convoy is moving, but in our situation, no. The estimation way should have less calculation cost and a simpler way along physics.

Mariculous

#21
Sorry for not being clear enough. I don't think we should call the sync_step to simmulate anything but that function seems to be the one actually moving the vehicles so that's the point to start researching how exactly vehicle movement works in simutrans-ex.
Many things in sync_step are absolutely nonsense for a virtual vehicle that does not exist in the simuworld like generating smoke. Additionally we don't care about anything else than the state==DRIVING case.

I guess there are two important things happening: The calc_acceleration call and the do_drive call.
We could try to calculate the integral and use it or alternatively discretely stepping along the curve by repeatedly calling calc_acceleration and do_drive.

Discretely stepping along the curve is expected to be slower but results will be closer to real vehicles moving in the simutrans world.
The first should perform better but will give less precise results and is more complicated to implement.
I don't expect discretely stepping along to be that extremely computational intense to lag the game and one could calculate it async. Also, no matter if stored or not, it won't be calculated pretty often.

No matter if you want to discretely step along or continously calculate it, you will need to cut the route into Vmax sections.

Phystam

The function for the time estimation is called only when players have changed convoy or schedule.
Or, at least we have to execute the function when the player opens the times_history (or times_estimation) window.
If the calculation time is negligible, we do not need to save the calculated data into savedata.

if we use calc_acceleration() and do_drive() functions, we have to modify them, since they move the actual convoy. Instead of them, we have to prepare a "virtual" convoy for the time estimation. It would be more complicated...

Mariculous

We still do not want to call the exact function but we want to call somethin that is pretty close to it in terms of simuphysics but as minimal as possible. These two funcrions will tell us what exactly we have to do.

Phystam

Anyway, we have to calculate numerical integration to obtain the estimated time --- but it depends on the integral variable, such as velocity, time or distance. Probably it is good for estimation that we use a similar function like calc_acceleration(), and integrate times along the route.

I copied some variables and functions used for moving the actual convoy. (array_tpl<vehicle_t*> virtual_vehicle; route_t virtual_route; etc.) Then we can pre-simulate moving of the convoy.

DrSuperGood

In theory one could simulate the vehicle physics (as if on a straight track) for 1,000-10,000 ticks and use the collected data to generate a graph. The performance for this should be pretty efficient due to the limited amount of data involved and could even be run asynchronously if that is a concern.

Mariculous

#26
That's how I would try to calclulate/simmulate travel times, however, I would use the actual path and cut it at changing vMax points and changing gradients just as the game does. That will consume a little bit more performance but is especially important for tracks in the mountains with many slopes and curves. Otherwise the calculated time would be be useless for these.