Long Train Operation

[R. Steele]

A Question: Will Ian Macmillan's MSTS Measuring Tool for Shape File viewer be accurate enough to determine the following for railcars?
ORTS... LengthCarBody; LengthBogieCentre; and LengthCouplerFace

For diesel locomotives those measurements appear to be common in manuals and specifications, although I'm having trouble finding that specific information for the Alco RSD15 and 17.

[motormaster532]

I have experienced similar issues on Mullan, which has me concerned. Running a 3x4x1 coal train up the grade, was getting constant derailing, even in areas of very broad/gentle curves. In the case of both this coal train and the Z Train Reroute consist, they are very very homogenous consists of all loads of similar car length, and all cars being nearly identical weight. These consists are also based on prototypical consists that run over this route without issue daily.

The coal train is 3 locos up front, 67 coal loads, 4 mid-train helpers, 58 more coal loads, then 1 DPU. Grade is 2.2%. The derailment was happening right at or very near to the mid-train helpers, so I am thinking the sim is being overly sensitive to the large in-train forces happening at the mid-trains.

Either there is a flaw that we (the TrainSimulations) team have introduced unknowingly in our WAG or ENG files that never surfaced previously because this type of derailment detection was not a thing... or, there is an error in the new code.

Either way, I am actually in agreement that it would be nice to figure out the solution to the problem, as I am always a fan of realism

Sean, I am getting ready to finish that "Z Train Route". I stopped it at Blossberg{had something to do}. I will let you know if and when the problem manifests itself if you wish. Brian

[R. Steele]

The wheel profiles used in the simulations were obtained from the transit system survey. These profiles were applied to simulations of both light rail and rapid transit vehicles with flange angles ranging from 60 degrees to 75 degrees and flange length ranging from 0.395 to 0.754 in.

From Flange Climb Derailment Criteria and Wheel/Rail Profile Management and Maintenance Guidelines for Transit Operations (2005) --- The National Academies Press https://www.nap.edu/read/13841/chapter/8

Another Question: The above underlined/bold information applied to trainsit rail --- is it also applicable to freight?
Specifically these two parameters --- ORTSWheelFlangeLength and ORTSMaximumWheelFlangeAngle?

[motormaster532]

Sean, I am getting ready to finish that "Z Train Route". I stopped it at Blossberg{had something to do}. I will let you know if and when the problem manifests itself if you wish. Brian

Just finished "Z Train Re-Route". I picked it up where I last left off at Avon. The Derailment notifications DID NOT come in at all the rest of the way. I used harder Dynamic Braking as well as hard Trainline braking than I normally would in the Sim,harder than I COMPLETELY would have in real life! No Problem! An excellent Activity in an excellent Route. Thank you Sean and Everybody else. I am going to PM you with this. Brian

[dcarleton]

If you're trying to fix long-train wheel/rail dynamics, don't base anything on that report. About the only thing that a long and potentially heavy train has in common with a rapid-transit system is that they both run on rails, and sometimes not even that!

[steamer_ctn]

Hi Sean,

It might be a bit until I can respond to set up a formal testing scenario with you, but I'll email you when I get some time in the coming weeks to do that.

No problems email me when you are ready.

Before you do, can you have run the derailment test route that I have setup, and skimmed through some of the documentation linked in the route documentation.

There is a statement that when these values are not explicitly specified (which would be the case with any of the Mullan content), that they are estimated from information in the WAG. Obviously I am curious what formulas are used for estimating these values.

It tries to use any default information that is available in the WAG file.

For example it uses the Size statement, however this is not always accurate as it is sometimes adjusted by users to get the "visual" effects of the SIM working correctly. It also uses the NumWheels statement (in older MSTS files), and again this is not always accurate.

For some of the other values it uses "guesstimates".

As I have suggested in my site, wherever the highest level of accuracy is desired the "default" information should be over written by accurate prototypical information.

