Long Train Operation

[PerryPlatypus]

Addressing the above quotes...I ran the activity that Nick and some other members were experiencing derailments with. Here's the results:

In the first run through I added the following lines to the loaded wag files used in the player consist
( BNSF_SELIGMAN_DOMESTIC_INTERMODAL folder )

DerailBufferForce ( 661kN ) 
        NumWheels ( 8 )
	ORTSNumberAxles ( 4 )
	ORTSNumberBogies ( 2 )
	ORTSLengthBogieCentre ( 19.25m )
	ORTSLengthCarBody ( 22m )
	ORTSLengthCouplerFace ( 23.39975m )
	ORTSWheelFlangeLength ( 0.754in )
	ORTSMaximumWheelFlangeAngle ( 1.308996rad )
        ORTSTrackGauge ( 4ft 8.5in )
	ORTSRigidWheelBase ( 5.65ft 3.6in )
	ORTSUnbalancedSuperelevation ( 2.56in )
	Friction (

I had no derailments until the curve immediately after passing Austin Spur. Then as others have stated car after car starting derailing--- I did a few tests at different speeds...near track speed and down to 5mph...all produced derailments.

Two obvious data points incorrect in the above addition to the cars
1.) the axles and bogies numbers are incorrect for these type cars...too many axles and bogies for the number of cars.
2.) the msts parameter "NumWheels" is not used ( and not needed ) by OR---it has been superseded by ORTSNumberAxles and ORTSNumberDriveAxles ( the sum of the two used in calculations ).

SECOND SERIES of test runs.
I ran the next test runs with the following edits made to all the loaded wagon files in the player consist.

BNSF_MaxiIV_211093A and BNSF_MaxiIV_211093B ( all A&B well cars had same edit )

DerailBufferForce ( 661kN ) 
	ORTSNumberAxles ( 2 )
	ORTSNumberBogies ( 1 )
	ORTSLengthBogieCentre ( 19.25m )
	ORTSLengthCarBody ( 22m )
	ORTSLengthCouplerFace ( 23.39975m )
	ORTSWheelFlangeLength ( 0.754in )
	ORTSMaximumWheelFlangeAngle ( 1.308996rad )
        ORTSTrackGauge ( 4ft 8.5in )
	ORTSRigidWheelBase ( 5.65ft 3.6in )
	ORTSUnbalancedSuperelevation ( 2.56in )
	Friction

BNSF_MaxiIV_211093C ( and all other loaded "C" cars in consist )

DerailBufferForce ( 661kN ) 
	ORTSNumberAxles ( 4 )
	ORTSNumberBogies ( 2 )
	ORTSLengthBogieCentre ( 19.25m )
	ORTSLengthCarBody ( 22m )
	ORTSLengthCouplerFace ( 23.39975m )
	ORTSWheelFlangeLength ( 0.754in )
	ORTSMaximumWheelFlangeAngle ( 1.308996rad )
        ORTSTrackGauge ( 4ft 8.5in )
	ORTSRigidWheelBase ( 5.65ft 3.6in )
	ORTSUnbalancedSuperelevation ( 2.56in )
	Friction

At the time of making this post I've made one run through the same curve just past Austin spur...at 10.5 to 11.5 mph.
NO derailments -- entire train through curve and beyond. I'm going to run again at higher speeds and see what happens.

Locomotive file edits ( example from the lead - all locos had same edit ) in the wag portion of the engine file.

DerailBufferForce ( 756.64416kN )

 NumWheels ( 12 )
 ORTSAdhesion ( ORTSCurtius_Kniffler ( 4.6 23.7 0.161 0.7 ) )
 ORTSAdhesion ( ORTSSlipWarningThreshold ( 70 ) )
 ORTSNumberAxles ( 0 )
 ORTSNumberBogies ( 2 )
 ORTSLengthBogieCentre ( 16.154m )
 ORTSLengthCarBody ( 20.31m )
 ORTSLengthCouplerFace ( 22.74993m )
 ORTSWheelFlangeLength ( 0.754in )
 ORTSMaximumWheelFlangeAngle ( 1.308996rad )
 ORTSTrackGauge ( 4ft 8.5in )
 ORTSRigidWheelBase ( 5.65ft 3.6in )
 ORTSUnbalancedSuperelevation ( 2.56in )
	Friction

