I am currently facing some difficulties in the design of an algorithm and hope that programmers have some ideas. I am not asking for code contribution, only for ideas.

The scenario is brake pipe pressure propagation. In openBVE, each car has a single variable that stores the current pressure of the brake pipe. For your information: The brake pipe is a pipe running from the very first car to the very last car of the train. For sake of simplicity, we can assume that the volume inside the brake pipe remains constant throughout the simulation, and also its surface area. In the case that there is a pressure rise or drop on some car, we want the pressure to propagate over time until an equilibrium is reached, meaning until all cars have the same pressure in the brake pipe. Of course in reality, the brake pipe is a continuous entity, while in the simulation, we simply simulate one point of the brake pipe per car.

An algorithm that does pressure propagation needs to follow these rules: A time difference is given (in seconds) that corresponds to the difference since the last execution of the algorithm. Additionally, the distance between each car is known (in meters) and needs to be incorporated. The algorithm needs to make sure that the average pressure in the brake pipe remains constant after one iteration, meaning it is not allowed to add or subtract pressure overall, only to more equally distribute it along the cars. There can be any kind of flow rate constant, but is not allowed to be infinite.

I am asking for ideas because my previous implementation are flawed. I will present a simple not working algorithm that does not even meet the above criteria just to show what such issues can be.

1) Mean algorithm between cars
For each car, calculate the arithmetic mean of its own pressure (X) and those of the adjacent cars (A and B), i.e. (A+X+B)/3. For the end cars, use the form (A+X+X)/3 instead. One can show that the total pressure in the train, e.g. for three cars: (A+A+B)/3 + (A+B+C)/3 + (B+C+C)/3 is equal to A+B+C, so at least the total pressure remains constant. This showcase scenerio does not include time or distance though, and one might expect that with high frame rates, it converges extremely fast. However, this is absolutely not the case. The reason is probably related to the fact that if car A has some pressure and all the others have 0, after one iteration, car B will have a pressure of A/3; in the next iteration, car C will have a pressure of B/3 = A/9 and so forth. So convergence is - don't know how to phrase it - maybe logarithmically (or exponentially with a negative exponent?) Either way, regardless of how you call it, it is extremely slow.

2) Current openBVE algorithm between cars
We have a flow rate measured in Pa*m/s (pressure * length / time), which is a constant. For each car, the up to two adjacent cars are compared. If the current car has a higher pressure than any of the adjacent cars, we first calculate the pressure difference D (in pascal) to the respective car. Then, we multiply the flow rate constant (Pa*m/s) by the time difference (s) and divide by the length between the cars (m) to arrive at the maximum pressure P (Pa) that can be exchanged in the current iteration. If P>D, we limit P to D. If P > current brake pipe pressure in this car, then we further limit P to that value. The brake pipe pressure in the current car is then reduced by P/2 and that of the adjacent car increased by P/2. Note that "new pressure" and "old pressure" are separated, so all of the calculations query the old values and derive new values to be applied simulaneously. The exchange is P/2 for two reasons: First, it ensures that in the next generation, the other car will not exchange the same amount of pressure back to this car, and second, that if pressure is exchanged between both adjacent cars, only half the current pressure can be exchanged to either one. Unfortunately, while this algorithm implements both the time and distance constraints, it suffers from the same logarithmic (?) rate of conversion, thus the anticipated flow rate is not actually achieved. I am currently using a value of 1,000,000,000 Pa*m/s, meaning that theoretically, given a maximum pressure difference in the brake pipe of 500,000 Pa (500 kPa) and a total length of the train of 300 m, it should only take 0.15 s to propagate a particle from one end of the train to the other, but an equilibrium only forms in 2-5 minutes in openBVE's reality.

