[pschlik]

Erick mentioned problems with wheel slip and excessive wheel speed in the 2021 wish list thread. As I had also experienced this problem and considered the effect very unrealistic, I was motivated to investigate further and compile a reasonable bug report.

First, the problem: When weel slip occurs (and with no AntiSlip or ORTSWheelSlipCausesThrottleDown parameters active), the speed of the locomotive's wheels increases a lot. Using a TrainSimulations GP38-2 with the speedometer tweaked to show speeds up to 10,000 mph, we can see that wheel slip results in incredibly excessive speeds at the wheels. I hope we can all agree this should be completely impossible. (Note that this test was performed with 100% adhesion factor correction, and the train brakes applied to prevent the thing rolling away on me.)
https://i.imgur.com/03EHN8Q.png

Oddly enough, I find it impossible to get a speed in excess of 2237 mph. However, this is exactly 3600 kph, or 1000 m/s, which is too convenient of a number to be anything other than a hardcoded limit. (And as Erick mentioned, this is roughly Mach 3.)

For reference, the TrainSimulations physics means this GP38-2 will normally stop putting out power completely at 190 mph. When it wheel slips, I would expect the speed of the wheels to never exceed 190 mph as without traction at 190 mph, the wheels shouldn't be able to slip up faster than that.
https://i.imgur.com/ExvWA6o.png

Obviously, the sim isn't always preventing tractive effort above 190 mph, otherwise, wheels wouldn't slip up to Mach 3. For some reason, the GP38-2 is not allowed to produce any traction above 190 mph when driving normally but is allowed to produce traction above this speed when slipping. This definitely doesn't make sense, and as the HUD shows, results in quite an impressive horsepower output for a locomotive that should only be capable of 1,700 horsepower at rail.
https://i.imgur.com/Cne9XJq.png

And here's what I think is the explanation: It would seem that whatever bit of code that decides how much traction a locomotive can produce is mistakenly using the "true" speed (radar speed/speed the HUD displays/whatever you want to call it) of the locomotive as the input to the tractive force curves when it should be using the wheel speed as the input. This can be verified by looking at the axle drive force, which will display the expected force output not for 2237 mph, but for 0 mph (or however fast the train is moving.)
https://i.imgur.com/JNyxnyN.png


This is a fairly simple mistake, likely just use of the wrong "speed" variable, and is an understandable assumption to make as the true speed and wheel speed are usually equal or close to equal. However, by definition, this assumption is wrong during wheel slip and produces inaccurate results during wheel slip (hence, this bug exists).


And the solution: To resolve this, the code should be changed to check tractive force curves against the current speed the wheels are rotating at, rather than the speed of the locomotive itself. This will improve the accuracy of the simulation, as in real life the tractive output of a locomotive is limited by the back EMF of the motors, which depends on the speed the motors are rotating at, and not the speed at which the locomotive is itself moving.

Hopefully, this change could make wheel slip more manageable and less physics-defying. Though I still agree that a larger rework of diesel electrics is required to even have a chance of realistic wheel slip simulation, this right here is a good place to start.


By the way, this is NOT a problem on the stable 1.3.1 version of Open Rails! Wheel slip is actually much easier to manage in the stable version as tractive effort depends on the speed of the wheels (just as it should), so something was changed in unstable releases since then that has broken physics. I would go searching for the exact version where this was introduced but I suspect someone else knows more than I do about where to look for changes that may have introduced this bug.
https://i.imgur.com/iLRS3fs.png
https://i.imgur.com/tVs4qp7.png

[Jean-Paul]

Hi,
I think I'm not alone to have noticed serious inconsistencies since stable 1.3.1. !
Wheelslip seems random : with almost same axle weight, and same tractive effort, differences between axle drive force and axle out force may vary from 2.5 % up to 8 %....
You can also read my post on bug in follow-up of tractive effort curves with testing version 1.3.1.296 (and certainly older ones)
Cheers,
Jean-Paul

[pschlik]

Jean-Paul, on 20 February 2021 - 03:17 PM, said:

Wheelslip seems random : with almost same axle weight, and same tractive effort, differences between axle drive force and axle out force may vary from 2.5 % up to 8 %....

