[steamer_ctn]

Coolhand101, on 11 September 2018 - 01:09 AM, said:

I think there may be a problem with the wind resistance. Can you try your CTN diesel activity, advance or basic. The loco/trainset will not get pass 5 mph as the wind resistance in the 1000s of ibs at that speed?

Hopefully corrected in #4205.

Thanks for spotting it.

[Jean-Paul]

Coolhand101, on 05 September 2018 - 03:57 AM, said:

I have just updated OR to x4185.

Using this feature, my EMU trains struggle to get pass 75mph on the level. The level balancing speed is 82mph. I have notice that the wind resistance is very high on certain coaches, namely the motor coaches. All the coaches have the same size but slightly difference mass.

My default EMU consist has this setup:

ENG+ENG+WAG+ENG.

If i use this test setup using the same mass and size as my default consist:

ENG+WAG+WAG+WAG

My EMU can get to 81-83mph on the level, depending on the wind strength and direction.

It appears the wind resistance is greatly enhanced if the consist has more than one engine, irrespectively of their size parameters.

Obviously these are my initial findings, so would the "ORTSWagonFrontalArea" and "ORTSDavisDragConstant" for my default consist that uses more than one engine, make the performance on par to my test consist?

I cannot seem to find any example setups on these two wind resistance parameters!

Thanks

