CSX Ethanol train physics

[geepster775]

H is a tightlock version of F, used primarily on passenger trains (Acela, Amfleet, etc)

F is a freight version of H with a top shelf design, which I believe is used on some rotary coupler cars, newer standard crude tank cars or other specialty application where you have tri-axle freight car trucks or greater. Situations like Schnabel cars where the loads are massive and weight is carried across 48 axles, or even a heavy duty 8 axle flatcar.

E is the common one for coal service or general 286K cars. I've seen figures as high as 450,000 for these. So I'm okay with Jason's 420,000 selection for those.

D is still in use today on lesser grade freight cars. This is the value Jason should be using for the lesser cars like gondolas and high cubes. His 250,000 value is low.

C is from the 40 foot, 70 ton boxcar era of the 1950s-1970s. They were still quite common into the 80s and 90s.

I managed to get a shot of a relatively new CNW AC4400 that had wandered away from home, and the relatively clean rear end plate had multiple holders for spare E knuckles only. These are on coal service units.

[greg_davies]

To wrap up, I did some research to find some real values for Coupling Break(). Based on the ORTS Manual, the Unit of Measure can be N for or kN for Newtons and lb or lbf for Pounds. There are conversion apps on the web to go between either.

Couplers are made to AAR M-211 Standards
Grade C knuckle, 300,000 lbs, and coupler 450,000 lbs.;
Grade D knuckle, 350,000 lbs, and coupler 600,000 lbs.;
Grade E knuckle, 400,000 lbs, and coupler 700,000 lbs.;
Grade F knuckle, 650,000 lbs, and coupler 900,000 lbs.;
Grade H knuckle, 650,000 lbs, and coupler 900,000 lbs.

Modern cars are generally equipped with F Type or Grade F couplers, that includes engines, coal and tank cars plus others.
Grade or Type H couplers are found on Passenger equipment and are considered "Tight Coupling" to keep cars coupled during derailments. I could not find anything on these so I used the Type F settings.
A lot of equipment running today are equipped with E Type couplers. There is an E/F Type which is basically a Type E for our calculations.
The Type C and D couplers are "Steam Era" type couplers.

These values are not validated with anything "official". The values are derived from various "un-official" sources. The values that we would use would be the Knuckle break values. The general idea is to break the knuckle before the coupler itself or any other part. Knuckles can be replaced easier in much less time and cost.

If you have better information, please share it. This is the best I could come up with in a short period of time. I think it is a good point to start and the values seem to be realistic. For what it is worth......

Greg Davies

[R. Steele]

I have been very interested in this thread as physics are a priority for me.

Why not use pounds for mass instead of tons?

My understanding is that OR accepts many UoM, see pages 219-221 Sec22.1 Units of Measure.
Reading that section you'll find that OR does indeed accept lbs for certain parameters.
You can choose to use any that is appropriate for a specific parameter, however, the only UoM that does not have to be explicitly expressed is the default UoM - all others have to be specified.
My choice was to use the default at all times, and stick to metric UoM

[derekmorton]

I have been very interested in this thread as physics are a priority for me.

Why not use pounds for mass instead of tons?

[greg_davies]

I have a test car set up as 100t-us mass. In the HUD the weight shown is 89.3 ltn which is a correct conversion from the US short ton to the Imperial long ton. This tallies with my choice of display units on the Options/General tab.

I stand corrected. I just looked at the Options/General tab and found the setting. So much for reading the manual. On my machine it is set to the default which is Player's Location. That means all of the weight measurements need to be in US Tons. The OR application will then convert to a standard weight to be used within the program. That makes a lot of sense. I wish I had known that earlier but I know it now and thanks for bringing that to my attention. Now I need to rethink whether to convert my files to Mass( US Tons ) or leave as Metric and then change the setting that Options / General tab setting. I need to spend some time with the manual, that is for sure, and back to the drawing board with the testing.

My appologies to everyone for misstating the now obvious.

Greg

[greg_davies]

Greg, it is puzzling why the various HUDs are a mixture of metric and US units. I suppose there was a reason for it, maybe discussed in the threads or the developers private forum. Never did make sense to me, if the input data (from the eng or wag file was metric, and most are) then the HUD should also be metric, why the need to convert for the display? Gerry

It is puzzling but understandable to a certain extent. Most programmers in the US have little knowledge of Metric measurements of any kind. The MSTS community has been forced into it because of overseas development. Programmers in the US tend to take the path of least resistance and think in terms of US measurements, everyone else Metric. It is easy to get confused and make assumptions.

What puzzles me even more is what units of measure are being used within OR that we can't see. Almost all characteristics of physics involve weight. Is the weight calculated correctly if the units were changed? Are the units being taken correctly to begin with? Can you tell me if there has been a document that describes the assumptions being made when data is being read from our files? Is the weight being read into OR as Metric Tons, US Tons, or some other unit of weight like kilograms? Inquiring minds want to know.

