[Genma Saotome]

steamer_ctn, on 02 March 2016 - 01:34 PM, said:

Does the freight animations use the main FrictionForceN calculations in the MSTSWagon file?

If so, friction relies on the Davies co-efficients multiplied by the speed of the train. The Davis co-efficients are calculated externally to OR, and they do take into account the mass of the wagon (but only a full or empty wagon scenario). Therefore, for the main friction calculations (and possibly freight animations), variable weight is not considered at this time, but is fixed at the value of the Davies co-efficients in the WAG file.

To adjust the friction values for a wagon with a changing mass, the full suite of Davies formulas would need to be incorporated (and this wouldn't allow for some freelancing by modellers with different Davies co-efficients) into OR, with a means to differentiate between the different wagon types.

Alternatively, perhaps the full and empty Davis co-efficients could be included in the WAG file, and a sliding calculation done between these two limits to adjust the friction with a changing mass.

I have always believed the OR software should be computing the Davis formula(s) using the elemental parameters in the .wag file AND NOT as it is now, being calculated by FCalc and holding the results. As far as multiple Davis Formulas, surely it would be easy enough to use a Case Statement to select among the several variations as chosen by either the end (via the options page) or perhaps by the car/locomotive designer (via a code selection in the .eng or .wag). These could be identified by year or by recommending party (e.g., something like "The 1945 Davis formula"). People who care about the difference can pick one, everyone else can accept whatever is the default in the program.

FWIW, It would also be (IMO) advantageous for .wags and .engs to use EmptyMass() and LoadedMass() with the ultimate expectation that LoadedMass() would ultimately depreciate in favor of LadingMass() where LadingMass() is kept outside of the .wag or .eng -- IOW either in the consist file one of the or Activity files.

[longiron]

Let's us take a relatively real life scenario. We have a train with 5,500 US tons facing a 2.40% grade, using three mallet (2-8-8-0) locomotives generating about 300,000 tractive force. Converting that to HP based on http://www.alkrug.vc...ForcesCalc.html you get about 3,000 HP at 10 MPH which is pretty realistic performance. Let's calculate the impact of consumables - fuel and water

1. The Mallet Engine weighs in at 485,600 lbs (includes water in boiler)

2. Empty tender weights 206,400 lbs

3. Fuel and water adds 40,000lbs for coal (20 tons) and 96,000 lbs for water (@ 8lbs per gallon)

Total weight of fully fueled mallet locomotive = 485,600 + 206,400 + 40,000 + 96,000 = 828,000. Of which only 16% of the total ENG weight is consumables.

Total train weight is 11,000,000 lbs without engines, or 13,484,000 lbs including three fully fueled engines. Assuming 2/3 of consumables are used before refueling, then each engines would be 91,120 lbs or about 45 tons lighter at the end of the climb. Times three and you have 135 tons less weight.

So at the start the train weights in at 6,742 tons and at the end it weighs 6,607 tons. Inputting these weight changes into (http://www.alkrug.vc...ForcesCalc.html), you get about 1/10th of a MPH better performance up the grade for the same engine output

I would argue that the OR physics calculations are not accurate enough to worry about 1/10th of a MPH better performance because of reduced weight. Much ado about nothing! I'd rather see those CPU and memory cycles used elsewhere.

chris

[steamer_ctn]

Hi Carlo,

Csantucci, on 02 March 2016 - 01:44 PM, said:

if I look at the Update method within MSTSWagon.cs I see that MassKG is used many times within the code part that computes friction, and MassKG is modified few lines below accordingly to the percentage of load.

Based upon my understanding of the code there appears to be three scenarios allowed for in the friction code:
i) Invalid friction code - lines 719 - 732 - MassKG used to calculate "default Davis values". Friction values missing from WAG file?
ii) Default MSTS friction format - lines 736 - 772 - reverse engineered MSTS format into Davis values. - No MassKG used by OR (accounted for by figures calculated and entered in WAG file)
iii) Davis data from WAG file - lines 788 - 901 - MassKG only used for starting friction calculation (ie < 5mph), normal running friction is calculated using the Davis values from the WAG file

Thus apart from option i) above (which would not (IMO) be a favored data entry option for OR), I still cannot understand how the friction values are varied with Mass.

In an attempt to confirm this I have used the load animation activity at the bottom of this page.

Run this activity and note the starting friction force for the wagons. Run at a speed over 10mph, and note the normal running friction force.

Then fill one of the wagons, and note the starting friction force. It has increased with mass added to the wagon. However once the wagon exceeds approx 6 mph, and it swaps from starting resistance to normal running resistance, it reverts to the same value as the empty wagons.

