[pschlik]

As well as investigating the problems with wheel slip I also wanted to get an idea of what was going on with the way the ammeter bounces around when using air brakes and power simultaneously. But what I thought was a bug in the code of the LOAD_METER cab displays is actually evidence of a much more major bug in the physics that has been causing trouble for years.

First of all, I'm going to make some assumptions about the quantities shown in the FORCE INFORMATION display of the F5 debug screens. I'm not entirely qualified on this, but after enough staring at the numbers, I think I get what's going on.
-Axle drive force appears to be just the traction force, ie: whatever force that is defined by the Tractive Force Curves or classic physics for the current speed and engine power (dynamic brakes don't show up as a negative drive force, but they should)
-Axle brake force is just the friction force of the air brakes
-Axle out force then is the Axle drive force less force due to dynamic friction from the brakes and wheel slip losses, this is also the 'motive' force (this is the bug)


The problem I was originally trying to investigate was that any LOAD_METER indicator in a cab view would not display the expected tractive effort; instead the expected tractive effort minus any brake forces was showing. Obviously, this is wrong. Real load meters measure what the motors are doing electrically, and applying the air brakes has no effect on what the motors are doing. I just assumed this was a graphical bug where the physics were fine but the load meter was being silly.

However, further investigation showed that this problem is not an issue with the LOAD_METER, but is indeed a core problem inside the physics itself. A load meter in a cab is showing the actual tractive effort a locomotive is generating, and the actual tractive effort is being reduced by applying the brakes. This is absurd, while applying the brakes will reduce the net effort a locomotive produces, it shouldn't suddenly cause the motors to power down!
https://i.imgur.com/PlDqPFo.png

The issue gets even worse from here. As it turns out, not only is the tractive effort produced by the locomotive being reduced by the brake effort, the brake effort is also counted as another separate force against the motion of the locomotive. This means that the locomotive brake force is counted twice; once as the actual brake force, then again by being subtracted from the motive force!
Note how, despite the drive force being 20 klbf larger than the brake force, the train is decelerating. The tractive effort has been reduced by the brake force, then the brake force was counted again, resulting in a net negative force when there should be a net positive force.
https://i.imgur.com/x9mur7m.png

This means that overcoming 59,000 pounds of brake force, which should require merely 59,000 pounds of drive force to counteract, actually requires 118,000 pounds of drive force to counteract.
https://i.imgur.com/zFvZKG4.png

Luckily, the solution to this problem appears to be simple. The calculation for motive force should be changed such that the axle brake force is not incorporated in the calculation. What likely involves changing one line of code would resolve a massive discrepancy in the train physics simulation, and make the LOAD_METER gauges in cabs act more as expected.

HOWEVER I would also suggest that LOAD_METER behavior be changed anyway, as showing the motive force means the load meter takes into account wheel slip losses, which it should not do. Remember, a load meter measures what the motors are doing, and wheel slip losses occur after the motors in the chain of energy. Anything after the motors is beyond what a load meter is capable of measuring. Having the load meter display the Axle drive force makes more sense.


As far as I can tell, this has been an issue for a very long time. Even version 1.0 calculates motive force incorrectly. However, in version 1.0, LOAD_METER displays in the cab show Axle drive force instead of showing motive force, no clue when that was changed but it was before version 1.3.1 came out; this behavior is just as problematic in 1.3.1 as it is now.