The Lateral Force on the car is influenced by the coupler angle, hence why it is more at risk of a derailment on a sharpe curve, and some of the parameters indicated by you will influence the coupler angle.

I do want to bring up the issue of superelevation as a potential cause.

Superelevation is already considered in the derailment calculations.

It should be noted that there are currently two "separate" superelevations at work in OR. The first one is purely for visual effects, and is set through the OR Options Menu.

The second one, which impacts the physics, is set with some "standard" defaults, but can also be overwritten with values in the TRK file. I assume that these are the values that you have set.

My personal preference would be to see the two merged into a common input arrangement. The visual one only allows the user to specify a single superelevation value for the whole route, whereas the other approach, whilst not as good as setting the superelevation in the track database does at least allow more variations.

However, as I'm sure you know in the real world, this superelevation can vary significantly from one curve to another on the same railroad, even between two curves with the same radius. It's all a matter of design track speed for a particular spot.

I agree that this can happen. If the full route has been designed to a common speed, then the correct amount of superelevation should be designed into the curve such that the train can safely travel around the curve at the indicated route speed. Where different superelevations are used for the same radius curves throughout the route, then I would expect to see different speed limits to apply on these curves. And if these speed limits are adhered to then this should ensure that operations will be within acceptable performance limits on most occasions.

At the moment, based upon my test scenario, and testing to date, I believe that superelevation is adequately considered within the derailment calculations.

Until I see your scenario in more detail I cannot offer any more suggestions.

[steamer_ctn]

Another Question: The above underlined/bold information applied to trainsit rail --- is it also applicable to freight?
Specifically these two parameters --- ORTSWheelFlangeLength and ORTSMaximumWheelFlangeAngle?

You may wish to have a look at the derailment thread on ET, as it has some links to documents which might help answer your questions.

http://www.elvastower.com/forums/ind...ost__p__276617

[R. Steele]

You may wish to have a look at the derailment thread on ET, as it has some links to documents which might help answer your questions.

http://www.elvastower.com/forums/ind...ost__p__276617

Thanks, with other sources I've found, and the link at Elvas, yes I'm in the ballpark...0.754in for flangelength and 75 degrees for flange angle ( 1.308996rad ) will be my starting testing values.

[CSRX]

Honestly, at the moment, I turn off derailments. If a train of the same car type, length, etc, derails, that I run almost daily with no issues in the real world, something isn't adding up.

At least everything else in ORTS is getting pretty good with the realism aspect. Air pressure depending on the length of train and how quick it climbs, curve dependencies, etc.

[UP_4848_Thunder]

Yep Flange info is important an I forgot to point that out.

Pre 2005 I typically use:
ORTSWheelFlangeLength ( 1.0in )
ORTSMaximumWheelFlangeAngle ( 70deg )

Modern today equipment I typically use:
ORTSWheelFlangeLength ( 1.25in )
ORTSMaximumWheelFlangeAngle ( 75deg )

I also point out wheel size is important too as there is a difference in starting force an turning rounds. If you are like me I get annoyed at the fast turning wheels in pre stock at slower speeds as if wheels were small but vulnerable to derailing like intended for some autoracks with small wheels with a bunch of cases of string lines.

A Question: Will Ian Macmillan's MSTS Measuring Tool for Shape File viewer be accurate enough to determine the following for railcars?
ORTS... LengthCarBody; LengthBogieCentre; and LengthCouplerFace

I barely used that tool an appears to be an accurate easy way to measure an move then what I been doing. But trying the tool vs the bounding info shape viewer shows, it looks pretty easy positioning the center green lines to the point of measure an multiplying it by 2 or measure both ends an add up. I would later convert to feet.

Thanks

[UP_4848_Thunder]

Honestly, at the moment, I turn off derailments. If a train of the same car type, length, etc, derails, that I run almost daily with no issues in the real world, something isn't adding up.

