[Genma Saotome]

I downloaded a locomotive pack today from TS.com -- 3 .eng files having identical mass() and MaxWhatever() values... so essentially what varied was in the skins. I notice that while the trio was moving along perfectly flat terrain at 10mph the projected speed was jumping around. The train had no cars, just the 3 locomotives. Using the f5 screen I expected to see something indicating a slip but everything except one value looked normal: for the middle unit only, in the column headed by "Motive", the value shown was jumping from -42000 to +100000. The lead and trailing units were very stable, often showing near identical values across the line. Once the locomotives came to a light grade the data values for the middle unit quickly matched the other two.

I checked the .eng files... mass() for all three was 118t. Throttle was at 13% and after getting to 5mph up'd to 25%. Speed was less that 15mph the whole time (the odd looking data was present from the start so I had not gone very far before I stopped the test). Frame rates were 27-30.

Running the same set again, same result but this time I noticed something else: the value for gravity: 1st unit was 2, second unit was 0, third unit was -2 (it was probably that value the first time too but I didn't notice it). I don't know why those values were what they were but it got me to wondering if the unusual data for unit #2 was entirely due to being in the middle of three identical units: pulled from one end and pushed from the other.

At any rate, I do not know if what I observed is perfectly normal or not... a problem in the .eng data or program. But it struck me as odd that the data for all three matched only when on a grade... and so I'm reporting it here for comment.

Any advice will be most welcome. Will be happy to provide additional information as needed.

[Matej Pacha]

Hi,
the numeric methods being used in ORTS are a bit mysterious - ORTS behavior depends on many factors, e.g. simulation step (FPS), time constant (self oscilation frequency of the system), etc. If you are using a train with 3 locomotives only (no load), the middle loco may oscilate between the front and the rear one. The reason is not so clear and without any investigation I cannot say what it is. Maybe you can try it with some load (freight train of reasonable mass) - it acts as a damper to this oscilation.
I don't know the reason why the gravity force should be different but 2 means 2 Newtons, what is really a small number to the tractive force (usually in kilo Newtons). It would be helpful to know the consist you are using. Is there a public and free download of the locos?
Thanks,

Matej

[Genma Saotome]

Yes Matej, over at trainsim.com. The file name to search for is cnwset1.zip; Very nice looking 1950's era locomotives.

I ran it again late last night, keeping the throttle at 13%. When I aimed the camera in a particular direction to get the fps to be high the three units tracked along with almost identical values. When I rotated the camera in a way to drop the fps towards 30 the data for the middle unit jumped all over the place. Perhaps it's just that known issue about lower frame rates. If so, it does seem a bit odd that it is always the middle unit that has trouble.

If you don't want to bother with the installation, here are the three .eng files. I'm pretty sure all you need to do is rename the files to something you have on hand and then update the Wagon and WagonShape() values.

 F7A_CNW_4052A.eng (29.83K)
Number of downloads: 213




 F7B_CNW_4067B.eng (15.27K)
Number of downloads: 220




 F7A_CNW_4098C.eng (29.83K)
Number of downloads: 231

[James Ross]

 Genma Saotome, on 26 January 2013 - 09:12 PM, said:

I notice that while the trio was moving along perfectly flat terrain at 10mph the projected speed was jumping around.

There was a small error in the projected speed calculation in V1395 that I fixed in V1401 which meant that the projected speed was not smoothed and instead jumped around a lot if there was variation in the simulation's calculations. If you were or are using a version in this range, I'd try a later version to check if it was this.

[roeter]

 James Ross, on 28 January 2013 - 10:32 AM, said:

There was a small error in the projected speed calculation in V1395 that I fixed in V1401 which meant that the projected speed was not smoothed and instead jumped around a lot if there was variation in the simulation's calculations. If you were or are using a version in this range, I'd try a later version to check if it was this.

The basic reason for the variation in the projected speed is variation in acceleration. The fact that the displayed values of the projected speed are now smoothed doesn't take away the basic problem - jitter in acceleration and/or speed calculations.
This problem manifests itself in many ways - for instance, if you are a bit late braking for a (passenger train) station stop and perform a brisk brake application, the train stops but the station stop is not acknowledged as the 'jitter' maintains a speed != 0.
This jitter only stops when the brakes are released, but if the station is on a bank, it means the train will immediately move and set off the departure sequence.
This jitter also manifested itself in AI trains causing some problems with position processing - for AI trains I now force the speed to 0 each update when the train is in a 'stopped' state.
The jitter is worse if you have multiple power units in a consist - e.g. a set of multiple units, top-tailed trains (with loco on each end) or push-pull sets with the driving trailer as a second power unit (as was required by MSTS).

Regards,

Rob Roeterdink

[Matej Pacha]

Have you tried to disable the advanced adhesion model? The jitter may be caused by a low FPS, thus a big integration step.

Matej

[roeter]

 Matej Pacha, on 30 January 2013 - 04:53 AM, said:

Have you tried to disable the advanced adhesion model? The jitter may be caused by a low FPS, thus a big integration step.

Matej

FPS is around 100.

Rob Roeterdink

[Genma Saotome]

 Matej Pacha, on 30 January 2013 - 04:53 AM, said:

Have you tried to disable the advanced adhesion model? The jitter may be caused by a low FPS, thus a big integration step.

Matej

Just did. The performance of the three units is identical and looking very smooth. Matej, when you say adhesion jitter caused by low fps, how low do you mean?

James: I am using version 1395 and yes the projected speed was all over the place. I assumed that was a consequence of the middle unit's unusual data as seen in the motive column.

[Matej Pacha]

 Genma Saotome, on 31 January 2013 - 11:24 PM, said:

Just did. The performance of the three units is identical and looking very smooth. Matej, when you say adhesion jitter caused by low fps, how low do you mean?

Well, I tested your consist on two different computers - first I could get the same behavior as you with my poor system on 10 FPS. My second run was on 150 FPS machine with no jitter presented. I can't say that the only reason is the low FPS but it is one possible reason. The simulation uses a very simple forward integral methods (Euler and Runge-Kutta). Both methods are non-stable at longer steps, thus if FPS falls down (30 and lower), the advanced adhesion model begins to oscilate. The reason why the adhesion model oscilate and the train movement doesn't is very clear: trains have usually much more higher time constant than the wheelset, in the other words - a train mass is much more bigger than a mass of its wheels. The sampling frequency should be at least 10x higher than the resonant frequency (1/time constant) to keep the computation stable. The sampling frequency = FPS, thus on low FPS the condition above cannot be reached and the simulation will oscilate. If this is what you are experiencing, just disable the advanced adhesion model in the Menu or by pressing Ctrl+Alt+X and continue to drive just like in MSTS.

Just a note: I've implemented an estimation algorithm which can divide the FPS by a number from 1 to 50, depending on the time constant estimation, what brings more stable results. This means, the lower FPS the higher number of substeps is computed. The RK4 method requires about 15 operations per step. To avoid higher CPU load at low FPS the Euler method is used (number of operations per step is only 4). Such algorithm is working in most of the cases I've tested. You can watch the process on F5 HUD Forces view as "Solver" and "Step dividing active". There is also an emergency algorithm for the simulation starts to oscilate: the time constant is corrected to fit the FPS - the "Stability correction" feature. If such a situation occures, the stability correction nuber increases what causes the absolute wheelslip to be higher (not the relative one - it remains the same) and the indicate speed increases too (not the real speed). When the simulation becomes stable, the stability correction number falls back to 1.

I hope I've explained it correctly (please consider I'm not a native speaker).

Matej

[roeter]

Matej,

The physics calculations are not the only 'suspect' for this problem. In the code for Train.cs, there is also a calculation on coupler forces. Have you ever looked at that? It might well be that the jitter results from oscilation in those calculations, especially if there are multiple power-units each putting their 'force' on the couplers. It would also explain why the jitter continues even if all power is off and brakes applied, and the train supposedly stopped.

Regards,

Rob Roeterdink