Funny you mention that, I also noticed the same oddities between axle drive force and axle out force, and I believe there are some serious faults in the force simulation. I am writing up another post about that issue right now and should have it posted in a few hours.

[scottb613]

Hi Folks,

Hah - you should see the wheel slip on a steam locomotive where it's really noticeable. Have a Trello card in on that one myself...

Regards,
Scott

[pschlik]

scottb613, on 20 February 2021 - 05:01 PM, said:

Hah - you should see the wheel slip on a steam locomotive where it's really noticeable. Have a Trello card in on that one myself...

The effect is definitely more spectacular on the steamers, but the steam locomotives don't generate quite as much easy to dig into data. It's a bit easier to prove my point numerically with the diesel locomotives, and we all know how it's all about the numbers.

[steamer_ctn]

Before making any changes I want to ensure that I have a good understanding of how things are supposed to work.

Firstly I believe that we are talking two different scenarios, ie:

i) Normal Operation - no wheel slip
ii) Wheel Slip

Secondly, as I understand it, OR uses the Advanced Adhesion (Wheel Axle) model to represent the impact of the forces on the locomotive wheels due to wheel slip, etc. In real life the diesel engine, generators, etc would be providing the input force into this model, and so this force would be related to the output of these components, not the wheel or train speed.

In OR the Axle input force is provided by the tractive force curves, which in reality is not 100% correct as these curves are supposed to represent the actual force between the rail and the wheel. The OR Axle model in most instances reduces the input force as the wheel speed changes (allowing correction for minor wheel slip), hence we will never achieve the "stated" rail force specified in the tractive curve. Provided we keep the errors a low as possible, this is probably not a big issue.

In some situations the wheel speed and the "real" train speed are the same, so the reduction in force to the rail is minimal. However in some instances the difference in speed between the wheel speed and the real speed can be larger. I have made the wheel speed visible in the HuD to allow some visibility of it. The video posted by hroc shows some instances where there is a difference between the two speeds.


Normal Operation - So initially looking at scenario i), where there is no or "minimal" wheel slip (which is normal) , the input force should be calculated from the TE curve using the the real train speed. If the wheel speed is used in this instance then the input force will initially be corrected for any minor wheel slip, and then this force will be further corrected within the Axle model. V1.3.1 was doing this double correction in the normal operating condition.

Wheel Slip - So if we start by considering an early generation DC diesel locomotive without any slip control fitted, what happens when wheel slip occurs?

Initially the friction between the wheel and the rail will dramatically decrease and effectively the wheel will have "no load" to balance the driving force on it. If wheel-slip occurs on a Series-wound DC drive, there is the tendency for the traction motor to speed up and run away, even to the point of mechanical failure if the power is not reduced quickly. The driving force (or input force in our situation) will remain the same until it is changed by some action. In the case of an early diesel, typically the driver would be expected to reduce the throttle position as soon as possible to reduce the force applied to the wheel. So in this instance perhaps the current operation is realistic, perhaps all that is needed is a failure mode to represent the mechanical failure of the motors at excessive speed?

The above scenario may vary where the traction motor is an AC. So depending upon the transmission type, ie DC, AC, hydraulic, etc, there may potentially be different responses, eg from full motor runaway (excessive speed on the wheel), to a more controlled scenario perhaps with an AC motor (due to back EMF?).

So if the wheel speed is used in the slip scenario, it will be adjusting the input force down (as you suggest), and therefore what reduction mechanism are we modelling in OR by doing this? Are all different locomotive traction types catered for with this type of approach? What about Electric Locomotives? What about hydraulic Locomotives?

If a full throttle reduction is applied by the driver once wheel slip occurs, does this not make controlling wheel slip manageable (before the wheel has a chance to speed up) and realistic? Do any of the current anti slip controls in OR manage wheel slip (and hence the input force) in an effective manner?
If we are able to implement only one traction type at the moment, then which one do we select?

[pschlik]

I think there's some confusion here about the core physics governing wheeled vehicles...Firstly, no, the current behavior is not correct for any type of transmission. 1.3.1 has the correct behavior. The wheel speed should be used as the reference value for the "input" force (before wheel-to-rail losses), instead of the train speed.

