[Genma Saotome]

Is there anything in OR that addresses a value of Mass() that varies within the activity? Examples are consumption of fuel by diesel locomotives, consumption of fuel and water in steam locomotive tenders, refueling of those just mentioned, and possibly open top cars when they take on or dump their loads (e.g., coal).

The question came to mind when I was reviewing some locomotive specifications and saw an 8t difference between unfueled and fully fueled... and the .eng file specification was in the middle.

Varying weight will have an effect upon both braking and friction; The locomotive I was reviewing was almost always used in sets of 4 units, often 5 or 6 and so the combined extent of potential variation could be as much as 48t. I would expect that number would be greater on modern locomotives as they are so much heavier. The difference between empty and fully loaded open tops cars is often 4-5X the weight of an empty car.

[Csantucci]

Genma Saotome, on 01 March 2016 - 04:37 PM, said:

Is there anything in OR that addresses a value of Mass() that varies within the activity? Examples are consumption of fuel by diesel locomotives, consumption of fuel and water in steam locomotive tenders, refueling of those just mentioned, and possibly open top cars when they take on or dump their loads (e.g., coal).

The question came to mind when I was reviewing some locomotive specifications and saw an 8t difference between unfueled and fully fueled... and the .eng file specification was in the middle.

Varying weight will have an effect upon both braking and friction; The locomotive I was reviewing was almost always used in sets of 4 units, often 5 or 6 and so the combined extent of potential variation could be as much as 48t. I would expect that number would be greater on modern locomotives as they are so much heavier. The difference between empty and fully loaded open tops cars is often 4-5X the weight of an empty car.

At least for the cars provided with the OR-specific freight animations (continuous type) the mass is variable and depends on the amount of freight load.

[Hamza97]

I always set the .eng file parameters for for fully fueled locomotive. OR then reduces the weight of locomotive as the fuel gets used up. Just tomorrow I completed a 150 km run with a diesel locomotive (18 passenger coaches - 868t total train weight, 110kmph max permitted speed, FYI). The locomotive was fully fueled (6000 litres) and weighed 126 tons, by the time I finished the run it was 125.5 tons. So that locomotive was lighter by 0.5 tons. Don't know if that's correct.... :)

[Coonskin]

FWIW:

Real world experience w/US railroading: And an engine with a large (3000 US gal.) tank that's full will hold the rail better than one tha's near empty.

[Lindsayts]

Coonskin, on 02 March 2016 - 05:14 AM, said:

FWIW:

Real world experience w/US railroading: And an engine with a large (3000 US gal.) tank that's full will hold the rail better than one tha's near empty.

3000 US gal of diesel would weigh aprox 21,000 lbs around 9700Kg.

Lindsay

[sim-al2]

The ability to specify passenger weight would be nice too. Many commuter and subway vehicles have load compensation valves that react to vehicle load, and vary braking and propulsion levels proportionally. However, older vehicles didn't, and heavy loads required the driver to compensate properly.

Freight cars are rather interesting in this regard too. European railways had freight cars as early as the 1920's with manually-set brake proportion levers (Empty/Load Lever) under the car, usually with 2 or 3 positions that were to be set depending on the car's load, to ensure that loaded cars could be run with reasonable braking performance without risking skidding on the empty cars. In modern cars, these manual valves are often replaced with automatic proportioning valves, which offer continuous adjustment of braking power. Similar valves are also found in modern North American cars, especially cars with fairly large differences between empty and loaded weight, such as coal gondolas.

[Genma Saotome]

Interesting. So OR does change the weight in some situations.... The values of these parameters are all influenced by the value of Mass():

• Friction()
  
• MaxBrakeForce()
  
• DerailRailForce()
  
• DerailBufferForce()
  
• actual adhesion

Do they also change as the weight changes?

[Csantucci]

Friction is recalculated at every program loop and has the mass as one of its parameters. Therefore friction dynamically depends from mass (at least for OR-specific freight animations).

[steamer_ctn]

Csantucci, on 02 March 2016 - 12:32 PM, said:

Friction is recalculated at every program loop and has the mass as one of its parameters. Therefore friction dynamically depends from mass (at least for OR-specific freight animations).

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.

[Csantucci]

Peter, 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.

[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.