Announcement

Collapse
No announcement yet.

CSX Ethanol train physics

Collapse
X
Collapse
First Prev Next Last
 
  • Filter
  • Time
  • Show
Clear All
new posts

    CSX Ethanol train physics

    I've encountered an interesting situation. The "out of the box" physics settings for SLI's ethanol train release for Open Rails still seem a little off. If I place that trainset, using the provided consist, and use it on the Sherman Hill route, I seem to be unable to ever get that train moving on the upgrade when starting the train anywhere on the 0.8% uphill grade of Track 3, the low grade line via Harriman.

    Of course trains that size should be able to start from a dead stop on a 0.8% grade without any rear-end shove - that happens all the time. In real life, coupler breaks would only happen from sloppy train handling or engineer-induced slack yanks and jerks.

    In explorer mode, starting at Harriman, and heading towards Dale Jct, it requires the 5th notch just to keep the train from rolling away backwards. But even if I stay in the 5th notch, doing this no-win battle against gravity, after about a minute, the coupler knuckles between 2 cars somewhere in the train will break. If I go to the 6th notch earlier, knuckles will break immediately.

    While I applaud the effort to bring this kind of train handling physics to Open Rails content, something seems a little brittle in the chosen values. Either that, or the rolling friction is too heavy.

    The only changes I made to any files were to correct the MaxPower value which was incorrect (it was too low) on the GE's. I never touched the car physics settings in any way.

    The reason I chose Sherman Hill was because not all routes are laid with consistent gradient, especially when trying to replicate modern construction of lines built in the mid 20th century as opposed to late-19th century, but this route was built right.
    My Open Rails videos https://www.youtube.com/channel/UClc...1kBPO2A/videos

    #2
    Good comments about the content from TS. I don't think payware providers have an understanding of OR yet. Most of them have not used the sim enough.

    I would say, that testing is much more reliable when using the test route.
    Here >>> http://www.coalstonewcastle.com.au/physics/route/
    For testing purposes I switched over a few months ago, you'll probably appreciate this route's advantages more than I.

    I just took a look at the wag files...(engine files are way outta my knowledge base, wags much simplier)
    Here's what makes them OR ready
    1. DDS only no ACE files
    2. Mass UoM is US tons?? - why? - locos are still metric tons.
    3. Coupler Break set at 1067kN, using UoM "kN" in preference to msts style (1.067e6N) - which is within a good range, probably will not break (gone as low as 400kN with some trains/loads. I think a reasonable range is from 950kN to 1550kN, lower if you want more breakage action than prototypical).
    4. Faster brake settings..maybe a nod to OR??? why that fast?

    On the minus side...
    1. Still using the old Adheasion (sic )
    2. Still using the mysterious msts Friction statement - anyone can derive the numbers using the proper utility. A few on the forums can actually understand and explain the concept of Friction and how it works in real world physics (definitely NOT one).
    Did anyone ever understand how all the Friction parameters were actually used in the msts calculations, how they interacted?

    Most definitely not OR ready until they start putting in the correct Davis Numbers and using Curtius Kniffler.

    Using the test track I cannot pull the consist without breaking couplers - 1% grade, I set the couplers ridiculously high, and still could not move consist. It will start on a level grade, without breaking couplers...but power is mismatched to load.

    Here's include files I used for the whole shebang. Engine include files are basic stuff.
    TS_EthanolTrain.zip
    Last edited by R. Steele; 06-30-2017, 00:57.
    Cheers, Gerry
    "A mind is like a parachute. It doesn't work if it is not open." Frank Zappa
    It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.
    Forever, ridin' drag in railroad knowledge.
    Audi, Vide, Tace, Si Vis Vivere In Pace

    Comment


      #3
      If no bearing type is specified the default is "friction". Try adding ORTSBearingType ( Roller ) or even ORTSBearingType ( Low ) to the wags for a lower starting friction.
      Beer is not a matter of life or death, it is much more serious than that.

      Comment


        #4
        Originally posted by baldwin View Post
        If no bearing type is specified the default is "friction". Try adding ORTSBearingType ( Roller ) or even ORTSBearingType ( Low ) to the wags for a lower starting friction.
        Correct, but if you examine files contained in "TS_EthanolTrain.Zip (post #2) you will find:
        Code:
        include ( "..\\DBUX_302740_26K_TANK_LD.wag" ) 
        Wagon ( 
        	 Coupling (
        		Type ( Automatic )
        		Spring (
        			Stiffness ( 1e6N/m 5e6N/m )
        			Damping ( 1e6N/m/s 1e6N/m/s )
        			Break ( 1067kN 1067kN )
        			r0 ( 15cm 25cm )
        		)
        		Comment ( CouplingHasRigidConnection ( 1 ) )
        		Velocity ( 0.12m/s )
        	)
        	Coupling (
        		Type ( Automatic )
        		Spring (
        			Stiffness ( 1e6N/m 5e6N/m )
        			Damping ( 1e6N/m/s 1e6N/m/s )
        			Break ( 1067kN 1067kN )
        			r0 ( 15cm 25cm )
        		)
        		Comment ( CouplingHasRigidConnection ( 1 ) )
        		Velocity ( -0.12m/s )
        	)
        	Buffers (
        		Spring (
        			Stiffness ( 1e6N/m 5e6N/m )
        			Damping ( 1.3e6N/m/s 3.8e6N/m/s )
        			r0 ( 20cm 30cm )
        		)
        		Centre ( 0.5 )
        		Radius ( 1 )
        		Angle ( 0.5deg )
        	)
        	ORTSAdhesion ( ORTSCurtius_Kniffler ( 7.5 44 0.161 0.7 ) ) 
        	[B]ORTSBearingType ( Roller )[/B]  <<< (my emphasis)
        	ORTSDavis_A ( 1196.27 )
        	ORTSDavis_B ( 19.5462 )
        	ORTSDavis_C ( 1.197900 )
        	Comment( == Assumptions -FreightCar Standard - speed - 65mph (105km/h), Roller Bearing, 4 axles, frontal area - 10.0m2, WagonWeight - 118.8 ton (metric) == )
        
        	Comment ( orts performance brakes )
        	BrakeEquipmentType( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
        	BrakeSystemType( "Air_single_pipe" )
        	MaxBrakeForce( 35.0kN )
                MaxHandbrakeForce( 57.2kN )
        	NumberOfHandbrakeLeverSteps( 100 )
                EmergencyBrakeResMaxPressure( 90 )
        	TripleValveRatio( 2.5 )
        	MaxReleaseRate( 3.50 )
        	MaxApplicationRate( 3.50 )
        	MaxAuxilaryChargingRate( 3.684 )
        	EmergencyResCapacity( 8.604 )
        	EmergencyResVolumeMultiplier ( 1.461 )
        	EmergencyResChargingRate( 3.684 )
        	BrakeCylinderPressureForMaxBrakeBrakeForce ( 77 ) 
        )
        Cheers, Gerry
        "A mind is like a parachute. It doesn't work if it is not open." Frank Zappa
        It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.
        Forever, ridin' drag in railroad knowledge.
        Audi, Vide, Tace, Si Vis Vivere In Pace

        Comment


          #5
          I am beginning to think there is a bug in the code. Here is how I came to this conclusion.

          Just for grins and giggles, I took the SLI wag file, deleted the Friction line, and inserted the roller bearing line in its place. There were no other ORTSDavis or ORTSAdhesion entries. No other ORTS physics entries at all. I did it for every wag in the consist. I am still testing on the Sherman Hill route with only a 0.8% grade.

          Under these conditions, the train ran away backwards quicker upon entering the sim, and it took almost 2 minutes to arrest the backwards slide with a notch 5 (63%) power setting. After arresting the slide, it did start creeping forward. It made no difference in how long I waited for the speed to build up. Whether it got to 2 mph forward (after about 4 minutes), or over 10 mph forward (after about 9 minutes), it DID NOT MATTER what the speed was, the moment I advance the throttle to notch 6, the train separated and went into emergency.

          If I happened to save the run just before advancing the throttle, and if I restored from that save, I could lean on the throttle all the way up to 100% notch 8 and have no trouble with separation. Even if I put the throttle in idle, waited until gravity stopped the train, and started out again from 0 mph, I could slam that throttle all the way to number 8 and never break the train.

          Something is happening when you start the explore session that is NOT happening when you restore from a save. I find it very difficult to believe once the train gets over 10 mph that the next notch up on the throttle will break it so easily. There already is enough forward momentum underway by that time. Something is very sloppy in the code there. And if you restore from a save you can abuse the train handling all you want and you will never break it.
          My Open Rails videos https://www.youtube.com/channel/UClc...1kBPO2A/videos

          Comment


            #6
            Originally posted by geepster775 View Post
            I am beginning to think there is a bug in the code. Here is how I came to this conclusion...
            Running on the 1% grade on the test track, using all the include files in post #3, the train will slide back, but slower then the content as delivered and your description using the Roller Bearing parameter...mild application of brakes (brakes settings in include file) will halt backward slide easily. The power as provided will not move the default consist, couplers breaks occur.

            By not using the Davis Numbers, Curtius Kniffler and the other components of the include file you are depriving yourself of using native OR physics, these eng and wag files as provided by TS are frankenwagons and frankenlocos. [spirit of transparency...long time and loyal customer of SLI-TS]. I think your testing is flawed at this point. More accurate results would be obtained using the include files.

            Really, just plug in the include files (these are very basic)...see for yourself. You should try this before deciding if there is a bug. Could be, not convinced here.
            If you are unconvinced about the test track...where on Sherman are you testing - still at "starting at Harriman, and heading towards Dale Jct"?
            Last edited by R. Steele; 06-30-2017, 21:22.
            Cheers, Gerry
            "A mind is like a parachute. It doesn't work if it is not open." Frank Zappa
            It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.
            Forever, ridin' drag in railroad knowledge.
            Audi, Vide, Tace, Si Vis Vivere In Pace

            Comment


              #7
              No backward creep on Sherman Hill 0.8% - slight after 2+ mins running time, -0.1mph, easily compensated for.
              Using include files & provided 103 consist.
              Click image for larger version

Name:	bandicam 2017-06-30 19-50-01-024.jpg
Views:	1
Size:	202.9 KB
ID:	2195556
              Last edited by R. Steele; 06-30-2017, 22:03.
              Cheers, Gerry
              "A mind is like a parachute. It doesn't work if it is not open." Frank Zappa
              It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.
              Forever, ridin' drag in railroad knowledge.
              Audi, Vide, Tace, Si Vis Vivere In Pace

              Comment


                #8
                I am seeing different behavior before and after a save. That alone is a bug, and is irrelevant of backwards creep or ORTS physics included or not or what route I am using to test. The question is, is it contained there around the save function, or part of a bigger problem. I do find the coupler sensitivity very harsh, almost unrealistically so, on the front side of the save, and non-existent when restoring on the back side of a save.
                Last edited by geepster775; 06-30-2017, 22:42.
                My Open Rails videos https://www.youtube.com/channel/UClc...1kBPO2A/videos

                Comment


                  #9
                  Originally posted by geepster775 View Post
                  I am seeing different behavior before and after a save. That alone is a bug, and is irrelevant of backwards creep or ORTS physics included or not or what route I am using to test...
                  Maybe a bug, maybe not - Now a new element has been added, never mentioned in first post, about behavior before and after saves, and now backward creep and OR physics is irrelevent...but you introduced the physics problem in your first post.

                  The only buggy behavior I'm seeing is your aversion to using even the most basic proper OR physics found in the include files.
                  Just give the include files an honest try and report the findings...what it so confounded difficult about that, geepster?
                  Quit using the frankenfiles provided by TS for testing purposes.


                  Originally posted by geepster
                  In explorer mode, starting at Harriman, and heading towards Dale Jct, it requires the 5th notch just to keep the train from rolling away backwards. But even if I stay in the 5th notch, doing this no-win battle against gravity, after about a minute, the coupler knuckles between 2 cars somewhere in the train will break. If I go to the 6th notch earlier, knuckles will break immediately
                  As shown in screenshot (post #7) the behavior you describe is not observed on the Sherman Hill route when using the include files.
                  Of course, you could try the include files and add to the knowledge base by finding out if your observations hold true when using basic OR adhesion and friction parameters. Perhaps, I've made an error, would be delightful, although embarrassing, if you found it.
                  I'm just looking for the best and most accurate results.

                  ...And yes, I will agree that a behavior change before and after save, if documented and repeatable, could be a bug...but you seem to be zigging&zagging across different subjects.
                  Last edited by R. Steele; 06-30-2017, 23:58.
                  Cheers, Gerry
                  "A mind is like a parachute. It doesn't work if it is not open." Frank Zappa
                  It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.
                  Forever, ridin' drag in railroad knowledge.
                  Audi, Vide, Tace, Si Vis Vivere In Pace

                  Comment


                    #10
                    Originally posted by R. Steele View Post
                    Now a new element has been added, never mentioned in first post,

                    ...but you introduced the physics problem in your first post.

                    ...but you seem to be zigging&zagging across different subjects.

                    Why, yes, the process of deduction through public input can feature many twists, turns, wide swings and zig-zags. Yes, the flashlight of suspicion can swing around dramatically, from vendor-supplied files, to what the code is doing when it processes vendor-supplied files. And I admit this process is not for everybody. Some people just may throw up at the sight of the sausage being made.




                    Originally posted by R. Steele View Post
                    Just give the include files an honest try and report the findings...what it so confounded difficult about that, geepster?
                    I will. Just for you.

                    But you do me a favor, too. Go back to this from post #2

                    "Using the test track (and ORTS physics) I cannot pull the consist without breaking couplers - 1% grade, I set the couplers ridiculously high, and still could not move consist."

                    Do this again, but just before you notch out the final step to the point of breaking the couplers, do a save, and then bail and restore. Tell me if notching up fully after the restore still breaks the couplers then.

                    Heaven forbid we see the same result (now, suddenly success!) Why, that just might prove the choice of test track, and whether or not OTRS physics are involved are irrelevant (you have them, I don't, and yet we both are seeing the same sudden success result, post-save). That will point to a code problem that might need fixing before the remainder of the deductive process can resume without results being tainted.
                    My Open Rails videos https://www.youtube.com/channel/UClc...1kBPO2A/videos

                    Comment


                      #11
                      Regarding post#10, all good points, your suggestion at end of post..."Do this again,"... - makes a very good point, one that had escaped me (in my enthusiasm for inc files ) ... I will do as suggested. Be back with results.
                      Cheers, Gerry
                      "A mind is like a parachute. It doesn't work if it is not open." Frank Zappa
                      It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.
                      Forever, ridin' drag in railroad knowledge.
                      Audi, Vide, Tace, Si Vis Vivere In Pace

                      Comment


                        #12
                        Well that was easy...I agree, something is screwy after the save, duplicated your findings.
                        Test Track 1% grade, default consist and coupler settings as provided by TS- using include files in OpenRails folder.
                        Save point at 63%
                        Click image for larger version

Name:	SavePoint at 63%.jpg
Views:	1
Size:	202.1 KB
ID:	2195557

                        Coupler breaks after saving (but before exiting from sim) at 75% -
                        Click image for larger version

Name:	CouplerBreak after save.jpg
Views:	1
Size:	173.4 KB
ID:	2195558

                        Resume from Save, powering up
                        Click image for larger version

Name:	Power after Resume from save.jpg
Views:	1
Size:	202.5 KB
ID:	2195559

                        NO Coupler breaks at full throttle
                        Click image for larger version

Name:	FullThrottle-NO CouplerBreaks.jpg
Views:	1
Size:	201.3 KB
ID:	2195560

                        Two different routes, two sets of physics, two different operators..."the game is afoot" Nice bug spotting.
                        What now?
                        Last edited by R. Steele; 07-01-2017, 12:53.
                        Cheers, Gerry
                        "A mind is like a parachute. It doesn't work if it is not open." Frank Zappa
                        It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.
                        Forever, ridin' drag in railroad knowledge.
                        Audi, Vide, Tace, Si Vis Vivere In Pace

                        Comment


                          #13
                          I know this is an older thread, but I just came across it tonight.

                          Break ( 1112kN 1112kN ) - We use this setting for standard cars using a typical Type E coupler, assuming that typical coupler strength is about 250K lb/f

                          Break ( 1868kN 1868kN ) - We use this setting for locos, passenger cars, and newer coal and grain cars. This value is to represent a Type F coupler with the assumed ability to withstrand up to 420K lb/f

                          I'm sure you can always put these numbers lower if you want a challenge...if you ask me, three heavy engines on the head end provides enough of a challenge to prevent breaking couplers (Type E), even with these settings.

                          Cheers,

                          Jason@Trainsimulations

                          Comment


                            #14
                            Hi Jason,
                            I just noticed in Conbuilder that without the engines the mass of the loaded train (100 cars) is 13098.99 and the weight is 14670.86 US tons.
                            My question is: would 3 dash 8 engines (of roughly 4000 hp) be enough to move this train at a descent speed.

                            I tried the train on the Sandpatch grade starting at Roddy's spur(which is a 1 % grade) heading up hill. It wouldn't move an inch. I then changed the engines to three engines on the front 2 GEVOs and an AC44CW and 2 AC44CWs on the rear. This works out to about 1.75 hp per ton. I managed to get it up the hill but only at about 12-13 mph.

                            What do you think? is the train underpowered? or is it just the way it is with MSTS and open rails?

                            regards Tom

                            Comment


                              #15
                              My estimate, from being around prototype RR's with significant grades, is that a 13,000 ton train on a 1% grade would take 5 high horsepower locos and wouldn't be making great speed at that.

                              Comment

                              Working...
                              X