3) Instantaneous distribution over all cars
In order to eliminate the convergence problem, I recently experimented with the following idea. If we continue to measure flow rate in Pa*m/s (pressure * distance / time), then given a constant, one can rearrange the formula Constant=Pressure*Length/Time to Pressure=Constant*Time/Length, corresponding to the pressure that could be exchanged over a given distance in a given time. If we, for every car A, calculate for every other car B the value Pressure=Constant*Time/Length, where Length is the total length from car A to car B, then we have the pressure that could be exchanged between cars A and B under the time and distance constraints. What I did was for car A to create an array B[] with all those pressure values. Of course, if we sum up all the pressure values in B[], we might exceed the pressure currently available in car A. So what I did was to normalize B[] so that the total pressure in B[] would be the same as in A. Now, we simply transfer all pressure of A to all other cars B given the weights in B[]. This means that every car will transfer its own pressure to all of the others. One issue is that as the distance between A and A is zero, one cannot meaningfully include A itself in B[], so I left A in B[] at 0. Interestingly, this algorithm converges perfectly quick. But there is conceptual problem: Once an equilibrium forms, one might expect all cars to have the same pressure. Not with this algorithm: The center car will have a peak pressure and the outer cars the lowest pressure. That is the equilibrium. The algorithm further has the problem that it does not prevent a car from having more pressure available than is possible.

As such, if you have ideas how one could implement a pressure/flow/propagation algorithm with the constaints of including time, length and some flow constant (whatever unit), I am open for these ideas. Things that might help conceptually: We can assume that the surface area and volume of the brake pipe is constant. As pressure is Mass * Acceleration / Area, and the area is constant, it can be accounted for in the flow constant and is otherwise irrelevant. Furthermore, unless one includes the acceleration due to gravity in the algorithm, Acceleration is also constant and thus irrelevant, thus for the purpose of the simulation, Pressure behaves the same as Mass, meaning one can visualize the propagation as exchange of mass or particles instead of thinking in pressure.

If you are interested in looking at the revelant parts of the source code: The file is TrainManager.cs and the procedure is called "private static void UpdateBrakeSystem(ref Train Train, double TimeElapsed, out double[] DecelerationDueToBrake, out double[] DecelerationDueToMotor)", and the relevant code starts with the comment "// propagation" and ends at the comment "// apply". There are other things in that source such as brake pipe leaks, which are irrelevant here.

Hello!

michelle wrote:I am currently using a value of 1,000,000,000 Pa*m/s, meaning that theoretically, given a maximum pressure difference in the brake pipe of 500,000 Pa (500 kPa) and a total length of the train of 300 m, it should only take 0.15 s to propagate a particle from one end of the train to the other.

In this case, the speed distribution of air wave is 300 m/0.15 s=2000 m/s, which is greater than the speed of sound in air v=20*sqrt(273+20)=342 m/s. This can not be.

I think that pressure be distributed in the brake line you want on your third option. We need to operate with the concept of velocity of the air waves in the brake line under braking and in the release. The speed of the air waves in the brake line under braking is defined as by dividing the length of the train at the time that has elapsed from turning the handle until you tap the pressure in the cylinder of the last wagon. Similarly, the speed of the air waves in the brake line with the release is defined as by dividing the length of the train at the time that has elapsed from turning the tap handles to start reducing pressure in the cylinder of the last wagon.

With this in mind, I offer these thoughts for the algorithm.

Initial data:
1. The speed of the air waves in the brake line during braking Vt, about 300 m / s.
2. The speed of the air waves in the brake line when releasing the brakes Vr, about 50 m / s. (These values are used to calculate the braking systems of the Russian freight trains).
3. The length of the car L, m.
4. The calculation must start with the locomotive.

The algorithm under braking and releasing identical, except for speed of the air waves during braking or releasing:
1. The driver changed the pressure in the brake line on the value of D. The change of pressure in the brake line of the next car of the same magnitude will occur in time T=L/Vt (or Vr).
2. If the pressure is equal pressure valve on the car, it increases (or decreases) the pressure in the cylinder.
3. The next change will occur in the car the same time, and so on until the end of the train.

Graphically change in pressure in the brake line and brake cylinders look like this


I hope all of the above may be helpful.

P.S. Hard on my English! Two hours of writing this message . But I am interested in this issue.

As far I have understood, you basically describe how to repeat the brake pipe pressure of the locomotive on other cars in a delayed fashion. However this does not integrate into the architecture for several reasons. First, there might be more than one source of sudden pressure change, e.g. multiple cars having air compressor and main reservoir connected to the brake pipe, brake pipe leaks, rupture of the pipe on derailments, etc. Second, if you had the brake pipe at a constant (high) pressure and then immediately set the brake pipe pressure in the locomotive to a low value, the other cars would repeat the low value, which does not guarantee that the mass in the brake pipe remains unaffected by the propagation algorithm. So, none of the conditions that I asked for are met.