In all transmissions, a big concern is providing relatively constant power to the wheels at a wide range of speeds, everyone has some intuitive understanding of this. But note that a transmission can only manage how power is applied to the wheels and that the "wide range of speeds" is technically a "wide range of wheel speeds". The transmission has no correlation or connection to what happens at the rail, that's for other systems to figure out, and we aren't talking about those. The speed of the wheels, and consequently the speed of whatever is directly geared to the wheels, is what governs the force that can be put into the transmission; NOT the speed of the vehicle relative to the ground. To maintain constant power going into the wheels, as the speed of the wheels increases, the torque/force going into the wheels must naturally decrease. If the torque doesn't decrease, then the power would have to increase, so (putting aside things with very strange relationships between torque and speed), this means the force going into the wheels will generally decrease as the wheels spin faster. This doesn't necessarily mean the power output to the ground is remaining constant, nor that the wheel speed has any correlation to the ground speed. But the transmission does not care about what the ground is doing, all that matters to it are what the wheels are doing.

The problem in Open Rails is that there is all sorts of confusion between where to use what's coming in to the wheels (from the engine) versus using what's going out of the wheels (to the rails), generally leading to overuse of quantities relating to what happens at the rails when the focus should be on the wheels. While I can understand Open Rails attempt to use the train speed as the governing factor for force and power, it so clearly leads to nonsense results that do not portray reality in the slightest. That's what I've been trying to demonstrate this whole time.

I feel that it is necessary to point out again how this level of physics has produces unreasonable results even in the in-game debug displays.
Note that the power going into the axles is a massive 363,830 horsepower because there is a massive amount of force going into the axles and the axles are going very very fast. Yes, the train is completely stopped and the power at the rail is zero, but the speed of the train and the power at rail is not the only thing that matters!
https://i.imgur.com/MTPZoIk.png

Yet, despite the massive power input into the wheels, if we then look at the locomotive information debug, the engine claims it is completely unloaded because the power at rail is used to determine the engine load. It should be obvious that this is incorrect, the load on the engine is determined by the amount of engine power going out of the engine, which is approximately the power going IN to the wheels, not what comes OUT. The engine doesn't care what happens at the rail because the engine is not directly connected to the rails!
https://i.imgur.com/9h6lkbY.png

This actually violates the law of conversation of energy. While 1619 horsepower is coming out of the engine, somehow 363,830 horsepower is entering the wheels! Where is all this extra power coming from? It's easy to claim that these results are reasonable if the power going into the wheels is ignored, but I sure hope nobody thinks it's reasonable that 1619 traction horsepower is leading to over 200 times as much axle power!


I do hope this is enough to prove my point. I would rather not have such physics-defying behavior in this simulator.

[steamer_ctn]

pschlik, on 26 February 2021 - 11:58 AM, said:

The problem in Open Rails is that there is all sorts of confusion between where to use what's coming in to the wheels (from the engine) versus using what's going out of the wheels (to the rails)

I agree, and therefore I believe that it is important to review and confirm what is happening within OR, including v1.3.1.

pschlik, on 26 February 2021 - 11:58 AM, said:

This actually violates the law of conversation of energy.

I agree that the conservation of energy principle should apply, and the input power to axle model should remain constant until the throttle position is changed.

As you suggest the speed and force values will change, but they should still combine to give the "expected" constant power value as an input.

I want some time to reflect on what is currently happening, and what should be happening a bit more, so I may not respond for a couple of days.

[steamer_ctn]

I have done some quick research using a couple of sources to try and confirm my thinking - source1 and source2.

So based upon the these documents, my perception for a real world situation is still:

i) That when slip occurs, the input force to the traction motor should, without any external influence (such as a slip control system or the driver reducing the throttle setting), remain the same as the pre-slip value.

ii) The wheel speed, if left unchecked will increase to significant values. In the case of some DC motors it will cause the motor to fail, throw electrical coils out of the ammature, etc. So without further research, I don't know what value this speed is typically. Similarly for AC motors there maybe a limiting wheel speed, but again I am not sure what this might be at this stage.

As discussed, OR uses an axle module to "manage and simulate axle forces considering adhesion problems" (from OR developer notes). From the developer notes, this model seems to support three different scenarios as follows:
i) No Drive
ii) Traction motor connected through gearbox to axle
iii) Simple force driven axle