Hello !
When you use two or more engines in a consist, those which are not ahead of the train must have a particular .eng file in which they are treated, in terms of friction parameters, as particular engines without full frontal contact with air. In the case of EMU/DMU in which a motor unit is completely integrated as a passenger car, you can determinate its resistance (with Fcalc 2.0, for instance) by considering it as a passenger car.
In the case where a motor engine is not completely integrated (for instance, "middle" or "push" engine in a freight train, I use to modify "C" term of Davis equation (A + BV + CV^2 - C is representative of aerodynamic forces), by reducing it @ 50 % of its "engine" value for a "middle-train" engine, @ 2/3 of its "engine" value for a "push" engine. By comparison with some real results, it seems to be reasonably realistic, but it compells to multiply .eng files. But, by this way, no differences of resistance following position of second engine in the train..
Cheers !
Jean-Paul

[Coolhand101]

steamer_ctn, on 11 September 2018 - 04:39 AM, said:

Hopefully corrected in #4205.

Thanks for spotting it.

Thanks peter. I will test this now!

Jean-Paul, on 11 September 2018 - 05:25 AM, said:

Hello !
When you use two or more engines in a consist, those which are not ahead of the train must have a particular .eng file in which they are treated, in terms of friction parameters, as particular engines without full frontal contact with air. In the case of EMU/DMU in which a motor unit is completely integrated as a passenger car, you can determinate its resistance (with Fcalc 2.0, for instance) by considering it as a passenger car.
In the case where a motor engine is not completely integrated (for instance, "middle" or "push" engine in a freight train, I use to modify "C" term of Davis equation (A + BV + CV^2 - C is representative of aerodynamic forces), by reducing it @ 50 % of its "engine" value for a "middle-train" engine, @ 2/3 of its "engine" value for a "push" engine. By comparison with some real results, it seems to be reasonably realistic, but it compells to multiply .eng files. But, by this way, no differences of resistance following position of second engine in the train..
Cheers !
Jean-Paul

Yes i have done similar on EMUs for years, however it was the wind resistance which was causing me problems!

As you describe above, Peter as now added this feature automatically for base and wind resistance on engines other than the leading front. You can also fine tune this with the resistance factor and other wind resistance parameters.

Over the years when using a single engine and coaches. From traction and performance graphs, i have achieved prototypical performance on level and certain graded track.

When the consist was double headed, i never did adjust the second engine friction parameters and only taken the extra performance from the addition engine power.

As i describe in the above test scenario, just under 5 mph was added because of the lower trailing engine resistance. So my double headed loco hauled stock was slightly under-performing from day one.

Shortly i will test a double headed class 33 loco with 8 Mk1 coaches to how much performance was lost
as my above test scenario. It probably be around the 5mph but i like testing things!

Thanks

[Coolhand101]

Peter

Using your CTN test route and the above activity. All is working correctly with the wind resistance on.


Many thanks for these addition train forces :sign_thanks:

[Coolhand101]

Testing my EMUs finally gave prototypical performance between long and short trains with still air and wind. Since MSTS and recently OR, there were tweaks to lower the Davis C parameter on trailing power cars to achieve this.

Now with this latest addition, the trailing power cars can now all have the same friction. This is mainly achieved by having these parameters in the leading power car :

   ORTSDavis_A ( 481.1 )
   ORTSDavis_B ( 11.5168 )	
   ORTSDavis_C ( 2.082575 )
   ORTSBearingType ( Roller )

   ORTSTrailLocomotiveResistanceFactor ( 0.40460 )
   ORTSDavisDragConstant ( 0.00035 )

For the above purpose, the Factor parameter is used when this car is not the leading car in a consist( No need for additional ENG files or consist changes ).

The drag parameter is used when the wind resistance is enabled.

For the former, the leading power car will produce a friction of say 1000Ibs at 90 mph. This same car as a trailer engine with produce a friction of 450Ibs.

The front coach will always produce that same friction. So with more traction motors on the consist, the EMU should perform better at high speed, as in the real world. And now it does in OR but prototypically.

4-car EMU level track balancing speed = 82.1mph

8-car EMU level track balancing speed = 84.3mph

12-car EMU level track balancing speed = 85.6mph


The parameters above work 100% with my trainsets. I only use these parameters on certain EMU/DMU consist with additional ENG files replacing WAG/Driving trailers.

I found because the middle coach was a power car, OR was reducing the friction too much as it is being class as a trailer ENG as well as the rear driving coach - also a trailer ENG. I was getting over 90mph on the level with my 4-car set. Hence the reason why these parameters are used!

Standard MSTS EMU/DMUs using Front engine and wags/rear engine and all other Engines/with coaches/wagons/double headed consists perform 100% 'out the box'. You can still use the above parameters for fine-tuning those consists.

The default KUJU EMU series 7000 uses a front engine, 9 wags and a rear engine. You can see the rear engine produces less friction than the front automatically!

All in all, the trailer engine friction and wind resistance has massively help the physics in this department.


Now i need to work the drag coefficient for wind resistance. The EMUs i use, have Cd of 0.80( blunt end but slightly angled with smoothing toward the sides. The class 47/50 locos have a Cd of 0.65

The easiest option is to divide the front area via the quoted cD of say 115 ft*2 to 90 ft*2 and using the ORTSWagonFrontalArea ( ) parameter. However, I'm open to more realistic methods.

Thanks

[steamer_ctn]

As a consequence of studying the code in OR for the coupler I have been forced to try and more fully understand the operation of a coupler, and I wanted to share a simplified view of my understanding of a coupler's operation (see attached diagram).

The diagram is based upon the operation of a AAR Type F Knuckle autocoupler, and shows the coupler force generated against the displacement (or extension) of the coupler. The type F coupler seems to have been reasonably well adopted world wide (as far as I can tell) for modern rolling stock. I appreciate that there are other coupler types in current usage, and also different ones used historically (see below for some thoughts on this).

As can be seen from the diagram I have interpreted 4 zones of extension for the coupler. Each of the first three extension zones contribute to the potential slack between each car, and hence the overall length of the train.

The current OR coupler appears to only model zone 1 and 3 operation (as far as I can tell), and thus I am contemplating the addition of an ADVANCED coupler function into OR which operates as closely as possible with the zones of operation shown in the attached diagram. However there is some level of effort required to code this, and I wouldn't want to embark on this endeavour if it does not have some degree of support and willingness by users to use it, and accept some of the challenges that it may introduce (described below).

Thus it should be noted, as pointed out in this post, that it will require some level of compromising between physics, and the visual appearances of rolling stock, as the potential slack between the cars can be quite significant, and thus gaps may appear between cars, etc.

It should also be noted that the current Coupler Force model shows very steady increases and decreases in coupler forces (see HUD view). However, a real coupler, due to the spring stiffness and damping, may have significant (coupler force) fluctuations, as the cars move backwards and forwards on the springs as force is applied to the couplers at each end of the car. Naturally these fluctuations are what can cause coupler breakages.

I am hoping that other coupling systems, such as Chains, Screw links, etc could be modelled by adjusting the relevant coupler parameters.

I would code the ADVANCED coupler so that it is only enabled in OR if the "Advanced Adhesion" model is selected, and a relevant "ORTSSlack" parameter is inserted into the WAG file coupler statements. The ADVANCED coupler will require reconfiguration of the coupler parameters in the WAG file, as legacy parameters may not give appropriate results for the coupler simulation.

So the question is, "is there an interest for the inclusion of an ADVANCED coupler model being included in OR based upon the relevant caveats"?

Attached thumbnail(s)

• 

[hroch]

steamer_ctn, on 12 September 2018 - 10:44 PM, said:

I would code the ADVANCED coupler so that it is only enabled in OR if the "Advanced Adhesion" model is selected

I do not think it's a good idea. The author of the eng file has no option to force this. I do not understand what has a common functioning coupling with the model of adhesion.

steamer_ctn, on 12 September 2018 - 10:44 PM, said:

a relevant "ORTSSlack" parameter is inserted into the WAG file coupler statements.

According to me this is the right solution.

[steamer_ctn]

hroch, on 20 September 2018 - 01:13 AM, said:

I do not understand what has a common functioning coupling with the model of adhesion.

My personal preference would be to see this renamed to "Advanced Physics".

Thus there would be two levels of physics, BASIC and ADVANCED.

BASIC would mainly cater for those users more interested in just seeing trains running rather then performing to a realistic set of physics physics. By using BASIC physics it would eliminate users having to struggle to start trains, with train wheels that are slipping, control brakes realistically, wonder why couplers are behaving the way that they are, etc.

ADVANCED would cater for those users who wish to operate a train in a realistic fashion according to train physics. This mode would require some effort on the part of the user in terms of configuring the stock as well as driving and understanding how the physics impact the train performance.

[superheatedsteam]

Personally I prefer realistic physics and don't mind the effort required to try and achieve them.

However I appreciate that some people prefer a basic mode for various reasons.

Cheers,

Marek.

[Mike B]

Could the modes not be just properties pages? So Basic mode would set OR physics and other properties to match MSTS and lock most of them (exposing for adjustment only those that were in MSTS). Advanced mode would unlock all physics properties. Physics packages could change a group of properties then lock them with a name for whodunnit. Maybe there might even be a Model Railroad mode where the controls are further simplified (go and stop with a single control, for instance). Or maybe that's the way it already is and I haven't seen them...