These wagons are set with Davis values in the WAG files, and I suspect that the "MSTS format" wagons will not vary for either starting or running friction.

Thanks

[gpz]

Genma Saotome, on 02 March 2016 - 02:32 PM, said:

I have always believed the OR software should be computing the Davis formula(s) using the elemental parameters in the .wag file AND NOT as it is now, being calculated by FCalc and holding the results. As far as multiple Davis Formulas, surely it would be easy enough to use a Case Statement to select among the several variations as chosen by either the end (via the options page) or perhaps by the car/locomotive designer (via a code selection in the .eng or .wag). These could be identified by year or by recommending party (e.g., something like "The 1945 Davis formula"). People who care about the difference can pick one, everyone else can accept whatever is the default in the program.

I fully agree with Dave that requiring to enter an FCalc-precalculated value is not the way to go on long term. Actually the number of Davis formulas can be narrowed down to 4-5 variations for each component, as I recall it from an old discussion. Nothing happened in the past 2 years about it, and I still think the current ORTSDavis_A-B-C parameters should be considered as just overrides (hacking possibilities).

[Genma Saotome]

longiron, on 02 March 2016 - 02:42 PM, said:

<reasonable argument deleted for brevity>
I would argue that the OR physics calculations are not accurate enough to worry about 1/10th of a MPH better performance because of reduced weight. Much ado about nothing! I'd rather see those CPU and memory cycles used elsewhere.

chris

OTOH there is the argument for just getting it right. The CPU cycles are there: the game loop has them available; Adding VariableMass( T|E|A ) -- Time based, One Time event based (e.g., loads, unloads), set by the activity) would minimize the occurrence of such calculations to exactly when it makes sense.

There is a side effect of having the .engs and .wags show the empty weight, at least for .wags: If you let each .wag be the empty weight and assign it's final weight elsewhere, such as in the .con file, you'll see a big reduction in the number of .wag files across the board. No longer will people need to set up two .wags: one for empties and the other for loads -- only need an empty car .wag.

[Genma Saotome]

<Admin comment>

Chris, I felt our discussion was drifting too far from this topic so I have split off those posts into a new thread: Discssing Include files. Let's continue that subject there.

[steamer_ctn]

A blueprint was raised to cover some of the discussions in this thread.

Work is commencing on this blueprint, and over the coming weeks there will be some changes made, with Carlo's support to try and allow for the following variations with mass.

• Friction() - adjust friction with mass

• MaxBrakeForce() - adjust friction with mass

To accommodate these changes it will be necessary to introduce loaded and unloaded parameters for the following.

EmptyORTSDavis_A ( x )
EmptyORTSDavis_B ( x )
EmptyORTSDavis_C ( x )
EmptyMaxBrakeForce ( x )

FullORTSDavis_A ( x )
FullORTSDavis_B ( x )
FullORTSDavis_C ( x )
FullMaxBrakeForce ( x )


These parameters will be incorporated into the current freight animation code.

These values will then be used to adjust the friction and braking force for the relevant stock depending upon load.

It is also hoped to include the variation in mass of the locomotive and tender.

[sim-al2]

One suggestion, perhaps for the long term, but empty and full settings for traction physics (primarily, the ORTSTractionCharacteristics tables) would be nice too. A lot of passenger multiple units (especially electric units) can increase their performance as passenger loads increase, to make up for the increased weight.

[Genma Saotome]

steamer_ctn, on 03 May 2016 - 02:18 PM, said:

To accommodate these changes it will be necessary to introduce loaded and unloaded parameters for the following.

EmptyORTSDavis_A ( x )
EmptyORTSDavis_B ( x )
EmptyORTSDavis_C ( x )
EmptyMaxBrakeForce ( x )

FullORTSDavis_A ( x )
FullORTSDavis_B ( x )
FullORTSDavis_C ( x )
FullMaxBrakeForce ( x )

No, not that, please.

Capture the parameters that you punch into fcalc and compute the result and get rid of that A, B, C stuff. For mass() you need Mass_Empty() and MassLading() where the later may be fixed (a load of lumber) or something that varies such as passengers, coal, whatever. When attention is finally turned to making a modern AE you can add events that change the value of MassLading() by some fixed amount and use a different one that changes by some rate.

What you've got above is (1) not fixing the friction code and (2) locking in a value of Mass() for the lading that can never change. No loading of coal, no unloading of coal, no variable passenger count, no reduction in weight on account of using or replenishing fuel.

In the long term MassLading() belongs outside of the .wag file, either in consist or somewhere in one of the activity files (maybe a new one). That way you have one and only one .wag for a mess and it's animation mesh.

[disc]

I thought friction is already calculated with mass.