At least everything else in ORTS is getting pretty good with the realism aspect. Air pressure depending on the length of train and how quick it climbs, curve dependencies, etc.

I panicked on that same thing about the real thing vs ORTS derailing. I even asked "why isn't the real thing derailing when I am out there an ORTS has to derail it easily?" that I tweaked up stock to standards adding the various needed new parameters that it removed most the panic away. Now on a real life section of track that's been getting derailments I just intend to do what the tapes an managers say what happened an look for accuracy. Even though I have never been on duty with a crew to derail yet but I have been around it or passed the scene of other crews an wonder what to test.

The derail test route is a good example of accuracy an sure derailed the exact involved car number of cars back to be the good example.

[R. Steele]

Yep Flange info is important an I forgot to point that out.

Pre 2005 I typically use:
ORTSWheelFlangeLength ( 1.0in )
ORTSMaximumWheelFlangeAngle ( 70deg )

Modern today equipment I typically use:
ORTSWheelFlangeLength ( 1.25in )
ORTSMaximumWheelFlangeAngle ( 75deg )

Yep, in one of the sources I found, AAR studies increased the flange angle...1990's had as low as 60 degrees - by 2005 ( as you've indicated ) up to 70degrees ( although the study I read had measured results from 60 to 75 degrees), 75 degrees does appear to be the recommended flange angle for modern rail.

Do you have references for the flange length? -- only current source I've found has 0.75in

[UP_4848_Thunder]

Yep, in one of the sources I found, AAR studies increased the flange angle...1990's had as low as 60 degrees - by 2005 ( as you've indicated ) up to 70degrees ( although the study I read had measured results from 60 to 75 degrees), 75 degrees does appear to be the recommended flange angle for modern rail.

Do you have references for the flange length? -- only current source I've found has 0.75in

The flange length is still in its testing stages I typically added .25 inch when I was dealing with lighter cars but dimensions got better accurate study I may go back down that little. But I did measure or measure wrong a real flange length up to little over 1.0in but will do multiple measures an tests based on wheel sizes as some are bigger some are smaller etc. I will measure multiples tonight when I am air testing.

[steamer_ctn]

If a train of the same car type, length, etc, derails, that I run almost daily with no issues in the real world, something isn't adding up.

If we want a realistic looking model of a real world locomotive, we don't make an object file with just a square cube in it, and then expect OR to render the model for what we are thinking of. Instead we add lots of detail to the object file (input information) and use that to tell OR what to render.

A very detailed model rendered in OR does not contain any detailed physics information, so similarly if we want accurate real world train physic performance in OR, then we need to provide enough accurate input information for the specifications (physics) of the pieces of stock that we are using.

A Question: Will Ian Macmillan's MSTS Measuring Tool for Shape File viewer be accurate enough to determine the following for railcars?
ORTS... LengthCarBody; LengthBogieCentre; and LengthCouplerFace

For diesel locomotives those measurements appear to be common in manuals and specifications, although I'm having trouble finding that specific information for the Alco RSD15 and 17.

For maximum accuracy I would highly recommend that wherever possible actual plans be used for determining these distances.

Measuring distances on the OR model could introduce errors if the object modeller has had to make adjustments for some reason, so I would suggest that the measuring tool only be used as a last resort, and with the knowledge that some errors may be introduced.

[R. Steele]

...A very detailed model rendered in OR does not contain any detailed physics information, so similarly if we want accurate real world train physic performance in OR, then we need to provide enough accurate input information for the specifications (physics) of the pieces of stock that we are using. ...

I too am getting derailments on Mullan Pass Z reroute act just past the Austin nameboard. This occurs on both the latest MG version and the latest testing version. ...Nick.

It's all about the length dimension parameters an number axles. ...

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 >>> bandicam 2021-12-12 14-13-09-695.jpg

pulling through curve >>> bandicam 2021-12-12 14-12-49-612.jpg