## News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

## acceleration info in convoy details

Started by Vladki, May 25, 2020, 10:47:00 PM

0 Members and 1 Guest are viewing this topic.

Hi I just noticed that there is "starting acceleration" in spect_tab of vehicle details. It says e.g:
Starting acceleration 2.07 km/h/s (2.29 km/h/s) ,  with the first value changing on each stop.
So I guess the first value is with current load, the other empty. Right?

But how is this value calculated? It does not seem to be exactly tractive_effort*gear/weight(*3.6 to make m/s/s to km/h/s)

#### Sirius

km/h/s o.O
Never seen such an odd unit.

#### jamespetts

Km/h/s is, apparently, the standard way of measuring acceleration in Japan. It is much easier to understand than m/s^2, as it does not require people to convert km/h into m/s. I believe that Ranran implemented this, so he should be able to elaborate on the mathematics used.

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

Any specs I have found so far use m/s^2, or a graph, or time to reach 100 km/h (but that's mostly for fast personal cars).

#### Ranran(retired)

#4
QuoteBut how is this value calculated? It does not seem to be exactly tractive_effort*gear/weight(*3.6 to make m/s/s to km/h/s)
At 0km / h the resistance is ignored. So I just converted get_force_summary into acceleration. get_force_summary was coded by Bernd Gabriel.
The value it returns should also affect gear. That is, it is not the theoretical value of the spec, but the actual acceleration value in the game. Otherwise, it will not be useful in the acceleration chart described later. Similarly, it would be useless in estimating the time required for acceleration and the travel time between stations.
It should be noted that it is linked to in-game distance and time. Changing just the display calculations creates a conflict with them.
This physics code affects many things and is complex so at least I can't modified it and I haven't done that.

Quote from: Freahk on May 25, 2020, 11:14:28 PMkm/h/s o.O
Quote from: Ranran on November 23, 2019, 06:59:23 AMIn 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.
Quote from: jamespetts on January 02, 2020, 11:08:21 AMThis is an interesting patch; thank you. I should note that doing this in km/h/s is almost certainly far clearer to a player than doing it in m/s2, as the former measure is related to something that the player can readily understand (km/h), whereas m/s is not a normal way of thinking about the speed of transport vehicles.
This is not because the unit system in the US or Japan is crazy. It has already been discussed in another thread late last year.
https://forum.simutrans.com/index.php/topic,19363.0.html
If we use m/s/s unit system, I think the velocity unit should also be m/s.
And the acceleration was also planned to be used as a graph. The patch broke, but may be revived in the future. Anyone interested in it can cast a resurrection spell. Renervate! ~
Anyways, as previously discussed, using m/s/s there will confuse players with the difference in units. This is because the current speed and maximum speed are expressed in km/h.
The vehicle speed is displayed as 160 km/h. Acceleration is displayed as 1 m/s/s. It is tedious to calculate if it is displayed correctly on the V-t graph.
At 2 km/h/s, it is clear that the 120 km/h speed increases in 60 seconds.

In addition, as explained in another thread, vehicles with modern inverter control may have an incorrect relationship between motor output and acceleration.
This is because modern AC motors make it easier to control the current, so the computer controls the acceleration. That is, the power in the catalog may differ from the actual power. Conversely, there is no need to use it as it is. It is set to the user's preference. It is a concept closer to the "gear" of simutrans or overclocking of CPU rather than the real gear.
Originally, to obtain TF from KW, the rated speed of the motor, gear ratio, and wheel size are required. You may just assume that KW to TF announces the correctly calculated result by the operating company.

In the Japanese example, one of the reasons to do such a thing is to achieve the same acceleration regardless of the convoy condition.
Second, a low-power motor is used with an overload on a train that is slow and has a short acceleration time. This has the advantage of reducing costs.
On the other hand, poor western Japanese train companies prefer to use high power motors to get a lot of regenerative power. However, at the time of acceleration, the capacity is limited by accelerating by limiting the current used against the output. This also has the purpose of preventing voltage drops in the DC electrification section where many vehicles run. Because they are poor, they cannot strengthen the substation.
In addition, since 2000, redundancy has become important in companies with abundant funds in urban areas, and as a result, the number of motors in the train has increased, and even if some of them fail, there is no problem.

The third impersonates the property by adjusting the current to make up for the weaknesses. For example, a high-speed gear car has low acceleration, which causes problems when traveling in the same section as a commuter train.
On the other hand, commuter trains compensate for this because the acceleration decreases in the high acceleration range. In that case, it behaves as if it had a rated speed different from the original. This can be accommodated by adjusting both TF and gear. This is because the rated speed is determined by the balance between TF and KW. After that, all you have to do is adjust the gear so that the desired acceleration is achieved.

In Japan, there are cases where we used an inverter AC motor from Siemens in Germany, so I don't think the motor specifications are so different. The introduction example of this motor was famous as a "singing motor" though it was a little. However, it has become extinct from Japan due to aging.
That train nominally has a starting acceleration of 2.0km/h/s, but it is impossible to achieve it with its poor performance. He from Germany must have been overworked and died like a Japanese worker.
(The truth is that the semiconductor has a short life.)

From the above, I recommend adjusting the in-game acceleration using gear. For example, if you feel that the acceleration of the Class 800 is low, adjusting the gear is recommended. Hitachi inspire the next manufactures railway motors as well as rolling stock. It may have the same specifications as Japan. If you don't think it's worth the cost, you might want to adjust the cost.
Using overload means that it actually consumes more power than the catalog specs.

QuoteAny specs I have found so far use m/s^2, or a graph, or time to reach 100 km/h (but that's mostly for fast personal cars).
When showing the starting acceleration in Japan, it shows the acceleration in the constant acceleration region. In other words, it is the acceleration up to the rated speed. Up to that point, the motor maintains a constant torque. After that, the torque is gradually lost. The derelict patch proved that Bernd Gabriel correctly simulated it.
When expressing the acceleration up to the speed exceeding the rated speed, it can be expressed only by an ambiguous measure of average acceleration. In that case you have to indicate the target speed.

I can't because I'm new to window manipulation code, but the dedicated graphs will help the player better understand.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、

(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべきである。らんらんはそれでやる気をなくした(´・ω・｀)

#### Sirius

Quote from: Ranran on May 26, 2020, 12:55:11 PMIf we use m/s/s unit system, I think the velocity unit should also be m/s.
In fact, in (central) Europe usual units are kind of a mess either...
In every-day-use, the speed unit is km/h, acceleration is usually given in m/s² or in a 0 to 100 figure, which is effectively in km/h/s, but I've never seen this unit written as such. Power of combustion engines is traditionally given in horsepower. Power of any other engine is given in Watts. Although, Watts do also get more and more common to combustion engines.

In physics, SI units are used quite consequently, which is speed given in m/s, acceleration given in m/s², power in Watt, weight in gram.
Engineering seems to conform to physics most times.

Locale specific unit translations is a good idea imho, although that might be dificult in online games.
Imagine someone had set this to use miles per hour, whilst another one is using km/h and yet another one is using m/s.
So what's that in mph or m/s? That would add some layer of complexity to communication.
Thus I am wondering if we adding SI values of such as a mouseover tooltip would be sensible.
I chose SI units, because it's common all over the world, although not the most usual unit in many cases and it's easy to understand relations of speed, time, distance, whatever in those.

#### Ves

Other games have the player select a preference and then everything is displayed in that meassure. Perhaps we could have a setting in the simuconf.tab where one can set the desired units of metric, and then this of corse will have to be ammended everywhere in the code where speed and acceleration (and perhaps even weight etc) are displayed.

Quote from: Ranran on May 26, 2020, 12:55:11 PMAt 0km / h the resistance is ignored. So I just converted get_force_summary into acceleration. get_force_summary was coded by Bernd Gabriel.
OK so what you do is basically get_force_summary() / get_weight_summary() * 3.6 ?    (Gear may be used already in get_force_summary?)

I found specs telling the (probably starting) acceleration of various vehicles. So I used that to calculate tractive force by simple F=m*a (/gear), but in the convoy details I get lower value. So there must be something more taken in account - I have to check get_force_summary(). Probably it takes rolling resistance into account, which is independent of speed. If so I would have to adjust all vehicles I touched so far (trams, electrostars).

Quote from: Ranran on May 26, 2020, 12:55:11 PMOriginally, to obtain TF from KW, the rated speed of the motor, gear ratio, and wheel size are required. You may just assume that KW to TF announces the correctly calculated result by the operating company.
It is extremely hard to come to that information. And if I have acceleration I do not need all that.

Quote from: Ranran on May 26, 2020, 12:55:11 PMIt has already been discussed in another thread late last year.
https://forum.simutrans.com/index.php/topic,19363.0.html  If we use m/s/s unit system, I think the velocity unit should also be m/s.
I was looking for that thread, but could not find it. I agree that for players imagination km/h/s might be easier. But I usually compare values relative to each other anyway. I just wanted to compare with real specs, if I have the tractive effort set right. So it is a minor inconvenience in debugging.

Quote from: Ranran on May 26, 2020, 12:55:11 PMFrom the above, I recommend adjusting the in-game acceleration using gear.
No. gear affects both power and tractive force, so fiddling with gear will change the power. We can usually find power from specs, so that is quite exact value. We do not know tractive force from specs (usually), so we have to calculate it from other sources. So if the vehicles do not behave as they should, we have to fix the calculation.

#### Sirius

Don't confuse real-world gear with simutrans gear.
Simutrans gear effectively is rather a loss ratio or something like that, adjusting force and power in the same way.

#### Milko

Hello

I would not give the opportunity to customize the units of measurement. Everyone would then use the same units of measurement to compare themselves also within the forum, we would lose the common language. We would also maintain the correlation with the data written in the paks.

Giuseppe

Ranran, can you point me, where in the code do you the conversion from get_force_summary to acceleration?
I can't find it. I found the definition of get_force_summary(speed) and digged furhter and get_force_summary(0) should give sum(tractive_effort * gear). No rolling resistance or anything. Yet you display a bit lower values: see the picture:

F=119 kN, m=172 t, a = 2.29 km/h/s
a = F/m = 119 kN / 172 t = 0.69 m/s/s (*3.6) = 2.49 km/h/s

So one of us made a mistake somewhere... Or we have a big rounding error...

#### Ranran(retired)

QuoteI found specs telling the (probably starting) acceleration of various vehicles. So I used that to calculate tractive force by simple F=m*a (/gear), but in the convoy details I get lower value.
Thank you for confirmation. I reaffirmed it. It seems that the rotary inertia resistance was set as a constant generally handled in Japan. It is just the wrong number being displayed. I fixed it. This should give you a higher display after a little acceleration.
`F=119 kN, m=172 t, a = 2.29 km/h/sa = F/m = 119 kN / 172 t = 0.69 m/s/s (*3.6) = 2.49 km/h/s`
It seems to agree with this calculation result.
I would appreciate if you could check it again.
@James - I have submitted a pull request for this fix. Please check pull request#183.

QuoteIt is extremely hard to come to that information. And if I have acceleration I do not need all that.
No, you may be missing information about how fast that acceleration lasts. The information is displayed as pulls .... t @ xxkm / h. Certainly it can be difficult to know exactly.
It will be revealed when the acceleration graph, acceleration time and distance traveled between stations are revealed.
But it may be a trivial problem, as it is not properly simulated outside of an electric motor. However, I haven't even seen any other paid game of this kind that simulates this behavior.
It's more than good enough.

QuoteNo. gear affects both power and tractive force, so fiddling with gear will change the power.
Catalog specifications will not change. That is the value found in the depot. It displays the value described in the dat file as it is. That is, the information that we can know in the real world. That's what we know in the real world. And the rated speed is determined without using fake TF with simutransic gear.
simutransic gear is used for numerical disguise.
Please note that the rated speed will change significantly if you rewrite the TF or power before impersonation. For example, a vehicle with a high-speed gear setting that accelerates to 100 km / h may change to a vehicle with a low-speed gear that decreases in acceleration after 50 km/h. The rated speed will decrease if TF is increased without changing KW in the dat file. So I recommended rewriting the simutransic gear.
This is how the TF changes in Bernd Gabriel's physics code, as shown by the patch buried in the tomb.

According to the chart, the rated speed of this vehicle is around 24km/h.
In that way, if you want to reproduce the actual train correctly, it is necessary to set the rated speed correctly.

People will also complain about the contradiction if they display specs that are spoofed in the depot. Then, is there a way to fix it using something other than simutransic gear?
For example, if the vehicle is overclocking twice as much as the catalog specifications, I think it's not a mistake to double the simutransic gear.

Well the problem is that the convoy detail displays the simutransized value, but it turned out to be a lot of work and was not achieved so far.

It should be noted that making the unit variable in the setting affects a lot of places such as the chart, and thus requires a lot of effort.
Also, considering the size of the map, I think the unit of m is too small.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、

(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべきである。らんらんはそれでやる気をなくした(´・ω・｀)

Quote from: Ranran on May 27, 2020, 09:37:49 AMrotary inertia resistance
I completely forgot about that. And AFAIK the physical model in simutrans ignores rotary inertia (of wheels, axles and motors).

Quote from: Ranran on May 27, 2020, 09:37:49 AMsimutransic gear is used for numerical disguise.
AFAIK simutrans gear should be renamed to efficiency. It is there to express the loss of power in transmissions. E.g. you have a diesel-electric engine with diesel motor rated at 700 kW, but due to losses in conversion to electric and back to mechanic you lose some part of the power. Even purely electric engine does not have 100% efficiency, consuming more power than delivering to wheels. And for that is used the gear - so that we can show the catalogue (rated) power in depot. IMHO gear should not be applied to tractive force. But for now we have to compensate by faking the simuTF = realTF/gear.

I know examples of railway engines that differ only in transmission rates (gear) so that one model has higher top speed but at the cost of reduced tractive effort compared to the other model. Yet they have the same motors = same power in kW. But this has nothing to do with simutrans gear. This can be perfectly implemented by setting appropriate tractive force. Moreover, you can't achieve that by changing simutrans gear.

Quote from: Ranran on May 27, 2020, 09:37:49 AMPlease note that the rated speed will change significantly if you rewrite the TF or power before impersonation.
I'm not sure I understand.  Please what you mean by "rated speed" and "impersonation". Neither of us two is native English speaker so this may be some linguistic problem...

The acceleration found in most specs is the max acceleration, so using that we get max TF. The speed where the acceleration (and TF) starts to fall (is that what you mean by rated speed?) depends on power, so I'm leaving that to the physics model of simutrans. At the moment I do not really care. But I have found some acceleration graphs, so if the graph is ever implemented in simutrans, we can check how good the physics model is. BTW what is the dark green line in the graph?

Quote from: Ranran on May 27, 2020, 09:37:49 AM@James - I have submitted a pull request for this fix. Please check pull request#183.
Could you explain what is that magic constant you changed?

#### Sirius

#13
What Ranran means by rated speed (at least he used it like this in the past) is the speed at which the machine will switch from being a constant-force machine to a constant-power machine, or in different words, the speed above which the force will start decreasing.

Although, technically the rated speed is something different, at least if my translation is correct, it's calles "nenndrehzahl" in German, which is the drive (usually in rpm) at which an engine can output its maximum power.

What "impersonate" means here is not clear to me either.

Quote from: Vladki on May 27, 2020, 03:17:05 PMBTW what is the dark green line in the graph?
That's the counter force. Notably air resistance.
The actual force causing the acceleration is the difference of the blue and green line.
When the green line hits the purple line, the acceleration will be zero.

So after the magic constant change, the acceleration is reported higher than expected. (EDIT - only for trams ... )

Ranran, could you please explain the formula you use to calculate acceleration? I see that you made new function for this purpose:
uint32 convoy_t::calc_acceleration(const weight_summary_t &weight, sint32 speed)
{
return ((get_force_summary(speed * kmh2ms) - calc_speed_holding_force(speed * kmh2ms, get_adverse_summary().fr))/g_accel).to_sint32() * 1000 / 28.35 / weight.weight * 100;
}

I digged further to see what is done. Now I will assume that speed=0, and weight is the empty weight.
get_force_summary(speed * kmh2ms) = tractive_effort * gear (in kN) at given speed. At 0 km/h it gives the max tractive_effort.

BUT you call calc_speed_holding_force(speed * kmh2ms, get_adverse_summary().fr)  with wrong arguments. The second argument should be Frs = Fr + Fs = rolling_resistance_force + slope_resistance_force. But instead of force, you send only to rolling_friction_factor. fr = rolling_resistance/10000   (i.e. for electrostar it is 13/10000). So then you are subtracting apples and pears...

I think your formula should be a = (F - Fr)/m = (F - fr*g*m)/m

return ( (get_force_summary(speed * kmh2ms) - calc_speed_holding_force(speed * kmh2ms, get_adverse_summary().fr * g_accel * weight.weight).to_sint32() / weight.weight );

I dont understand why you do * 1000 / 28.35 * 100 ?

#### Ranran(retired)

Quote from: Vladki on May 28, 2020, 09:48:36 PMI dont understand why you do * 1000 / 28.35 * 100
1000^2/(3600*9.8）

Quote from: Vladki on May 28, 2020, 09:48:36 PM(EDIT - only for trams ... )
Road vehicles may use different functions. If so, I haven't changed it.
I would appreciate it if you could give a reference example to show a good example of road vehicles.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、

(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべきである。らんらんはそれでやる気をなくした(´・ω・｀)

#### Ranran(retired)

#16
QuoteIMHO gear should not be applied to tractive force.
As I have said many times, to achieve that must be rewritten by someone who has a solid understanding of Bernd Gabriel's physics code.

QuoteBut for now we have to compensate by faking the simuTF = realTF/gear.
You have to understand what happens by changing simuTF.

Rated speed is reproduced in simutrans extended. This is probably from the time Bernd Gabriel wrote the physical code.
It has been possible to check it for a long time as shown below.

As shown in the acceleration chart above, the acceleration decreases when this speed is exceeded. This is the characteristic of a real world electric motor.

I give you examples.

The pink line is the dat file description of the current performance of this vehicle.
The yellow vertical line is the current rated speed.

(1)If you only increase the TF. The line changes like yellow-green.
(2)If you only increase the power. The line changes like blue.
(3)If you only increase the gear. The line changes like red.

Which gives you closer results to what you want to achieve?
Notice the change in rated speed.

The balance between power and TF is the real world gear ratio itself.

By changing this balance, it behaves as if the real gear ratio changed.
For example, if you raise only the class 800 TF, it will not be able to drive at high speed like the commuter train. Because the force at high speeds weakens.
But the acceleration display will go up. This is because it actually exerts a large force up to the rated speed. Then is the acceleration better overall?
In the real world, trains for short distances are intentionally set like this.

Is it a gear setting for high speeds? Is the gear set for commuters? It is currently recommended not to change this balance if it is reproduced correctly.
It's not good to stick to starting acceleration value alone.
If you don't want depot to display the wrong value for power, you can only change simutransic gear.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、

(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべきである。らんらんはそれでやる気をなくした(´・ω・｀)

Quote from: Ranran on May 29, 2020, 11:21:37 AMWhat are your goals?

My goal is to set the power, tractive_effort and brake_force of vehicles as close to reality as possible. (And of course have them to behave as realistic as possible.)
The problem is that the specs I could find do not tell tracive/brake force, but only maximum acceleration/decceleration.
So I used simple F=m*a, to calculate it, and see that the value you are showing in details is different. So I want to find out what's wrong. So far I found these bugs:
- I did not take rolling_resistance into account.
- You use rolling_friction_FACTOR, in place where rolling_friction_FORCE is expected (to calculate acceleration)
- rolling resistance shown in depot is 1/10th of my expectation (Fr = m * g * fr) where fr = rolling_resistance/10000

My approach is:
- (simutrans) gear is fixed = 0.8 for electric; 0.5 for diesel
- power from specs is copied to dat file as is.
- tractive/brake force has to be calculated from acceleration, weight, number of powered/braked axles, (and rolling resistance).

Expected result - the details window should show the same acceleration as is given in specs.

Quote from: Ranran on May 29, 2020, 11:21:37 AMYou have to understand what happens by changing simuTF.
Is it a gear setting for high speeds? Is the gear set for commuters? It is currently recommended not to change this balance if it is reproduced correctly.
I do not want to change it just for fun... I want to find the correct value. And I think that in most cases, what is entered is just a wild guess. For some vehicles I even fixed the power according to specs, so the TF was indeed just a random number. I want to find the value when it will behave as the real vehicle does.

QuoteRated speed is reproduced in simutrans extended.
Thanks for explaining. I never thought that that speed is somehow special.

Quote from: Ranran on May 29, 2020, 11:21:37 AMIt's not good to stick to starting acceleration value alone.
I usually do not have anything else. So at least having starting/max acceleration right will bring us forward.
We can then do further refinement for those few vehicles where we have the acceleration curve. But we usually do not have that.

Quote from: Ranran on May 29, 2020, 08:37:18 AMIf you don't want depot to display the wrong value for power, you can only change simutransic gear.
Depot show the ungeared power, details show both, so it is not a problem. I'm fine with setting the specs power in dat file and have the gear applied to it. I think that is what was intended anyway.

Quote from: Ranran on May 29, 2020, 08:37:18 AM1000^2/(3600*9.8）
but WHY?? a = F / m .... there is no place for g = 9.8 in that...  Once again:
a = F / m
m = weight
F = Fm - (Fr + Fa + Fs)
Fm = tractive_effort / gear = get_force_summary(speed * kmh2ms)
Fs = slope resistance = 0 on flat track
Fa = cf * v * v (air resistance) = 0 for starting accel
Fr = m * g * fr (rolling resistance on flat track)
fr = rolling_resistance / 10000
(Fr + Fa + Fs) = calc_speed_holding_force(speed, Frs) expects the second argument to be Fr+Fs (force), but you feed it with fr (friction factor). And then you do some funny magic with g_accel and 28.35. The only magic constant that should appear is 3.6 to convert from m/s/s to km/h/s

Quote from: Ranran on May 29, 2020, 08:37:18 AMRoad vehicles may use different functions. If so, I haven't changed it.
Trams are not road vehicles, but let's have a clear example:

BR-class 375
https://eversholtrail.co.uk/fleet/class-375/
power = 2 (axles) * 3 (cars) * 250 kW = 1500 kW * 0.8 = 1200 kW (details say 1195 kW) - some rounding error?
tractive_effort = 2 * 3 * 44 kN = 132 kN * 0.8 = 105.6 kN (details say 105 kN) - good
empty weight = 46+40+40+46 = 172.0 t
max acceleration in specs = 0.62 m/s/s. Check 132 kN * 0.8 / 172 t = 0.614 m/s/s * 3.6 = 2.198 km/h/s (details say 2.19 km/h/s)

OK. now it fits... I'm confused now... But yesterday I did a lot of checks, maybe with other vehicles and it did not fit....

And that was without friction at all... If friction is added we get more fun:
rolling_resistance (factor) = 13
rolling_resistance (force) = 46*9.81*13/10000 = 0.587 kN (depot display = 0.060 kN) - 10x less?
rolling_resistance (force) = 40*9.81*13/10000 = 0.510 kN (depot display = 0.052 kN)
Moreover the powered 40 t vehicles declare resistance 0.060 kN too. But only for class 375. Other classes are OK.

Applying the friction reduces the tractive force by 2.193 kN so the acceleration would be 2.164 km/h/s

Still the calc_acceleration code is imho really adding pears and apples. I can't say how much the result is affected byu rounding errors or using wrong friction values...

#### Sirius

#18
Quote from: Vladki on May 29, 2020, 05:25:18 PMAnd I think that in most cases, what is entered is just a wild guess.
You don't just think this, it was confirmed that most starting forces were roughly guessed, based on forces of other vehicles.

I couldn't find an error in Vladkis calculations, so I'd assume there is an error in calc_acceleration.

#19
Just a few others for comparison:

BR class 376:
Power = 3*600 = 1800 kW * 0.8 = 1440 kw (display 1434 kW)
TF = 3*50 = 150 kN * 0.8 = 120 kN (display 119 kN)
weight = 172 t
rolling resistance = 13 (same as BR-375)
acceleration (without friction) = (150*0./172*3.6 = 0.700 m/s/s = 2.512 km/h/s  (specs = 0.66 m/s/s, display = 2.49 km/h/s)
acceleration (with friction) = (150*0.8-(172*9.81*13/10000))/172 = 0.685 m/s/s = 2.466 km/h/s

Tram T68
Power = 2*210 = 420 kW * 0.8 = 336 kW (display 334 kW)
TF = 2*40 = 80 kN * 0.8 = 64 kN (display 63 kN)
weight = 2*24.5 = 49 t
rolling resistance = 60 (force per articulated piece: 24.5*60/10000*9.81 = 1.442 kN (display 0.147 kN)
acceleration = 2*40*0.8/49 = 1.306 m/s/s = 4.702 km/h/s (specs = 1.3 m/s/s, display = 4.67 km/h/s)
acceleration with friction = ((80*0.-(49*60/10000*9.81))/49 = 1.248 m/s/s = 4.490 km/h/s

So as you can see now, the displayed values for acceleration are somewhere between the value calculated with friction and without. That leads me to conclusion the calculation is wrong.

EDIT:
OH, and probably the biggest mistake - convoy_t::calc_acceleration returns unit32 Integer??? for values generaly 0 - 5.5 km/h/s ? (0 - 1.5 m/s/s which is the comfortable range?)

EDIT2
Diging deeper - starting to prepare a fix of that code so that it does not use doubles but float32e8_t
Just tracing if the power in details window is show correctly is crazy:
get_sum_power() / 1000 = get_continuous_power() = get_power_summary(max_speed) = get_effective_power_index(max_speed) = geared_power[(max_speed)] = power * gear... Hmmm, wonder whether there is some rounding or type conversion on the way, or just simply wrong use of gear and GEAR_FACTOR (64) somewhere...   OMG this is complicated...

EDIT3
Probably found why the rolling resistance was 10x lower. In gui_convoy_assembler.cc line 1063, there is (rolling_resistance * (double)total_empty_weight / 1000.0)... Mhmmm, should be * g_accel, which is approximately 10   Now to check if it is a bug only in the display or also in the physics code...

EDIT4
Patch prepared - I rewrote the functions to minimize type conversions. All calculations are done in float32e8_t, conversion to double or int only for display.
Also renamed convoy_t::calc_acceleration() to convoy_t::calc_acceleration_info() because there already exists convoi_t::calc_acceleration() that does something completely different.
https://github.com/jamespetts/simutrans-extended/pull/184

EDIT5
More fixes and tests. Test with BR-319 on straight flat track, no load, accelerates to full speed at 6-tiles longer distance than calculated.
So we have to deal with extra "friction" (default=4 for roads, dafault=1 for everything else) which is applied in similar way as slopes and curves.
But that is imho a leftower from standard, which does not have rolling_resistance at all.

@James, did you set rolling_resistance of various vehicles according to real world values for wheel/rail or tyre/road values?
Default are defined in vehcle_desc.h:
case track_wt:
case monorail_wt:      return 15L; //0.0015 when read
case tram_wt:         return 60L; //0.006 when read
case narrowgauge_wt:   return 17L; //0.0017 when read
case air_wt:
case water_wt:         return 10L; //0.001 when read
case maglev_wt:      return 13L; //0.0013 when read
default:
Most modern rail vehicles have rolling_resistance=13

So the question is if the old friction should be set to 0, and used only for additional friction caused by corners and slopes, or kept as hidden increase of friction even on flat straight track?
IMHO this could be also the reason why road vehicles struggled on slopes and have a special exception making slopes less steep for roads.

And as a further improvement, this friction could be reworked to depend not on whole waytype but individual way - so that dirt road has higher friction than asphalt road, or continuosly welded track lower friction than classic.

#### Ranran(retired)

#20
I was stuck with the magic number 30.9 used in Japan and it was strange. Certainly the formula was wrong. I'm sorry.
Thank you for taking a closer look.

`uint32 convoy_t::calc_acceleration(const weight_summary_t &weight, sint32 speed){ const float32e8_t Frs = g_accel * (get_adverse_summary().fr * weight.weight_cos + weight.weight_sin); return (get_force_summary(speed * kmh2ms) - calc_speed_holding_force(speed * kmh2ms, Frs)).to_sint32() * 360 / weight.weight;}`
Isn't it enough just to fix it like this?

Quote- (simutrans) gear is fixed = 0.8 for electric; 0.5 for diesel
No. There is no such thing in the real world.
The simple story is that the efficiency of motors is different between manual transmission and automatic transmission. The history of diesel cars(DMU) is similar.

I'm sorry in Japanese, but it is also described in detail on wikipedia
https://ja.wikipedia.org/wiki/%E6%B0%97%E5%8B%95%E8%BB%8A%E3%83%BB%E3%83%87%E3%82%A3%E3%83%BC%E3%82%BC%E3%83%AB%E6%A9%9F%E9%96%A2%E8%BB%8A%E3%81%AE%E5%8B%95%E5%8A%9B%E4%BC%9D%E9%81%94%E6%96%B9%E5%BC%8F

QuotePower transmission system for diesel trains and diesel locomotives

Mechanical
It is a system that combines a clutch and a mechanical transmission (gearbox), similar to the "manual transmission" in automobiles. In the 1900s and 1920s, a method using a manually selected sliding type transmission and clutch that diverted the powertrain of the car at that time was adopted, and this method was also adopted in Japan.

Especially in Europe and its former colonial diesel cars, this method became popular at that time, and one-car two-engine vehicles and heavy-duty general control were put into practical use in the 1930s. It has been put to practical use.

Among the mechanical type, the advantages and disadvantages of the manual type are as follows.

Pros
- Simple structure, small size and light weight.
- Low cost.
- There is almost no power loss, and the power transmission efficiency is extremely high, over 95%.

Cons
- Skillful operation is required.
- It is difficult to use for high-power engines because of the pressing force of the clutch plate and the strength of the gears.
- As it is, it is not possible to remotely control the transmissions of multiple vehicles, so a driver is required for each vehicle when connected, which goes against rationalization.
It says "the power transmission efficiency is extremely high, over 95%." This is also mentioned in some of the rail magazines I have.
Also
Quote
Case in Europe
In Europe, it has been adopted mainly for diesel trains operated in short trains, and has been used for excellent trains since the 1930s. Especially in England and Italy, production was continued until the 1970-1980s.

In the 1970s, in the 1970s, most of the general diesel-powered vehicles were occupied by mechanical systems that had general control functions, and were driven by formations that included ancillary vehicles and control vehicles.

And the most common diesel:
Quote
Liquid type (fluid type)

A method that uses a torque converter for power transmission of a vehicle. It used to be called a hydraulic type, but it has come to be called a liquid type since the introduction of a hydrostatic drive system.

~ Omitted ~

Pros
- When used on diesel trains and small locomotives, it is less expensive, lighter, and more compact than the electric type. Since it is lighter than the electric type, the axle weight is light and it is possible to enter a branch line.
- Overall control is possible.
- It is easier to drive than the mechanical type.
- The traction force at start-up is large compared to the electric type of the same scale.
Cons
- The structure of the transmission is extremely complicated and expensive.
- A large amount of transmission fluid (automatic transmission fluid) is required, and quality control and assembly of seals were previously a problem.
- Loss due to slippage inside the torque converter is unavoidable, and power transmission efficiency is around 80-85%, which is slightly inferior to the electric type.
- Inferior to electric type in adaptability to high power engine
- Since it is necessary to suppress overheating of the transmission fluid, it is not suitable for long-term power running in the gear position.
In Japan, this system has been adopted since 1950 and most of the time, since it was evaluated for its comprehensive control.

I omit it, but in recent years, another evolution has been progressing.
For example, there used to be a diesel engine that generates electricity to turn a motor, but the motor at the time was heavy and uncommon, but it has started to spread recently.

And motors are evolving day by day, and efficiency cannot be fixed. And how do you deal with changing the current limit value as I have shown in the example?

The simplest solution I can think of is to split the simutransic gear in two. Divide like efficiency and load factor. But I don't see the benefits of doing it.

EDIT:
Use the vladki's one. I haven't checked in detail.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、

(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべきである。らんらんはそれでやる気をなくした(´・ω・｀)

#### jamespetts

Thank you for the research. May I ask - in the "over 95%" case, does it mean that over 95% of the engine's rated power is power actually available at the wheels?

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

#### Ranran(retired)

Quote
Thank you for the research. May I ask - in the "over 95%" case, does it mean that over 95% of the engine's rated power is power actually available at the wheels?
Power transmission efficiency seems to have the same meaning in all the literature. I think that I have the power to be finally transmitted. That is, the wheels.
The English translation of "動力伝達効率" becomes "power transmission efficiency", but I don't know if it is translated correctly.
Japanese definition of "動力伝達効率"
QuoteThe power transmission efficiency is the ratio of the output from the engine to the output finally transmitted to the drive wheels via the entire power transmission device. In the actual calculation, the loss generated in each power transmission device is taken into consideration, and the effective torque (or horsepower) obtained by subtracting the loss is used for the calculation.
https://www.weblio.jp/content/%E5%8B%95%E5%8A%9B%E4%BC%9D%E9%81%94%E5%8A%B9%E7%8E%87
Quote動力伝達効率

The gears and bearings of the clutch, transmission, joints (constant speed, universal, etc.), propeller shaft, final (final reduction gear), etc. that make up the power transmission device are lost due to friction, shock, agitation of lubricating oil, etc. Occurs. The ratio of the effective torque or horsepower minus the loss to the engine output (torque or horsepower) is called power transmission efficiency.

It should be noted that Bernd Gabriel's physical code faithfully reproduces the basic properties of electric motors.
The engine and the motor draw completely different acceleration curves. So I thought it was considered half of a motor.

Diesel engines draw a curve like light blue. Diesel also has gears.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、

(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべきである。らんらんはそれでやる気をなくした(´・ω・｀)

Quote from: Ranran on May 30, 2020, 02:16:13 PMIsn't it enough just to fix it like this?
Probably Yes. I'm thinking about adding back the weight.weight_cos and weight.weight_sin. But there' one thing you should keep in mind:

Avoid unnecessary type conversions. To keep maximum precision, convert input from whatever you have to float32e8_t and basic SI units (m, s, kg, W, N, ...) and do all the calculations with them. Conversion to other units (e.g. m/s -> km/h; W -> kW;) and from float32e8_t to double or int, should be done only when displaying the value to player. Internally it is best to keep everything in the basic units in float32e8_t. That makes the calculations more understandable. Using magic constants like 35.31 (= g_accel * ms2kmh) is confusing.

Quote from: Ranran on May 30, 2020, 02:16:13 PM- (simutrans) gear is fixed = 0.8 for electric; 0.5 for diesel

No. There is no such thing in the real world.
The simple story is that the efficiency of motors is different between manual transmission and automatic transmission.
I agree - this is just a rough estimation. I also think that the 0.5 for diesel is quite low. That is exactly why I think that gear should be renamed to efficiency and applied only to power, not tractive effort. Then we could adjust gear according to real world data on case by case basis.

#### jamespetts

The 95% transmission efficiency seems inconsistent with other information that I have in the past used for calibration, so great care needs to be taken to make sure that we are measuring the same thing in the same way. If there is a radical difference in transmission efficiency from 95% in some cases to 50% in others, we will need much more detailed research to find where on the spectrum that various vehicles fall.

The story behind the use of gear in this way in Simutrans-Extended is worth retelling here as it is significant in this discussion. Initially, when Bernd Gabriel developed the new physics engine in circa 2011-2, gear was not used. However, after a while, it was found that low powered, very light vehicles were performing a lot worse than they ought to be performing. After some investigation, Bernd explained that he had set the air resistance constant in the algorithm to a much higher value than his sources indicated was realistic because, with a realistic value, he was not getting realistic performance (and he was testing more powerful, heavier vehicles/convoys).

We eventually worked out that the extra air resistance was actually a proxy for transmission losses and that we got much more realistic behaviour in both high and low powered vehicles if we used the real value for air resistance and used the "gear" in internal combustion engine and electric vehicles to simulate transmission loss. After some research, appropriate figures appeared to be 50% for internal combustion engines and 80% for electric motors. 100% was used for steam engines since the engine and the locomotive is one and the same, and, in any event, steam engine power had to be inferred and extrapolated rather than simply recorded as only tractive effort figures were generally recorded and known for steam locomotives.

I cannot now immediately recall the sources for the 50% and 80% figures (as will be imagined, there is an element of approximation, but it was thought better to use these universally since (1) no per vehicle transmission loss information was available; and (2) making them universal made it easier to compare different vehicles), but there should be a discussion in the forum about this somewhere in the 2011-2014 period, and these figures were both definitely based on research from a reputable source. I would need to understand fully the reason for the inconsistency between the sources and have found an evidence based way to reconcile them before making use of apparently contradictory data.

I should note in particular that one of the vehicles that was noted to be performing incorrectly with the original air resistance figure was the GWR railcar, which is a diesel engined single car rail vehicle with a mechanical transmission. Rail vehicles with mechanical transmission were common in the UK from the 1950s until the early 2000s, and the GWR railcars had been in use from the mid 1930s until the early 1960s, so the category of rail vehicles with mechanical transmissions is a large one.

At the time that this was done (or possibly even before this: I cannot recall now), the English translation text for "gear" was changed to "power output ratio", chosen over "efficiency" because the figure is shown as a ratio rather than as a percentage. This translation remains even now.

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

#### Sirius

#25
95% efficiency is a reasonable number to the ratio of the power measured at the engine to the power measured on wheels.
It does definitely not include engines efficiency itself, however.
Diesel-electric and Diesel-hydraulic engines will be much less efficient in this matter than Diesel-mechanic.

However, I am not quite sure if the gear aims to represent engine-to wheel losses or does also include engines efficiency itself. (including transforming and so on in case of electric engines)

However, the statement about steam engines rather indicates we don't care about engines efficiency itself but only about engine-to-wheel losses.
The actual efficiency of a steam engine is not even close to 100%, although the engine-to-wheel efficiency might be somewhere around 95% to 99%, so assuming 100% here is not too bad.

Still, Ranran is correct. No matter, what exactly the gear value should demonstrate, it's not a constant.

The reason why most modern diesel trains are diesel-electric is because of the rather huge power and forces, resulting in uneconomically huge wear of mechanical clutches.
In case of diesel-electric engines, further advantages are high starting forces and the ability to run the diesel engine in range of its best efficiency, which can partly compensate the losses of converting mechanical energy to electrical engergy and back to mechanical energy.

Some smaller engines do still use diesel-mechanic engines, for above given reasons.

I don't see the difference in a ratio and a percentage. It's technically the same.
Don't know when I last wrote 80% instead of 0.8 or 8/10

#### jamespetts

The thermal efficiency of the engine is not what we are looking at with "gear", as the rated power of the engine that we use for "power" already takes this into account. Thermal efficiency is more relevant for steam engines, where I have to use an estimate of this to work out the power (for steam engines, this is usually 4-7%, and less for earlier engines), and it is also relevant for fuel consumption where these data are not directly available.

If there is a large difference in the power transmission efficiency between diesel mechanical and diesel electric or hydraulic (or even petrol electric, as some early 'buses were - and we have some in Pak128.Britain-Ex), then I need to know about it, but I really need both efficiency figures coming from the same source, since I am concerned that the 95% figure is not readily reconcilable with the 50% figure.

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

#### Sirius

#27
In contrast to steam and diesel engines, it sems like electric engines power ratio of 0.8 is related to catenary-to-wheel ratio instead of engine-to-wheel ratio.
I have just found a source stating 87% catenary-to-wheel efficiency of an ICE3 BR403 train, according to this shet, which is part of a 53 page long presentation of the Deutsches Kupferinstitut ~German Copper Institute
https://image.slidesharecdn.com/bahneffizienz-100731040206-phpapp02/95/wie-energieeffizient-ist-der-bahnverkehr-wirklich-30-638.jpg?cb=1508506575

I'm currently trying to validate this with a further source, as I've never heard of that institute before.

In any case, a loss of 20% on the connection from the enginge to the wheel seems unreasonably huge, as many types of electric engines are quite closesly tied to the axle.

Edit:
According to a more detailled paper of the Kupferinstitut https://www.kupferinstitut.de/wp-content/uploads/2020/02/BahnEffizienz.pdf
QuoteBei
einem Wirkungsgrad von 95% für den Fahrzeugtransformator, 95% für die Fahrmotoren,
98% für die Umrichter und 98% für die Zahnradgetriebe ergibt sich ein Gesamt-Wirkungsgrad von knapp 87% ab Stromabnehmer für den Antriebsstrang innerhalb des Fahrzeugs.
At an 95% transformation efficiency, 95% engine efficiency, 98% converter efficiency and 98% gearing box efficiency, the overall efficiency from the catenary to the wheels results in a little less than 87%

this suggests a simugear of 0.97 in case of the closely related eurostar e320 and very likely other electric vehicles of the same age and the same engine type are not very far from that.
Although this does still need another document in support.

#### jamespetts

Freahk - thank you for that. The 80% was, I recall, from a specific source, and the actual performance appears to be broadly correct with this being used. I will need to understand fully how this apparent discrepancy arises, including finding the original source and analysing in detail actual performance in game matched with real performance over a large range of vehicles with both figures, before I can sensibly deal with this. This may take a very considerable time indeed, and is a lower priority than a large number of current tasks.

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

James, thanks for this history excursion about gear. Do you remember some similar discussion about: `base_friction = get_friction_of_waytype(waytype)` and `rolling_resistance = get_rolling_default(desc->wtyp)` -- as they seem to me to be somewhat duplicate...

#### jamespetts

Quote from: Vladki on May 31, 2020, 05:30:20 PM
James, thanks for this history excursion about gear. Do you remember some similar discussion about: `base_friction = get_friction_of_waytype(waytype)` and `rolling_resistance = get_rolling_default(desc->wtyp)` -- as they seem to me to be somewhat duplicate...

I cannot now recall why there should be a duplicate here; do they produce the identical number? If so, then it might be worth combining them. If not, then further investigation will be required.

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

They do not produce the same number (they are added together at the end), but seem to simulate the same thing. Friction is in standard, as well and is used to simulate not only friction but also slowdown on hills and corners. In extended corners have their speed limit, and increased friction in corners is applied only to trams. But even that is quite small. So the main use for friction in extended is slopes. The friction on flat way should be defined using rolling resistance. So I would propose to set default friction of all ways to 0, and check if rolling_resistance is correct for given wheel/way combination. Then this could be extended to simulate different way qualities.

#### jamespetts

Thank you for the clarification - in which case, there is a good reason for these to remain separate, as one is based on a Standard feature which has been retained and one is Extended specific.

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

#### Sirius

I have never noticed a friction caused slowdown of trams in curves.
Is that practically noticeable in old times?

#### jamespetts

Quote from: Freahk on June 02, 2020, 09:49:02 PM
I have never noticed a friction caused slowdown of trams in curves.
Is that practically noticeable in old times?

Yes, I think that modern trams are too powerful for this to be noticeable. You are more likely to notice it with steam or horse trams.