[darwins]

Sorry, this is going to be a long post. Having a better model of propagation along the brake pipe could remove a lot of other complications of the brake system that have built up over the years.

The original OpenRails brake propagation model seems to have started with three false assumptions
( i ) all brake systems have equalising reservoirs
( ii ) propagation is always from the front of the train to the rear
( iii ) propagation time depends on the number of vehicles rather than on the length of the brake pipe(s)

Most automatic air brake systems include an equalising reservoir, most automatic vacuum brake systems do not.
Non-automatic brake systems (direct vacuum, direct air, SME) do not generally include an equalising reservoir.

On long freight trains in USA the brake valves on helper locomotives at the rear of the train (or in the middle) can be operated from the leading locomotive. Thus reduction or increase in brake pipe pressure can take place in both directions and from more than one location. In a similar way in UK Inter City 125 and Inter City 225 train sets were arranged so that brake applications took place from both ends of the train at the same time. (In this case release was only in one direction from the front.) This is not possible in OR as even if locos at the front and rear of a train are both set up with "EP" brakes, reduction in brake pipe pressure still only moves backwards from the front.

In OR at present the time taken to release the brakes on a 300m long train of 50 two axle wagons can be the same as that for a 1000m long train composed of 50 bogie vans. Also for some strange reason the time taken for brake signals to be passed on by a "piped" wagon is longer than that taken for signals to be passed on by a "braked" wagon.


** Would it be possible to replace the current propagation model with one based on fluid dynamics, simplified if needed, that would calculate the changes in brake pipe pressure based upon
* length of the brake pipe(s) - based on length of vehicles;
* diameter of the brake pipe(s);
* differences in pressure between wagons or cars;
* volume of air entering or leaving the system (particularly where no equalising reservoir is present)?


This would apply to both air and vacuum systems. A different would be needed for mechanical train brakes and manual braking.


What new factors would be required? So far as I can see only two user inputs would be needed.

( a ) Train brake pipe diameter - entered by the user when not a default value.
[ suggested default 1 inch for air brakes on passenger cars, 1.25 inch for air brakes on goods wagons and locos, 2 inch for vacuum brakes ]

( b ) Presence of an equalising reservoir in the train brake controller - entered by the user when not a default value.
[ suggested default 1 for air_single_pipe, air_twin_pipe, EP and ECP; 0 for all other brake systems ]

This logically moves the equalising reservoir from the Wagon ( BrakeEquipmentType ( ) ) to the Engine ( [Train Brakes Controller] ) section.
It would also make redundant the designation Wagon ( BrakeEquipmentType ( Vacuum_Eq ) ) and unnecessary the addition of a BrakeEquipmentType ( Air Non Eq ).


What existing factors could be simplified or made redundant?

Trying to make propagation function realistically with the existing model has led to the introduction of a number of factors into OR, which so far as I can tell were never required for legacy MSTS files:

ORTSBrakePipeTimeFactor ( x )
ORTSBrakeServiceTimeFactor ( x )
ORTSBrakeEmergencyTimeFactor ( x )
ORTSBrakePipeDischargeTimeMult ( x )

If the behaviour of air in the brake pipe was modelled more reastically depending on the system size and pressure then these factors may no longer need to be adjusted.

Such changes might also make it easier to set up train brake controllers that do not include equalising reservoirs.

At the moment the following only apply to brake controllers with equalising reservoirs:

TrainBrakesControllerMaxReleaseRate ( x )
TrainBrakesControllerMaxQuickReleaseRate ( x )
TrainBrakesControllerMaxApplicationRate( x )
TrainBrakesControllerSlowApplicationRate ( x )
TrainBrakesControllerEmergencyApplicationRate( x )

They do not work with train brake controllers that do not have equalising reservoirs, even though the related parameters for EngineBrakesController... apply to the engine brakes which do not normally contain an equalising reservoir.

Since TrainBrakesControllerMaxApplicationRate( x ) and TrainBrakesControllerEmergencyApplicationRate( x ) are used by TCS scripts this also means that TCS brake applications do not work with brake controllers that do not have equalising reservoirs. This seems wrong as the TCS application should act on the brake pipe and not on the equalising reservoir!

Tidying this up might also mean that that a number of brake tokens developed only for vacuum brakes would no longer be needed.
For example we might no longer need to use

Brake_Train ( 0 1 0.2 0.2
NumNotches( 3
Notch(0 0 TrainBrakesControllerReleaseStart )
Notch(0.2 0 TrainBrakesControllerRunningStart )
Notch(0.3 1 TrainBrakesControllerVacuumApplyContinuousServiceStart ) ) )

with the application rate defined by ORTSBrakePipeTimeFactor ( x ) and ORTSBrakeEmergencyTimeFactor ( x )

and might be able to return to the same controller as used for air brakes and in MSTS files

Brake_Train ( 0 1 0.2 0.2
NumNotches( 3
Notch(0 0 TrainBrakesControllerReleaseStart )
Notch(0.2 0 TrainBrakesControllerRunningStart )
Notch(0.3 1 TrainBrakesControllerApplyStart ) ) )

with the application rate defined by TrainBrakesControllerMaxApplicationRate( x ) (or perhaps not user defined at all, as in a simple system this depends only on the diameter of the pipe and the pressure)!

[Weter]