My biggest fear is that what we see in the HUD is not what is going on behind the scenes. All I know is the weight being displayed, whatever unit of measure that is, can be manipulated by changing the Mass() value in the HUD. Beyond that, I have no clue. All I know is that the changes I made now allow the train to work as one would expect.......at least on my machine.

I guess it is time to dust off my Visual C# compiler and run the code in debug mode to see what is going on inside. That is going to take some quality time of which I have little.

On the other side of the coin, I applaud the work that the OR group has done. We have a much better platform to run our trains on with room to grow. I gave up MSTS years ago and have been exclusively ORTS ever since. Even with the problems, OR is so much better than MSTS I really do not understand why some people continue to use MSTS. But they do and they have their reasons. So be it. I can live with that.

Kicking the soap box to the side.....

Greg

[baldwin]

I have a test car set up as 100t-us mass. In the HUD the weight shown is 89.3 ltn which is a correct conversion from the US short ton to the Imperial long ton. This tallies with my choice of display units on the Options/General tab.

[R. Steele]

Greg, it is puzzling why the various HUDs are a mixture of metric and US units. I suppose there was a reason for it, maybe discussed in the threads or the developers private forum. Never did make sense to me, if the input data (from the eng or wag file was metric, and most are) then the HUD should also be metric, why the need to convert for the display? Gerry

[greg_davies]

In reference to the 2 problems Geepster presented in Message #1. The problem with the different behaviors involving a Save and Resume I will not address, but I will address the coupler issue. First off, I followed Gerry's examples and cleaned the engine codes for all three units with ORTS and set the MaxPower at the correct 4000hp setting of 2982.7992kW. Then cleaned up the tank cars and added appropriate ORTS code and changed the coupler setting. I then proceeded to test the train under various situations.

I found one interesting issue with OR. In the HUD using the shift F5, I found the reported weight of the tank cars was in excess of what I had entered in the Mass(), by almost 10%! I calculated the Gross Weight of the car by adding the Light Weight (car empty) together with the Load Limit Weight (maximum weight of the cargo the car can carry). Both of these added together equals the Gross Weight or fully loaded weight of the car. For a 30k tank car the LtWt is about 66,000lbs and the LdLmt is about 197,000lbs for a total of 263,000lbs. I like to take these values right off of the actual car for accuracy. Calculating the Metric Tons the Gross Weight is about 120 metric tons. This is the value I entered in the Mass() yet the HUD was showing 133 metric tons.

It is interesting to note that the HUD was showing 133 as the car weight. If the units of that value were US tons, then that would be about right BUT we should be dealing with Metric Tons as originally used in MSTS. (Remember, a lot of MSTS was written in England.) The HUD is only visual indications of what is going on inside OR so I have to assume the weight of the cars is being calculated incorrectly. I reduced the Mass() value by approximately 10% until the value shown in the HUD was 120.

The next thing I did was to increase the Break() values of the couplers to 2150kN each. At that point I could start the train from a stop on an 0.8% grade without breaking any couplers using reasonable throttle control. Word of warning, don't forget the covered hopper idler car. In my testing this was the car that took the most abuse so lower the weight of the car and set the same coupler values as the Tank cars.

Is all of this correct? I have no idea. The engine max power is correct for those units. I have no reason to believe other wise. The rest of it will take more research but atleast the train is moving.......on my computer.

Greg Davies

[greg_davies]

comment ( 28.5t empty, 118t full )
Mass ( 122t-us )

The load is actually given in US units - metric weight of 110.7 was used to compute Davis numbers.
Although I don't give the question of weight too much weight...the user can always adjust to suit their ideas or experience.

Word of warning to all - be careful what you assume. Just because the Mass is stated to be in US Tons does not mean OR makes that conversion from US Tons to Metric Tonnes. In many cases OR takes the numeric value and then defaults that value to what MSTS was using it as, Metric Tonnes or Kilograms. Many of the unit conversions have not yet been implemented due to time and priority issues.

To be on the safe side, use the units that MSTS used. One of the major premises that OR used was to make OR work like MSTS and weight is important. Just because TS/SLI used it in their Wagon files does not make it so.

I only bring this up as testing coupler strengths is based on weight. If the weight is incorrect, your conclusions will also be incorrect. Otherwise, if the weight of the car is not that important then leave it as is and move on to more important matters.

Greg Davies

[greg_davies]

Perfect Mr. Steele. Thanks you. That is exactly what I was looking for....a place to start or just stay for a while. I realize this "hobby" we are in is called a simulator and as such it simulates the real world not duplicate. I too find it difficult to wait for the air to come up as it would in real life and do short cuts to speed the process. I also would not wait 2 to 3 hours for the track to clear so I can proceed. I just want to get to what I enjoy. But on the other hand, I do want the simulation to be somewhat accurate and for what you have done, it suits my purposes perfectly.