For everyone interested in an illustration and source code (C#) to test own ideas visually, see the attachment.

I have closely watched the program "PressureDistribution.exe". I think the speed of distribution of pressure does not correspond to reality. The speed of the brake pressure distribution strongly higher (300 m / s) than in the program, and upon release of much lower (50 m / s). And you, the same rate for both cases.

if you had the brake pipe at a constant (high) pressure and then immediately set the brake pipe pressure in the locomotive to a low value, the other cars would repeat the low value, which does not guarantee that the mass in the brake pipe remains unaffected

But exactly what will happen in reality! If the train length of 300 meters, to reduce the pressure in the first car (let's stop-cock) from 0.8 MPa to 0 MPa, then through a one second in the last car pressure drops from 0.8 MPa to 0 MPa. I have therefore proposed non-iterative algorithm for calculating the pressure drop.

yabay wrote:But exactly what will happen in reality!

Exactly this is what cannot happen in reality, sorry. Pressure is Mass times Acceleration per Area. Assuming a constant acceleration and area, any pressure change will correspond to a change of mass. If locomotive A and trailer car B each stored a mass of air of 3 kg, and suddenly, I take out 2 kg of air off locomotive A so that 1 kg remains, then you say that the mass in trailer car B will drop to 1 kg also. But where do the 2 kg of air go that where previously in the trailer car B? They won't vanish. Instead, the air distributes to 2 kg in locomotive A and 2 kg in trailer car B. That is what I mean by distribute or propagate. The air will flow from high pressure to low pressure until an equilibrium forms. Your "algorithm" on the other hand simply repeats the pressure of a locomotive but does not explain where the air comes from or where it goes. A distribution algorithm must keep the amount of air constant throughout the brake pipe, only better distribute it until all cars have equal pressure.

I think the speed of distribution of pressure does not correspond to reality.

I hope you have actually read my first post. I have started this thread exactly because any current algorithm I use does NOT work. The constraints are that any flow rate should be actually achieved, but my algorithms don't do that. I have set the flow rate to an unrealistically high value in openBVE exactly because the algorithm does NOT work as intended and it was the only way to make at least something usable out of it. If you tell my that my demonstration program does not work, then you only repeat what I was talking about all the time. My algorithms suffer from a convergence problem, and I have also explained why this is. What you can do with the demonstration program is to see about how a distribution algorithm should work, and it gives you a testbed to easily test your own ideas. Everyone who can at least do something in C/C++/C# will have no difficulties in testing some ideas. Basically, from a code point of view, there is an array of OldPressures[] and an array of NewPressures[], and what should happen is how one can derive the new pressures from the old pressures after some time TimeElapsed has passed, taking into account a flow rate and the distance between the cars. Feel free to experiment.

what about the EP-commanded braking on EMU's, DMU's and hauled/pushpull passengertrains?
ElectorPneumatic, it means that the brakecommand has been passed at each brakedistributer of a passenger coach by a electrical wire at the SAME time while applying and releasing the brakes so the airflow occurs at each carlength at aproximatly the same moment

How is this question relevant to the topic?

I want to summarize: My question does not involve the design of a brake system, but simply asks how one can derive an array of new pressures from old pressures (measured at the center of a car), taking known distances between the cars, the time that elapsed since the last call of the algorithm and a flow rate into account (where the flow rate needs to be actually achieved). Of course I assume that it is possible to model the flow of a fluid via such discrete samples per car.

I have thought about a series of refinements to my algorithms, but not yet tested any. So, for those who followed this thread so far and are interested in the outcome:

Let's assume a simple scenario with apples: {3, 2, 1}, meaning the first car has 3 apples, the second car has 2 and the third car has 1. We further assume a flow rate of 1 apple of exchange between the cars per execution of the algorithm. The ideal scenerio would be if one apples flow from the first to the second car, and simultaneously, one apple from the second to the third car. This makes the situation end up in the perfect equilibrium of {2, 2, 2}. However, my current openBVE algorithm does this: At the first car, it checks the neighboring cars and determines that the second car has less apples than the first car, so it tries to give as many apples as would be required to make the two cars end up in equilibrium, which is 0.5 apples. The second car does the same with the third car, and the third car does nothing, because it cannot give any neighbors apples of its own. This makes the scenario end up in {2.5, 2, 1.5} after one execution of the algorithm. The effectiveness of the flow rate is only at 50%. In the next turn, this will yield {2.25, 2, 1.75}, with an effectiveness of 25%, and so on. Basically, any exchange between c cars will have an effectiveness of 0.5 ^ c. Over many cars, this converges to 0% effectiveness, albeit slowly.

A simple brute force method could form a first workable solution to this problem. Take into account that there is the flow rate constraint, so the algorithm should remember which amounts of pressure (or apples) were exchanged between two adjacent cars. Once this quota is reached, there cannot be any further exchange. If the algorithm simples executes multiple iterations per frame, the low initial effectiveness could be overcome. With two iterations, I assume the effectiveness to have reached 75%, with three iterations 87.5%, and so on. So basically, the effectiveness would be 1 - 2^-n, with n being the number of iterations per frame. If we want a particular effectiveness p at the end of the iterations, we have the formula 1 - 2^-n = p to solve for n in order to determine the number of required iterations per exchange between adjacent cars. However, taking into account that the effectiveness drops over many cars, even an effectiveness of 99% would drop to 98% over three cars, 90% over ten cars and 60% over 50 cars. To account for that, we combine the two above formulas to (1 - 2^-c) ^ n = p, and solve for n. This gives a required amount of iterations of -Log[1-p^(1/n)] / Log[2], which fortunately would make the algorithm of about c*O(log(c)) complexity as opposed to quadratic or exponential as I initially feared. As said, this conceals some of the underlying problems with such a simple exchange, but could achieve a constant effectiveness regardless of the amount of cars used.

Now that I have not yet tested this, I will try to implement it in PressureDistribution.exe and upload a new version once done. If there are programmers around who have different ideas, I am still open for then.

Nonetheless, an algorithm that would take the initial problem into account from the very start would still be better. I have, for example, played with this idea: {3, 2, 1}. If one apple was exchanged simulaneously from 1st>2nd and 2nd>3rd, we would be at 100% effectiveness. Starting with car 3, this car could "request" 1 apple, because that's the difference to its neighboring car. This request would be handled to the second 2, which determines that it is already in the average of its two neighbors, so tells car 3 that it would only give 1 apple if it got a replacement apple from one of its own neighbors. So it passes the same request to car 1, but tells car 1 that has only 1 apple itself (assuming that 1 apple would be given to car 3). This way, car 1 would determine that the average of its neighbors is 2, but itself has 3, so it could spare 1 apple. This way, the simultaneous exchange would in fact happen. However, this is more of an ideal example. As soon as there is no strict ascending or descending order of pressures in the cars, it get's more complicated, and a possible implementation that implements these requests (via recursion?) might pose additional implementational difficulties.

I'm not a programmer, so excuse me if this sounds as a foolishness, but, apart from the algorithm used, isn't it possible to add a delay variable set via the extensions.cfg (or train.dat) file, so that the train builder can "hand adjust" the result of the computation made by the algorithm ?

I don't know what you mean, but the only adjustable thing we could talk about is the value used for the flow rate. Again, for my algorithm to meaningfully work, the flow rate is measured in Pa*m/s. Taking into account that yabai said that a flow speed of around 300 m/s could be about all right, one could either use a fixed pressure in the constant (e.g. 490 kPa), or use the actual value used as the operating pressure in the brake pipe (variable and customizable), or any multiple/fraction thereof. Using the 490 kPa, my flow rate would thus be about 147,000,000 Pa*m/s. Once I update the demonstration tool, we can see if this a) makes sense and b) even works.

---

EDIT:
I have integrated my new idea into the demonstration tool, and basically, it works relatively well. There are two issue though, one I could solve. The first issue is that there is an assymmetry between increasing and decreasing overall pressure if I continue to use the approach where a car with higher pressure "gives" some amount of its own pressure to a neighbor. Increasing overall pressure seems to converge faster this way than decreasing it. Once I switched to "dragging" pressure from a higher pressured neighbor, I could observe the inverse effect. To solve this, I am switching between both approaches between iterations, which makes the algorithm symmetric again. The second issue that still remains is while I can increase the amount of iterations to approach arbitrarily well the perfect convergence, my numeric analysis posted earlier does not seem to hold for this algorithm. While the whole Iterations = -Log[1-Effectiveness^(1/Cars)] / Log[2] idea is not a bad start, it seems to be too low. If I square the amount of iterations though, this seems to be good enough. I don't know though whether the iterations could also be lower to achieve the same effect. Either way, play with the attached updated program. The flow rate seems to be almost perfectly achieved, but which value to use is still an open question.

Michelle,

I have a spreadsheet based iteration which seems to fulfill your criteria.

Basically you start with each car having an a value for the volume of air in its section of the train pipe. You then select a pressure change in the first car (car a) - assume a reduction in this case and use this to calculate the flow rate from car b to car a. The rate of flow is proportional to the square root of the pressure difference according to the laws of fluid flow. Likewise for all the other cars in the train. Each car has a flow constant in the form of the amount of air that flows per unit time per single unit of pressure difference between cars which characterizes the restrictions in flow for each car - valving, pipe diameter etc. It can be increased / decreased linearly with the length of the car.

For each cycle you can the calculate the transfer of air between each car and over time the whole pipe settles out at a new equilibrium pressure. The total volume of air in the system stays constant. Of course as the flow is proportional to the square root of the pressure difference the system never really reaches settle out pressure.....

I can send you the spreadsheet if you are interested. Below column one is time in seconds, columns QA, QB and QC are the volumes of air or pressure at each car. QT 4th column) is the total air. The rest of the columns are the flow rates between cars and the flow in the time increment. I apologise for the format - I could not easily past the spreadsheet here.

Time QA QB QC QT
0.10 5.00 100.00 100.00 205.00 4.47 1.00 21.24 0.00
0.20 26.24 78.76 100.00 205.00 1.73 1.13 4.55 1.20
0.30 30.79 75.41 98.80 205.00 1.56 1.14 3.49 1.34
0.40 34.28 73.25 97.46 205.00 1.46 1.15 2.85 1.40
0.50 37.13 71.80 96.07 205.00 1.39 1.16 2.41 1.40
0.60 39.54 70.79 94.66 205.00 1.34 1.16 2.09 1.38
0.70 41.63 70.08 93.28 205.00 1.30 1.15 1.85 1.34
0.80 43.48 69.58 91.95 205.00 1.27 1.15 1.65 1.29
0.90 45.13 69.21 90.66 205.00 1.24 1.14 1.49 1.23
1.00 46.62 68.95 89.43 205.00 1.22 1.14 1.36 1.17
1.10 47.98 68.76 88.27 205.00 1.20 1.13 1.24 1.11
1.20 49.22 68.62 87.16 205.00 1.18 1.13 1.15 1.04
1.30 50.37 68.52 86.12 205.00 1.17 1.12 1.06 0.99
1.40 51.42 68.45 85.13 205.00 1.15 1.12 0.98 0.93
1.50 52.41 68.39 84.20 205.00 1.14 1.11 0.91 0.88
1.60 53.32 68.36 83.32 205.00 1.13 1.10 0.85 0.83
1.70 54.17 68.33 82.50 205.00 1.12 1.10 0.80 0.78
1.80 54.97 68.32 81.72 205.00 1.11 1.09 0.74 0.73
1.90 55.71 68.30 80.99 205.00 1.11 1.09 0.70 0.69
2.00 56.41 68.30 80.29 205.00 1.10 1.08 0.65 0.65
2.10 57.06 68.29 79.64 205.00 1.09 1.08 0.61 0.61
2.20 57.68 68.29 79.03 205.00 1.09 1.08 0.58 0.58
2.30 58.25 68.29 78.45 205.00 1.08 1.07 0.54 0.54
2.40 58.80 68.29 77.91 205.00 1.08 1.07 0.51 0.51
2.50 59.31 68.30 77.40 205.00 1.07 1.06 0.48 0.48
2.60 59.79 68.30 76.91 205.00 1.07 1.06 0.45 0.46
2.70 60.25 68.30 76.45 205.00 1.06 1.06 0.43 0.43
2.80 60.67 68.30 76.02 205.00 1.06 1.06 0.40 0.41
2.90 61.08 68.31 75.62 205.00 1.06 1.05 0.38 0.38
3.00 61.46 68.31 75.23 205.00 1.05 1.05 0.36 0.36
3.10 61.82 68.31 74.87 205.00 1.05 1.05 0.34 0.34
3.20 62.16 68.31 74.52 205.00 1.05 1.04 0.32 0.32
3.30 62.49 68.31 74.20 205.00 1.05 1.04 0.30 0.31
3.40 62.79 68.32 73.89 205.00 1.04 1.04 0.29 0.29
3.50 63.08 68.32 73.60 205.00 1.04 1.04 0.27 0.27
3.60 63.35 68.32 73.33 205.00 1.04 1.04 0.26 0.26
3.70 63.61 68.32 73.07 205.00 1.04 1.03 0.24 0.25
3.80 63.85 68.32 72.82 205.00 1.03 1.03 0.23 0.23
3.90 64.08 68.32 72.59 205.00 1.03 1.03 0.22 0.22
4.00 64.30 68.32 72.37 205.00 1.03 1.03 0.21 0.21
4.10 64.51 68.33 72.16 205.00 1.03 1.03 0.20 0.20
4.20 64.71 68.33 71.97 205.00 1.03 1.03 0.19 0.19
4.30 64.89 68.33 71.78 205.00 1.03 1.02 0.18 0.18
4.40 65.07 68.33 71.60 205.00 1.02 1.02 0.17 0.17
4.50 65.24 68.33 71.44 205.00 1.02 1.02 0.16 0.16
4.60 65.39 68.33 71.28 205.00 1.02 1.02 0.15 0.15
4.70 65.54 68.33 71.13 205.00 1.02 1.02 0.14 0.14
4.80 65.69 68.33 70.98 205.00 1.02 1.02 0.13 0.14
4.90 65.82 68.33 70.85 205.00 1.02 1.02 0.13 0.13
5.00 65.95 68.33 70.72 205.00 1.02 1.02 0.12 0.12
5.10 66.07 68.33 70.60 205.00 1.02 1.02 0.11 0.12
5.20 66.19 68.33 70.48 205.00 1.02 1.02 0.11 0.11
5.30 66.29 68.33 70.37 205.00 1.02 1.01 0.10 0.10
5.40 66.40 68.33 70.27 205.00 1.01 1.01 0.10 0.10
5.50 66.50 68.33 70.17 205.00 1.01 1.01 0.09 0.09
5.60 66.59 68.33 70.08 205.00 1.01 1.01 0.09 0.09
5.70 66.68 68.33 69.99 205.00 1.01 1.01 0.08 0.08
5.80 66.76 68.33 69.91 205.00 1.01 1.01 0.08 0.08
5.90 66.84 68.33 69.83 205.00 1.01 1.01 0.08 0.08
6.00 66.92 68.33 69.75 205.00 1.01 1.01 0.07 0.07

The table of numbers doesn't look bad. And I would agree that at least mathematically, a perfect equilibrium should only be reached at infinite time. But I have not really understood what kind of algorithm you use. Are you using an exchange of pressure to neighboring cars in one iteration, or to all cars simultaneously? Do you take the length of the cars into account? (Each car can have a different length.)

Could you describe what the algorithm does exactly, or post the formulas used? Sending me the spreadsheet might also work, but would require that I try to understand how it works, which I would find better if you explained it.

I have taken a look at your spreadsheet, but there are some things that I don't understand:

First of all, between cars A and B, you calculate the square root of the ratio of their current pressures, Sqrt[B/A], and use that as some sort of a factor.

Then, you multiple that factor by the difference of pressure (B-A) and a flow rate constant. So we end up at Sqrt[B/A] * (B-A) * CONSTANT. This is the value you use to determine by how much car A's pressure is increased in this iteration.

However, I don't see how this can be symmetric between the cars. For example, ignoring the CONSTANT part, if A is 100 and B is 200, then I get 141.42135623731. However, if A is 200 and B is 100, I get -70.7106781186548. Shouldn't the pressure exchange value have the same absolute value here?

Maybe this has its purpose as I need to figure out the rest of the interactions in your algorithm. But if this behavior was not intended, a quick fix might be to normalize the ratio B/A so that the ratio is always >= 1, for example if A>B, then take A/B, otherwise take B/A. I hope you can explain this situation a bit.

Besides that, your algorithm seems to work fine in preserving the total air volume, but car lengths are not taken into account. I would say that any algorithm should produce the same end result whether I had 10 cars @ 10m length, or 20 cars @ 5m length, to make an example. Maybe though it suffices to account for that in the flow rate constant. Additionally, if I use higher numbers for the flow rate constant, the algorithm does not converge, but will quickly produce overflows (test with 0.225 or 0.3 if you want).

OK - I will try and explain and correct an error caused by producing this too quickly late last night. Your question made me look at this with a fresh pair of eyes. The error was I was calculating square root of the pressure ratio between the cars when I should have been using the square root of the pressure difference. This simplifies the calculations.

In my example, I am assuming that each car has identical configuration and therefore has the same volume of air in its system at the same pressure.

At iteration 1 a step change in pressure is made in Car A. In order to calculate the change is pressure in all the cars, we need to know the exchange of air between each one.

First we need to calculate the driving force for the exchange. Using simplified fluid mechanics and not taking expansion of the air into account pressure drop is proportional to the square of the flow rate. So if I have a 20 MPA pressure difference the rate of exchange of air between cars will be 2 times faster than if I have a 5 MPa pressure difference. So based on the pressure differential between the cars, we can calculate the relative ratios of the flow rates between each car.

Now we need to know the actual flow rate. The other parameter that determines the flow rate is the frictional characteristics of the system. There are constant for identical cars. So we assume a number which tells me the flow rate I get through the system. This is my constant. Assuming a constant cross section pipe through the car with no restrictions at all in it, the constant would take 1/2 the value if a car were double the length. However, bends in pipes and connections contribute much more highly to friction than straight lengths of pipe, so in reality a double length vehicles would likely have in the order of 10% difference in friction.

The correction I have made introduces a new problem is that as the algorithm converges and pressure differences between the cars approach 0 you eventually get to a point where the pressure difference goes negative and the algorithm tries to calculate the sqrt of a negative number. I am sure you could enter a check for a small negative pressure difference and halt the algorithm and basically assign the average pressure to all cars at that point.

Clearly if you add pressure above the starting pressure you run into the same problem therefore you would need to check for the direction of the pressure change between each cars and calculate accordingly. I could attempt that if required.

The only other time where there is no convergence is when the constant is unrealistically high. Then the problem could be solved by using a smaller time increment, although this should not be necessary for your purposes. You could restrict allowable ranges for the constant to avoid this problem.

Hope this helps and I will send you the updated spreadsheet.

I think in the real world the issue of propogation of pressure along long trains is a big problem and was solved by putting reservoirs of additional air on each car with special valving to speed up application and release.

Square root of a negative number isn't the biggest problem. Instead of Sqrt[B-A], you can simply use Sign[B-A] * Sqrt[Abs[B-A]]. This takes the square root of the absolute difference but preserves the sign of the difference.

The things about your changes:
Previously, you used Sqrt[B/A] * (B-A) * CONSTANT to determine the flow from B to A. Physically, at least the unit is correct. B/A is unitless as the units cancel out, Sqrt[UNITLESS] is also unitless, B-A is the same unit as either A or B, so if CONSTANT is also unitless, then the calculation would make sense. I am not picky about this, just interested. In your new version, you use simply Sqrt[B-A] * CONSTANT, which would require CONSTANT to be measured in Sqrt[UNIT], e.g. square root of mass, volume, pressure, etc. Not that it makes sense, especially as I have to multiply CONSTANT with the time elapsed somehow and the inverse of the car length, but as long as it works, I don't mind. The one thing about the new version is that it doesn't diverge for large values of the flow constant anymore, but it doesn't really converge either, but oscillates between some final values even if the flow rate constant is small. I think that this is acceptable though if frame rates are high enough.

---

EDIT:
PressureDistribution visualizer is updated. The algorithm has a few issues. First of all, there is oscillation with high values of the flow rate. I have set a default of 30000, which works for me, but 100000 for example does not. Another thing is that the algorithm does not prevent pressures from becoming negative or higher than they could, but I think that I can deal with that. With the oscillation not so much though.