Hello.
I'm uncertain now, do You mean auxiliary reservoirs, belonging every wagon with particular brake system, or equalizing reservoire, which is part of some train brake controllers (other major part is brake valve self), mounted on locomotive?
ER is needed for quicker setting desired pressure by hand (it's 8-12 or 20liters volume only), than BP's pressure will be equalized and maintained equal to ER's pressure automatically by valve, so no need to wait and control that process by driver.
AR contains deposit of compressed air for filling Brake cylindre(s) under particular vehicle, create sufficient pressure there and maintain it in case of brake pipe's breaking down with opening to atmosphere.

For doubled train, brake pipe of first consist HERE is being connected to the driver's valve of the second consist's leading locomotive, instead of equalizing reservoire. As long, as latter is set to "lap with feed" position, pressure in the end of first consust's BP sets pressure in second consust's BP, being fed by second locomotive's compressor and main reservoirs. Too air release is performed by second locomotive's brake valve and air distributors under each wagon of consist.

Brake pipe length often is much longer, than vehicle's length, especially on locomotives. And it's volume is added by all its branches to stop valves, sensors, and air distributors volume, so it would be good to specify said volume better.

[engmod]

Hi Darwin,

I have been pondering about brakes for the longest time.
I have never found the settings that I consider should be authentic.

I will put my hand up for any testing that you may wish to do.

[darwins]

Quote

I'm uncertain now, do You mean auxiliary reservoirs, belonging every wagon with particular brake system, or equalizing reservoire, which is part of some train brake controllers (other major part is brake valve self), mounted on locomotive?
ER is needed for quicker setting desired pressure by hand (it's 8-12 or 20liters volume only), than BP's pressure will be equalized and maintained equal to ER's pressure automatically by valve, so no need to wait and control that process by driver.

I am discussing ER. If the driver's brake valve has an ER then it will allow air to enter or leave the brake pipe until the air pressure along the length of the train is the same as the air pressure in the ER.

When there is no ER, the driver must guess (based on experience) how much air to let into or out of the brake pipe. When the driver returns the brake valve to the 'Lap' position no further air will enter or leave the brake pipe. The air that is already in the brake pipe will spread out along the length of the train until the pressure is even all along the train.

Quote

Brake pipe length often is much longer, than vehicle's length, especially on locomotives. And it's volume is added by all its branches to stop valves, sensors, and air distributors volume, so it would be good to specify said volume better.

This is true. A paper on brake propagation suggested that to match the behaviour expected by fluid dynamics calculations that the length of the brake pipe should be considered as 3 times the length of the train.

Unfortunately I don't have a figure for vehicles that are through piped, but not braked. As there are no branches I would guess that in that case we might think of 1.5 x vehicle length.

[Weter]

1. I agree: manometer on locomotive will have a delay in indication. Experience is indeed needed.
2. Probably, yes. At least, pipes are making X-over under car's bottom for appearing on proper side on each of car's ends.

[cesarbl]

Quote

The original OpenRails brake propagation model seems to have started with three false assumptions
( i ) all brake systems have equalising reservoirs
( ii ) propagation is always from the front of the train to the rear

Let's ignore these at the moment, since they are not affecting propagation itself. They are only related to the driver brake valve. I'd prefer to keep things separated for clarity.

Quote

( b ) Presence of an equalising reservoir in the train brake controller - entered by the user when not a default value.

This sounds great, but let's focus on propagation (and air dynamics in general). We have to get that working first.

Quote

** Would it be possible to replace the current propagation model with one based on fluid dynamics, simplified if needed, that would calculate the changes in brake pipe pressure based upon
* length of the brake pipe(s) - based on length of vehicles;
* diameter of the brake pipe(s);
* differences in pressure between wagons or cars;
* volume of air entering or leaving the system (particularly where no equalising reservoir is present)?

Some papers for this are welcome. I'd like to have at least two of them for comparison and analysis.

[darwins]

cesarbl, on 16 July 2023 - 06:39 AM, said:

Let's ignore these at the moment, since they are not affecting propagation itself. They are only related to the driver brake valve. I'd prefer to keep things separated for clarity.

This sounds great, but let's focus on propagation (and air dynamics in general). We have to get that working first.

Some papers for this are welcome. I'd like to have at least two of them for comparison and analysis.

Certainly direction will not affect propagation and can therefore be ignored until the model is working.
My concern with the EQ RES is not knowing the volume of air that has entered or left the system - also thinking it might be easier to add than remove!

I will PM you links to some papers that may be useful.

[dajones]

I have an air brake simulation that is based on this paper: Railway Air Brake Model and Parallel Computing Scheme. The simulation described in the paper uses a time step of .1ms and they model the brake pipe in 1 meter lengths. They used 8 cores at 100% to model the brakes on a 150 car train in real-time, and they didn't simulate anything else. My implementation uses a 1ms time step and it models the pipe in car length increments. I did have to limit the air speed in one direction to prevent oscillations that caused accidental brake release. My C++ code is at https://github.com/dajones42/rmsim in the airtank.cc and brakevalve.cc files.

Doug

[pschlik]

I recently stumbled across this dissertation which included multiple differential equations for not only simulating the brake pipe but also the locomotive control stand and triple valves and it generally produced quite accurate results even after some simplifications. It's from years ago so modern computing power should be more than enough to simulate this in real time.

[steamer_ctn]

Here is another paper.

For the most accurate outcome, I think that it is important to remove any reliance on brake timing parameters (except for legacy purpose) as these are mostly guesstimates or apply to a particular scenario, and instead we should only use real world parameters that OR can then use to calculate accurate propagation values.

Hence using all the "key" elements of the brake system, such as brake cylinder volumes, reservoirs, brake pipe volume, etc, I believe will give the most realistic outcome.