For the next series of tests I am going to delete the NumWheels entry and add to the eng portion of the engine file the following: ( example from lead BNSF #5228 )

Sanding ( 30mph )
	ORTSDriveWheelWeight ( 181.44t )
	ORTSNumberDriveAxles ( 6 )
	MaxTemperature ( 120 )

Conclusions...so far nothing wrong with the code...or probably the route...taking the good advice of both Andre and Peter -- accurate data input to OR and making sure the axles and bogies of the cars are accurately recorded in the data does appear to make a difference...and Yes - one other thing...proper train handling.

Austin spur and the curve >>> [ATTACH=CONFIG]82564[/ATTACH]

pulling through curve >>> [ATTACH=CONFIG]82565[/ATTACH]

Hi Gerry,

I had suspicion there was an issue with discrepancy of axle/bogie count, since I was only getting derailments with the A and B cars when I did a test. If you get satisfactory results after further testing, would you mind emailing me some of the updated WAG's to look at your edits?

[R. Steele]

Hi Gerry,

I had suspicion there was an issue with discrepancy of axle/bogie count, since I was only getting derailments with the A and B cars when I did a test. If you get satisfactory results after further testing, would you mind emailing me some of the updated WAG's to look at your edits?

Sure thing Sean, happy to.

[R. Steele]

Finished the tests...results are good. No derailments at 100% throttle with modifications to wag and eng files ( as shown and explained in post #45).
Activity is the "Z Train Reroute" in the Mullan Route.

Screenshots of Force Information HUD - Derailment Coefficient says it all (highest coefficient was 2.21! )

Default wag files as provided ( no edits ) >>> DerailCoef_Before.jpg derail warnings

After Editing files and adding correct ORTS parameters >>> DerailCoef-After.jpg no derail warnings

I adjusted the values for some of the ORTS parameters, final numbers used are shown below

BNSF_MaxiIV_211093C and all other "C" cars

ORTSNumberAxles ( 4 )
	ORTSNumberBogies ( 2 )
	ORTSLengthBogieCentre ( 19.37497m )
	ORTSLengthCarBody ( 16.49995m )
	ORTSLengthCouplerFace ( 23.39975m )
	ORTSWheelFlangeLength ( 0.754in )
	ORTSMaximumWheelFlangeAngle ( 1.308996rad )
	ORTSTrackGauge ( 4ft 8.5in )
	ORTSRigidWheelBase ( 5.65ft 3.6in )
	ORTSUnbalancedSuperelevation ( 2.56in )
	Friction

A&B cars:

ORTSNumberAxles ( 2 )
	ORTSNumberBogies ( 1 )
	ORTSLengthBogieCentre ( 19.37497m )
	ORTSLengthCarBody ( 16.49995m )
	ORTSLengthCouplerFace ( 23.39975m )
	ORTSWheelFlangeLength ( 0.754in )
	ORTSMaximumWheelFlangeAngle ( 1.308996rad )
	ORTSTrackGauge ( 4ft 8.5in )
	ORTSRigidWheelBase ( 5.65ft 3.6in )
	ORTSUnbalancedSuperelevation ( 2.56in )
	Friction

[UP_4848_Thunder]

Finished the tests...results are good. No derailments at 100% throttle with modifications to wag and eng files ( as shown and explained in post #45).
Activity is the "Z Train Reroute" in the Mullan Route.

Screenshots of Force Information HUD - Derailment Coefficient says it all (highest coefficient was 2.21! )

Default wag files as provided ( no edits ) >>> [ATTACH=CONFIG]82566[/ATTACH] derail warnings

After Editing files and adding correct ORTS parameters >>> [ATTACH=CONFIG]82567[/ATTACH] no derail warnings

I adjusted the values for some of the ORTS parameters, final numbers used are shown below

BNSF_MaxiIV_211093C and all other "C" cars

ORTSNumberAxles ( 4 )
    ORTSNumberBogies ( 2 )
    ORTSLengthBogieCentre ( 19.37497m )
    ORTSLengthCarBody ( 16.49995m )
    ORTSLengthCouplerFace ( 23.39975m )
    ORTSWheelFlangeLength ( 0.754in )
    ORTSMaximumWheelFlangeAngle ( 1.308996rad )
    ORTSTrackGauge ( 4ft 8.5in )
    ORTSRigidWheelBase ( 5.65ft 3.6in )
    ORTSUnbalancedSuperelevation ( 2.56in )
    Friction

A&B cars:

ORTSNumberAxles ( 2 )
    ORTSNumberBogies ( 1 )
    ORTSLengthBogieCentre ( 19.37497m )
    ORTSLengthCarBody ( 16.49995m )
    ORTSLengthCouplerFace ( 23.39975m )
    ORTSWheelFlangeLength ( 0.754in )
    ORTSMaximumWheelFlangeAngle ( 1.308996rad )
    ORTSTrackGauge ( 4ft 8.5in )
    ORTSRigidWheelBase ( 5.65ft 3.6in )
    ORTSUnbalancedSuperelevation ( 2.56in )
    Friction

Glad your getting good results but I would try one more thing with the axles. For Articulated 3 Packers that share a bogie they deal with 8 Axles total. So on A&B try 3 Axles, on C 2 Axles (A 3 Axles, C 2 Axles, B 3 Axles would total to 8 Axles). But since there is no half a bogie I would still keep 2 Bogies each since A&B share with C an would remove the hard tension of C having 4 Axles an A&B 2 Axles. So A&B both split the axles with C because they share a bogie just looking at them making teamwork an are more efficient then 3 Packer Drawbar connected sets totaling 12 Axles.

Does that make sense that gives a realistic axle count splitting an sharing? I been using this method on the ATWells an they work well unless you handle them wrong. I stress test them starting at 3DTS Tehachapie route at East Bealville a lot on the empties since that interlocking switch was my frustration when length body was wrong an at Run 4-5 starting 2 motors at stand still.

[steamer_ctn]

Hi Gerry,

Finished the tests...results are good. No derailments at 100% throttle with modifications to wag and eng files ( as shown and explained in post #45).

Thanks for doing this testing, it is nice to have the confirmation that it works in this scenario as well.

	ORTSRigidWheelBase ( 5.65ft 3.6in )

This ideally should be "5.0ft 3.6in" or you could do "5.3ft 0in".

The value that is entered is probably slightly higher then what you intended.


I have also come across a formula for "platform" cars that I will be looking to add at some stage. I am not familiar with the terminology of a platform. However I am assuming that it is a number of flat cars connected together by a supporting bogie between them. Is this correct?

When I do this, I will need to create a special type of car to distinguish between a "platform" and a "normal" car.

[R. Steele]

Hi Gerry,
Thanks for doing this testing, it is nice to have the confirmation that it works in this scenario as well.

This ideally should be "5.0ft 3.6in" or you could do "5.3ft 0in".

The value that is entered is probably slightly higher then what you intended.


I have also come across a formula for "platform" cars that I will be looking to add at some stage. I am not familiar with the terminology of a platform. However I am assuming that it is a number of flat cars connected together by a supporting bogie between them. Is this correct?

When I do this, I will need to create a special type of car to distinguish between a "platform" and a "normal" car.

Re: Rigid wheel base measurement -- agree -- I've already converted/adjusted UoM to metric.. ORTSRigidWheelBase ( 1.76m ) -- which for this car was not from plans/schematic, but a careful - repeated - measurement on the model...so it could use some tweaking.

Re: Platform car: I'd only be guessing at this point...referring you to my tagline >>> "Forever, ridin' drag in railroad knowledge".

...and lastly to all others reading this...referring to the locomotive parameters I posted...ignore the ORTSRigidWheelBase data -- they are incorrect!

[CSRX]

45 loads and a coupler breaks, with three locomotives on the head end. That doesn't seem accurate at all. (using Gerry's updates on the salt cars I did)

I pull 35-50 loads out of Whitehall per night, with 3-4 locomotives, and no broken couplers, on grades that are almost 1.5%-2.0%, with tight curves.

Some things just don't seem right in this, which is why I check a lot of these boxes off like Broken Couplers and Derailments...

Edit:
Tested again, SD70M-2, GP38-2, GP38-2, SD70M-2, with 40 loads out of Whitehall on my route, no issues.
Oddly, an SD70ACe, SD40-2XR(2), with 45 cars, broke a coupler. Shrugs. Maybe just a fluke.. Or maybe they aren't appreciated being on the Mullan Pass when they probably have never seen that line in reality. haha

[R. Steele]

45 loads and a coupler breaks, with three locomotives on the head end. That doesn't seem accurate at all. (using Gerry's updates on the salt cars I did)

I pull 35-50 loads out of Whitehall per night, with 3-4 locomotives, and no broken couplers, on grades that are almost 1.5%-2.0%, with tight curves.

Some things just don't seem right in this, which is why I check a lot of these boxes off like Broken Couplers and Derailments...

Edit:
Tested again, SD70M-2, GP38-2, GP38-2, SD70M-2, with 40 loads out of Whitehall on my route, no issues.
Oddly, an SD70ACe, SD40-2XR(2), with 45 cars, broke a coupler. Shrugs. Maybe just a fluke.. Or maybe they aren't appreciated being on the Mullan Pass when they probably have never seen that line in reality. haha

Hi Shawn, may I ask you to provide copies of the consist, route, path and the activity -- if you were using one --- I'll PM my email or you could attach a zip here...your choice.

I'd like to test this particular situation out...that's the way to figure out if the data input is accurate or something needs adjusting. You could have found a bug...only one way to find out. Apply all the recent OR parameters and see what happens. Be Happy to give it a go. Maybe you'll provide some guidance, train handling, speeds, etc....I'll need it.

If I recall, the salt car OR modifications were the addition of CurtiusKniffler values, and Davis numbers...plus some OR brake settings. They really need to be updated to conform to the code parameters that are the subject of this thread.

[CSRX]

So we are in a constant state of updating parameters with no solid values that are accurate? Well that seems like a battle I am not interesting into dealing with.
Just used those OR modifications of yours on my other cars I'd like to release, but that sounds like I may have just wasted two hours updating..

[dcarleton]

I think Shawn's making an important point here. If someone has two hours after work-time and before bed-time, and they want to spend that time running a train; if they have to spend two hours tweaking physics then they'd be better off watching a movie or a game, or finding another hobby. They may see it as an exercise in regressive realism.

[R. Steele]

So we are in a constant state of updating parameters with no solid values that are accurate? Well that seems like a battle I am not interesting into dealing with.
Just used those OR modifications of yours on my other cars I'd like to release, but that sounds like I may have just wasted two hours updating..

There are solid values that are accurate...of course you might face updating or adding new parameters as the code is developed towards better realism both in the rendering of models and physics, most of us have been doing that since the beginning or OR.

Again, if you don't feel like updating now...and I can appreciate and sympathize with that -- I was working at one time and had little time to spend on hobbies...what time I did have was precious --- so, please, just copy the consist, I can probably figure out the rolling stock from it and let me know the route and where the derails occurred ( or an activity you were running ) and I will test and do all the updates and provide them to you. Cannot ask fairer than that.

...and not having seen the modifications you made to the cars, I really comment on them - whether time wasted or not.

[CSRX]

I wouldn't mind knowing what the current standards are for US freight car physics. Would like to us them. As I mentioned, currently, I use the ones you had provided in the salt car updates here in the library. I get a few "warnings" for certain cars on my route for the derailcoeff, but that's about it.

[steamer_ctn]

I think Shawn's making an important point here. If someone has two hours after work-time and before bed-time, and they want to spend that time running a train; if they have to spend two hours tweaking physics then they'd be better off watching a movie or a game, or finding another hobby. They may see it as an exercise in regressive realism.

This raises an interesting philosophical question.

If we don't want to spend time adjusting files as new features come out then the easy solution is for a user to stay on the current version that they are on. Some commercial software adopts this approach by "locking" their content to a particular version. For example, some older software is no longer supported in Win10, hence we can't upgrade our O/S if we want to continue using it.

So if we want "MSTS" functionality then why not just continue to use it. I understand that it still works in Win 10 (after a fashion). I suspect that users wanted better functionality (and features) so that they have moved to OR, but it is not a clone of MSTS, so some adjustments need to be made. Again they could stay on the original version of OR, but I suspect that new features have attracted them to update to more recent versions.

Commercial software often introduces changes that the user needs to adjust to when a new version is released. OR is about continual improvement, and hence we can expect changes to occur in the future. It would be interesting to compare the rate of change (improvements) introduced by other train simulator platforms.

Life is all about compromises, to bring about improvements (or change in our lives) always requires some effort. So at what point will a user determine that they have reached a point that they don't want to put any more effort into making changes, and instead stay on the version that they are on? The answer to this question will vary from user to user.

So perhaps another thread needs to opened to consider how OR users, and content providers, can cope with changes in OR as new versions (with new features) are released.

[CSRX]

Same question can be raised to those constantly making these changes to Open Rails. At what point will it be enough is enough before we push everyone out with this constant changes and updates, a user has to do to keep things running? I like some of the changes, but it's absolutely ridiculous half of the products I produced, as many others, are going to become useless, with the constant changes provided. I myself don't have all the time in the world to sit down, make changes to every car I create, just to continue to run in a simulator/game.

This isn't real life, and it becomes to the point, it will become far more work, than play, and honestly, no thanks..

[csantucci]

In my opinion refinements and improvements in OR shouldn't require changes in pre-existing rolling stock to continue using it as usual. If these refinements and improvements require such changes, they should either subject to option checkboxes or should become operational only if additional parameters are inserted in the .wag and .eng files. Backwards compatibility is important IMHO.