Greg Davies

[R. Steele]

In Message #21 there was a reference to include ( "..\\..\\Common.Std\\Engines\\Std_Eng_BrakesTS.inc " ), would it be possible to know what that looks like and how did you arrive at that set of code values?

I am figuring it out as I go along and found I had been making some assumptions that were not correct. Your code snippets were of great help in that area along with a search of the source code. I don't understand all of it quite yet but I am getting there. I see FCalc can provide some of the values for the friction but is the ORTSAdhesion ( ORTSCurtius_Kniffler ( 7.5 44 0.161 0.7 ) ) pretty much a constant across the board for both engines and freight cars?
Greg Davies

AFAIK the Curtius Kniffler numbers are empirical, derived from many tests and experiments over the years. Just search Curtius Kniffler on the web and you'll find test papers written up. There probably is no benefit from adjusting these numbers, although I'm sure people will try.
I did so and then saw the curves that resulted from my new numbers, the new curves did not come anywhere near the expected results. I think it is best to leave them as they are.

The brake parameters are derived from TS [SLI] brake sections. They are definitely not prototypical. Mine are a little faster and please my tastes for now, I'm constantly tinkering with them. If folks actually had to wait for a modern freight consist (mile long) to charge the brakes, they would complain. The values are a compromise between reality and enjoyable simulation. There has been a constant discussion in the threads (especially over at ET ) about slow brakes and some changes have been made to the code, other changes are waiting for priority or a coder to work them.
After all the palaver here they are:

Comment ( Standard Diesel Locomotive Brakes  )
Comment ( include ( "..\\..\\Common.Std\\Engines\\Std_Eng_BrakesTS.inc" ) )

 	BrakeEquipmentType( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
        BrakeSystemType( "Air_single_pipe" )
	ORTSBrakePipeTimeFactor ( 0.003s )
        ORTSBrakeServiceTimeFactor ( 1.009s )
        ORTSBrakeEmergencyTimeFactor ( 0.1s )
	MaxBrakeForce( 107.1kN )
        TripleValveRatio ( 2.5 )
	MaxReleaseRate( 5 )
	MaxApplicationRate( 5 )
        MaxAuxilaryChargingRate ( 2.15 )
        EmergencyResCapacity ( 8.604 )
        EmergencyResChargingRate ( 2.05 )
        EmergencyBrakeResMaxPressure( 90 )
        BrakeCylinderPressureForMaxBrakeBrakeForce ( 70 )
        EmergencyResVolumeMultiplier ( 0.4 )
        EmergencyBrakeTriggerRate ( 180 )

This is the set of parameters I most often use: for modern diesel locomotives, again not prototypical.

Comment ( Standard Diesel Locomotive Brakes  )
Comment ( include ( "..\\..\\Common.Std\\Engines\\Std_Eng_Brakes.inc" ) )

 	BrakeEquipmentType ( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
 	BrakeSystemType ( "Air_single_pipe" )
	ORTSBrakePipeTimeFactor ( 0.003s )
        ORTSBrakeServiceTimeFactor ( 1.009s )
        ORTSBrakeEmergencyTimeFactor ( 0.1s )
        MaxBrakeForce ( 178kN )
 	EmergencyBrakeResMaxPressure( 90 )
 	TripleValveRatio( 2.5 ) 
 	EmergencyResVolumeMultiplier ( 1.461 ) 
	MaxReleaseRate( 3.3 )
 	MaxApplicationRate( 3.3 )
 	MaxAuxilaryChargingRate( 3.4 )
 	EmergencyResCapacity( 8.0 )
 	EmergencyResChargingRate( 3.3 )
 	BrakeCylinderPressureForMaxBrakeBrakeForce( 70 )

[greg_davies]

In Message #21 there was a reference to include ( "..\\..\\Common.Std\\Engines\\Std_Eng_BrakesTS.inc " ), would it be possible to know what that looks like and how did you arrive at that set of code values?

I am figuring it out as I go along and found I had been making some assumptions that were not correct. Your code snippets were of great help in that area along with a search of the source code. I don't understand all of it quite yet but I am getting there. I see FCalc can provide some of the values for the friction but is the ORTSAdhesion ( ORTSCurtius_Kniffler ( 7.5 44 0.161 0.7 ) ) pretty much a constant across the board for both engines and freight cars?

Greg Davies

[greg_davies]

I guess all of this begs the question: Is anyone working on 'more realistic' physics for freight cars and/or diesels????? I'll let someone else bring up the question about electric and steam.

Greg

[hiball 3985]

ORTS Wheelslip Throttle Down may work correctly for modern locos but what about older units like SD40-2 etc. How is the wheel slip controlled on multiple units?