Currently only iii) above is used by OR, so it appears that the original developer had not completed their development work for this module. In addition it appears that it was going to have the ability to take into account some different electric motor attributes.

There appears to be no provision for any speed limitation in the model, eg for the speed failure points of DC or AC motors, etc. Hence wheel speed will keep increasing while ever there is sufficient input force to drive it up. In a real world situation, either the driver or the slip control system would reduce the throttle setting as soon as slip started happening (thus reducing input force), so in theory large speeds would not normally be reached. As the model does not have any speed limitation provision, it appears that the developer elected to added a "pseudo" slip control feature external to the axle model, which reduces the input force as the wheel speed increases.

Hence this means in its current form it is only modelling locomotives, with a basic slip control system. Wheel slip can still occur in this model, whereas with more modern locomotives a more advanced system might reduce the throttle setting to ensure that wheel slip does not occur. Early model DC locomotives would need some code changes to model them as no slip DC locomotives cannot be modeled currently.

As in real life, I would expect a driver in OR to manage wheel slip by reducing the throttle in order to bring wheel slip under control as soon as they start to experience wheel slip. Alternatively a more sophisticated slip control system would need to be incorporated into the locomotive control.

Given the fact that I currently don't have any more time to spend on the necessary research and thinking required to make large code changes in this area, and also given the fact that users are used to OR operating in this fashion currently, I have reinstated the "pseudo" slip control system for the axle model when slip occurs, until functionality can be added to make it possible for the user to select between, no slip, basic slip, and fully automated slip control.

The changes have been uploaded to the latest unstable version. To help users (and myself) to understand more about what is happening in the Axle model, I have also added a couple of extra values to the HuD. The first is the "equivalent" input power in the Force In line. The second two are the "axle speed" and following this value the "slip speed".

Also whilst running a few tests I found some unusual happenings in v1.3.1 when using dynamic braking and wheel slip with flipped locomotives. These haven't been investigated further.

[pschlik]

Thought about this some more, and I believe boiling down this issue to a bunch of individually manageable changes can provide an approachable way to improve this part of physics so it hasn't regressed from 1.3.1 and is easier to understand for future reference.

First, create some distinction between the axle input power (axle drive force & wheel speed) and the axle output power (motive force & train speed).
-It's clear that right now, there's not enough attention paid to the difference between what goes into the axle and what comes out; including the distinction in code is a step toward understanding the distinction

To fix the main "bug" reported here, change the physics to target a constant axle input power, instead of whatever it does now.
-Basically, change calculations for axle drive force to use wheel speed instead of train speed; that'll create the intended behavior and preserve the laws of physics

For added clarity, set engine load to be based on the axle input power, rather than the motive power.
-Don't think this would change physics at all, but this is a more realistic way to calculate load, and it may be relevant for the future

Additionally, LOAD_METER instruments inside cab views should also use the axle drive force, rather than the motive force, to calculate the displayed value
-A minor change, yes, but a further part of correctly representing the difference between what goes in and out of the axles; load meters can only measure what is going in

While we are at it, also tweak motive force calculations to not subtract the locomotive air brake force, as that causes a problem as I elaborated on here
-This is a somewhat different issue that appears to be an entirely different mistake but is still affecting the same part of the physics system
-By the way, it's fine to leave the calculations of wheel slip, wheel slip losses, and inertial losses unchanged, only brake "losses" are an issue

Individually, each of these changes is deceptively simple...add a variable here, replace a variable there with something else, that kind of thing. I'm sure there would be all sorts of regression testing required, but the point is that the physics are built on reasonable foundations, it's just a few specific calculations and behaviors that have been implemented in unusual ways, leading to infamous problems like wheels going Mach 3 and the ammeter bouncing around. Also, as few of these changes actually affect physics, and many would just be done for clarity and accuracy, it is highly unlikely these changes would ruin any old content. In fact, resolving Mach 3 wheel slip would most likely make old content easier to work with.

And for comparison, version 1.3.1 only obeys the second point. So, it's better than the testing version at obeying the laws of physics, but still somewhat confuses things in these other aspects, which is why we ended up here confused about what physics is and should be doing.