Maximum throughput of a rail line

[Illiander42]

Has anyone gone and found the old signalless clocked setups yet?

The ones where the order you placed the trains boosts throughput if you get it right.

I only remember the one with a # setup where trains drive through the gaps between wagons of other trains.

But theoretically if you remove all signals you should be able to clock trains to leave signals so they drive head to tail without that pescy breaking distance ruining your throughput.

Someone found it for me:

https://www.reddit.com/r/factorio/comme ... gnals_400/

[SoShootMe]

On a straight track with constant signal spacing,
with identical trains as close to each other as can be (train -> braking distance -> signal block length -> train),
and assuming trains move at a constant speed,
this graph on desmos should show how throughput varies with speed.
[...]
Interestingly, throughput is always highest when braking distance = train length + block length, whatever speed that ends up being.

For trains moving at some given speed (v), I think maximum throughput is achieved if block length (s) = train length (t) + braking distance (D(v)), so that the stopping point of a given train reaches the signal protecting a block just as the train ahead leaves that block. This is one train for every two blocks, so throughput y = 60v / 2(t+D(v)). Block lengths that are a divisor of t+D(v) would be give the same throughput as they effectively just add reserved signals within D(v) of the front of each train.

You define l = t+s, and give y = 60v / (D(v)+l) = 60v / (D(v)+t+s). If s = t+D(v), then this gives the same result as above.

If D(v) = t+s (your observation that yields maximum throughput), y = 60v / 2(t+s). But I think this is only consistent with the above if t=0, so I think at least one of us has something wrong... thoughts?

[mrvn]

On a straight track with constant signal spacing,
with identical trains as close to each other as can be (train -> braking distance -> signal block length -> train),
and assuming trains move at a constant speed,
this graph on desmos should show how throughput varies with speed.
[...]
Interestingly, throughput is always highest when braking distance = train length + block length, whatever speed that ends up being.

For trains moving at some given speed (v), I think maximum throughput is achieved if block length (s) = train length (t) + braking distance (D(v)), so that the stopping point of a given train reaches the signal protecting a block just as the train ahead leaves that block. This is one train for every two blocks, so throughput y = 60v / 2(t+D(v)). Block lengths that are a divisor of t+D(v) would be give the same throughput as they effectively just add reserved signals within D(v) of the front of each train.

You define l = t+s, and give y = 60v / (D(v)+l) = 60v / (D(v)+t+s). If s = t+D(v), then this gives the same result as above.

If D(v) = t+s (your observation that yields maximum throughput), y = 60v / 2(t+s). But I think this is only consistent with the above if t=0, so I think at least one of us has something wrong... thoughts?

Actually no. The maximum density of trains (with signals) is when trains are exactly breaking distance apart. And for that there must be a signal right after each train at all times. Best you can do for signals is a signal every 2 meters which then puts a gap between trains of breaking distance + 2.

Going at it from another direction: There must be an unclaimed block after the train for the next train to claim said block. All the blocks breaking distance ahead of the train are already claimed so the minimum gap between trains is breaking distance + block length.

[mmmPI]

Interestingly, throughput is always highest when braking distance = train length + block length, whatever speed that ends up being.

For trains moving at some given speed (v), I think maximum throughput is achieved if block length (s) = train length (t) + braking distance (D(v)), so that the stopping point of a given train reaches the signal protecting a block just as the train ahead leaves that block.

But I think this is only consistent with the above if t=0, so I think at least one of us has something wrong... thoughts?

So i tried a few configurations :

L =1
W=8
s=100
r=1

It yield a max throughput of 12.3715... train per minutes or so , with a speed at max throughput of 67.2187.. m/S which means a braking distance D(v) of 163 m , which is also the result from l=7(L+W)+s which is the train lengh in tile + s the block length.

If instead of 100 i tried with a block lengh with 0 tile between signals :

L =1
W=8
s=0
r=1

It yield a max throughput of 23.89... train per minutes or so , with a speed at max throughput of 50.17 m/S which means a braking distance D(v) of 63 m , which is also the result from l=7(L+W)+s which is the train lengh in tile + 0 as the block length.

This means the higher throughput is achieved with 0 spacing between signals. Block length need to be as small as possible no matter what if one wants higher throughput.

The added reserved signal in front of the train are useful because when trains are moving the reserved space that lower density of cargo moves with them, if signals are more spread out than the minimum it creates delay/ lower density because more space is reserved than the strict minimum because trains reserve the block in which their stopping point would be if they stopped braking at any single moment, but such stopping point can be "at the beginning" of the block, and the train would still reserve the whole block, "losing density of cargo" without necessarily gaining any speed from it which would reduce throughput i think.

I think the graph behave according to my expectations and i think you are not correct SoShootMe with your hypothesis ""maximum throughput is achieved if block length (s) = train length (t) + braking distance (D(v))"". Because if taken literally, it means you can lower throughput by reducing block lengh to "too low" i don't think that is correct.

I also think the way farcast worded the sentence is difficult to make sense of in game.

If you pick a 1-4 trains, the train lengh is 35 tile, this means with no braking research, and 0 block length, this is the braking distance for a train going at 32.07 m/s so their optimal speed is 115km/h. Now if you increase braking research ( r=2 ) the train can go faster and still have the same braking distance, around 44.2 m/s so 159 km/h that is the new optimal speed for throughput.

If you increase block length, you reduce the "max theorical achievable throughput any speed by that 1-4 trains" , but you also increase the speed at which those 1-4 trains needs to go to achieve optimal throughput given the increased block-lengh. that 44.2m/s becomes 86m/s if the signals are placed 100 tiles away. Why ? well because of that larger than braking distance space that will be reserved on average it's wasted for density, so if trains would go faster there would be an increased braking distance, and a lower throughput, but not as bad as if there was just an increased distance due to block reservation, but no speed increase.

Instead, it could almost be rephrased as : throughput is always highest when braking distance = train lengh because if you compare 2 different block lengh to add , the smaller one will yield more throughput in the graph, and i expect also in game. Interestingly this is almost the same equation as s = t+D(V) with s =0 is almost meaning that the train lengh and the braking distance should be equal, there is a sign inconsistencies i can't find explanation.

This is intuitively possible to make sense of, if you consider a short and fast train, it has a long braking distance relative to the amount of material it carry, so the total effective lengh of that train going fast is long, the faster it goes the smaller the effective density. What you want is to add cargo to it because it will increase the braking distance a little, but increase the quantity of material a lot. At least the first wagon ,second wagon, third wagon, there is diminishing return. And if train goes super slow their braking distance is almost 0, but so is their throughput. There is a "sweet spot", a local optimum.

I have not been able to find a situation where optimal throughput is achieved when braking distance is inferior to train lengh.

Edit : played some more with Desmos https://www.desmos.com/calculator/rtfviz2lsn

I added a formula t, that math out the theorical max speed of the train reusing the formulas from the other thread, and u which is the game speed cap both depending on k, the fuel top speed bonus value that can be 1 , 1.05 or 1.15 in game so it's a slider that does from 1 to 1.15 with 0.05 increment.

I don't know how to make it so that desmos picks whichever t or u is the smallest and limit the drawing of the curve to the max speed of the train. But it is enough to find t=16 m/s or 57.6 km/h when using 1 loco and 15 wagons that is when using coal or wood fuel because with solid fuel the speed the train will reach is 72 km/h, and with nuclear fuel, it is 28 m/s or 100.8 km/h.

[quyxkh]

Testing tells me two things: a rocket-fueled 1-12 can reach the top 1.38m/tick speed (pretty sure a 1-14 would get there eventually but I'm not that patient) and adding or subtracting cargo wagons has basically no impact on braking distance, you can see that by getting a 1-12 train up to speed, turning on the braking-point display, then stopping time, removing wagons, putting it back in auto mode and looking at the braking point again. It moves, but going from 1-12 to 1-4 moves it by less than a wagon length.

[farcast]

New graph with more bells and whistles.

Added settings for reversed locomotives, artillery wagons (because why not), fuel bonuses, drag, and switches for m/s to km/h or trains per minute to wagons per 10 seconds.

Max throughput calculation now accounts for top speed due to drag or the speed limit.

Thrust is in Newtons
Drag is Newtons per m/s
450 drag for a forward facing locomotive in front
600 drag for a reversed locomotive or cargo wagon in front (I think)
900 drag for an artillery wagon in front
Cargo wagons and fluid wagons should have the same stats so no extra setting needed

I'm not sure if wagons per 10 seconds should include artillery wagons but right now it doesn't.

There should now be enough settings for every vanilla train configuration! ... okay, technically, it doesn't account for using different fuels in different locomotives in the same train, but what kind of monster would do that?

Thank you mmmPI for doing your best to explain things, I know I'm not very good at that.

[mmmPI]

Testing tells me two things: a rocket-fueled 1-12 can reach the top 1.38m/tick speed (pretty sure a 1-14 would get there eventually but I'm not that patient)

You are correct, and made me realize i made a mistake in (my bad) previous graph, i messed up fuel acceleration bonus and fuel top speed bonus, i used the top speed bonus instead of the acceleration one when calculating the acceleration whereas it should only be used to extend the "game max_speed" which is 1.2 tile per tick. ( 1.2*1.15 = 1.38) there use 1.15 for nuclear fuel. But i also used 1.15 instead of 2.5 for the acceleration bonus given by nuclear fuel. ( i used only 1 "k" switcher ).

When correcting the graph it shows that it would require 32 wagons to be attached to a single nuclear powered locomotive for it to not be able to reach the 1.2 max speed. If you don't refuel the train it shouldn't reach more than the predicted 68m/s or 244.8 km/h or 1.13333 tile per tick.

For rocket powered train instead of 2.5 one has to use 1.8 for acceleration bonus and 1.15 for the top speed cap, so then it's only at 18 wagons that the train cannot reach 1.2 tile/tick and instead is capped by its acceleration at 68m/s or 244.8 km/h or 1.13333 tile per tick.

I tested both in editor x64 speed because it sounded funny that it would be the exact same speed, and indeed after few minutes at x64 speed doing some manual refuel both trains are going at the same 244.7 speed. The max speed limit is then capped by the time a train can accelerate with 3 stack of fuel i think or the patience of the person running the test i suppose

train speed cap.zip

(1.15 MiB) Downloaded 54 times

and adding or subtracting cargo wagons has basically no impact on braking distance, you can see that by getting a 1-12 train up to speed, turning on the braking-point display, then stopping time, removing wagons, putting it back in auto mode and looking at the braking point again. It moves, but going from 1-12 to 1-4 moves it by less than a wagon length.

Yes, but this is more true when you already have a lot of wagon and are not going super fast, (the diminishing returned mentionned ealier to find the sweet spot for train composition) this can be seen if you make visible D(v) in the desmos graph ( the latest from farcast too ! ), then moving the W slider, it shows the braking distance changing (the greenish curves that looks like x²). The braking distance at every single speed, the higher up in the graph the higher is the speed and the more the braking distance is changing if you change the number of wagons.

A funny other one : Whenever you remove a loco, you are always making a train composition that can achieve a higher throughput if the train can still move!
This can be seen because no matter the settings(?), reducing L will always yield a black curve that peak at a higher height ( better theorical max throughput ) .

Thank you mmmPI for doing your best to explain things, I know I'm not very good at that.

You're welcome, i'm not pretending i can find better wording than yours , you have answered the question with those graphs pretty much x), i try my best to share my understandings from it, but i do mistakes even when i try with something i think i understand well, which is not always the case for everything i try to explain , sometimes it's just how my attempts at getting corrected when i make a mistake to make sure i have indeed understood sounds like.

I had tried a little the tutorials to make if then else logic on desmos, because i couldn't write the Mix Max properly , i'll make sure to spend some time studying the "correction"

Using wagon per 10 second is one step closer to material throughput, only 40 slot* stacksize/10 is needed for unit matching the belts expressed in item per second for comparaison of "how many blue belts can i potentially unload in this area supplied by a single rail track ?"

That's a very good tool for planning rail networks or learning Desmos , i've seen players launching rockets faster than the time i played with it already and i have yet to use it to try and build something funny in game like inspired by that crazy signalless build:)

[SoShootMe]

Actually no. The maximum density of trains (with signals) is when trains are exactly breaking distance apart. And for that there must be a signal right after each train at all times. Best you can do for signals is a signal every 2 meters which then puts a gap between trains of breaking distance + 2.

Going at it from another direction: There must be an unclaimed block after the train for the next train to claim said block. All the blocks breaking distance ahead of the train are already claimed so the minimum gap between trains is breaking distance + block length.

Yeah... not sure what I was thinking... .

New graph with more bells and whistles.

Some useful additions .

There is something I noticed before I veered off (went off the rails?) rather badly and ended up posting something completely different, related to what mrvn wrote above: given constant block length, the minimum gap is possible in practice only if train length + braking distance is a multiple of the block length. I think that the result is correct only in that case, and an overestimate otherwise.

For a fixed speed, if you round up train length + braking distance + block length to the next multiple of block length I think you have the minimum "steady state" distance (nose-to-nose) between trains. On that basis, the train (or wagon) rate will be proportional to speed, but with discontinuities (where the constant of proportionality changes) at certain speeds, something like the orange line here (generated for a 2-4 train with signal spacing of 20), which suggests the error can be quite large:

Screenshot 2023-12-09 092425.png (14.88 KiB) Viewed 2718 times

[mmmPI]

For a fixed speed, if you round up train length + braking distance + block length to the next multiple of block length I think you have the minimum "steady state" distance (nose-to-nose) between trains.

I agree with the idea, that the occupied space in game is a multiple of block length, because a block is fully reserved or not. It also make sense to consider that trains cannot be closer to each other than a certain amount that is a multiple of block lengh.

In game when multiple trains are parked in front of each other and tasked to all in a direction, there is a "natural spacing" that occurs between them when signals are everywhere that is at least the braking distance considering nose-to-tail distance.

But if signals are more spread out than the minimum, the "stopping point" of the braking distance may be "at the beginning of the following block" and thus reserving "more space" than stricly necessary/ the full block. The minimum of excess, that will always need to be reserved is then at least [a full block] + [ braking distance].

Considering the end result has to be rounded up to be a multiple of block length, that leaves the question of wether or not to include the train lengh and then talk about nose-to-nose distance or omit it and talk about nose-to-tail distance. This should matter when mathing out the density

On that basis, the train (or wagon) rate will be proportional to speed, but with discontinuities (where the constant of proportionality changes) at certain speeds, something like the orange line here (generated for a 2-4 train with signal spacing of 20), which suggests the error can be quite large:

That part seems mysterious to me, that was also the case earlier, i think measuring in game the results where there are large descrepancy expected would help me understanding, this suggest finding a combo of train composition braking research and fuel so that the max speed achieved in game is a place where there is a large diference between the orange and the blue curve and count the trains in game, then adding signals , and see why the throughput increase, what changes in the train behavior.
Is this supposed to happen/model what happen because trains moderate their speed by braking and re-accelerating ? Because trains won't keep a constant-lower-than-their-maximum-speed in game and would create traffic jams by braking and coming to a full stop before entering the next block rather than entering it with initial speed in case signals are super spread out ; but it's less visible at say 20 tile signal spacing ? Is this an unrelated phenomenon ?

[SoShootMe]

For a fixed speed, if you round up train length + braking distance + block length to the next multiple of block length I think you have the minimum "steady state" distance (nose-to-nose) between trains.

I agree with the idea, that the occupied space in game is a multiple of block length, because a block is fully reserved or not. It also make sense to consider that trains cannot be closer to each other than a certain amount that is a multiple of block lengh.

Funnily enough, I'm starting to think my premise above is wrong . Although I can't shake the feeling that there is something that means, in practice, there is a "sensitivity" to block size and the theoretical maximum (per farcast's model) is unachievable. Perhaps something to do with not having infinte stretches of railway line with no junctions...

On that basis, the train (or wagon) rate will be proportional to speed, but with discontinuities (where the constant of proportionality changes) at certain speeds, something like the orange line here (generated for a 2-4 train with signal spacing of 20), which suggests the error can be quite large:

Is this supposed to happen/model what happen because trains moderate their speed by braking and re-accelerating ?

The opposite: it assumes constant speed. In the game, as you note, speed would vary except at maximum speed. I'm not sure if this would effectively cancel out overall (I doubt it), or how much difference it would make.

[mrvn]

The gap between trains must be >= breaking distance + block. As one train leaves a block the next reserves it. But that doesn't means all trains must hit a block boundary at the same time. So I don't think the optimal distance between trains (nose to nose) must be a multiple of the block length.

Also notice that the graph assumes a constant speed for the train. In game that isn't actually what happens when below the maximum speed. The train will reserve the next block and accelerate into it. When the breaking point hits the end of the block it can't reserve the next block so it breaks till the next block clears. This then gives an average speed approaching the speed in the graph. I don't know what effect this has when the train length + breaking distance isn't a multiple of the block size. I think this allows trains to be a bit closer than the formula.

Lets assume train length + breaking distance is (n + 0.5) block lengths. Then half the trains would be accelerating into their next block and half the trains would be breaking waiting for the next block to clear. The distance between trains varies between train length + breaking distance and train length + breaking distance + block length in some form.

Note: breaking distance isn't a constant because the speed varies.

It could very well be that the average distance between trains then is train length + breaking distance + 0.7 * block length or something.

Secondly trains reserve blocks at tick boundaries and switch between accelerating and breaking every tick. So the actual function for the speed of the train will not be smooth. Getting the derivative to find the maximum throughput might not be well formed.

That also applies to trains leaving stations or signals. You might not get trains packed optimally because you can't control them finer than once per tick. The optimal packing might have a train every 102.4 ticks and 103 ticks between trains would be the best you can achieve. Although you might achieve some fractions of ticks by varying the time trains use to achieve the desired speed before you merge them onto a single rail, by stuttering their acceleration patterns in different ways.

[mmmPI]

Funnily enough, I'm starting to think my premise above is wrong . Although I can't shake the feeling that there is something that means, in practice, there is a "sensitivity" to block size and the theoretical maximum (per farcast's model) is unachievable. Perhaps something to do with not having infinte stretches of railway line with no junctions...

The opposite: it assumes constant speed. In the game, as you note, speed would vary except at maximum speed. I'm not sure if this would effectively cancel out overall (I doubt it), or how much difference it would make.

All great discoveries are met with skepticism at first, maybe you are onto something and it is normal you start doubting yourself, maybe you are part of the skepticism that need to meet farcart's model, or both not sure skepticism is the correct word but it is healthy i think that's how knowledge is established

The model shows a maximum throughput achieved considering speed is constant and distance between trains too. I think too that there is in practice some limits in game where the theorical throughput modeled from farcast isn't correct, but if looking at the 2 curves, it's still correct as saying it's a "maximum".

The model from farcast does show a sensitivity to block length, as increasing s ( signal spacing) diminishes the maximum throughput. However it is not attempting to tell if in game the block length impact is changing the models own assumptions of constant speed for trains. And i think the situation you describe would in game leads to that.

There is nothing that prevent the model to predict situations that are impossible to build or that would lead in game to the emergence of additionnal phenomenon which it is not attempting to model as it's the "theorical max throughput assuming constant speed and spacing between trains"

Having a train goes 40km/h and signals being spaced 5000000 tiles away is probably going to lead in game to such phenomenon. Because then most of the time the train and its braking distance will fit into a single block. But sometimes a train will reserve 2 blocks because it would be just in between 2. That means there is a varying density of train on a segment because the effective train lenght is varying overtime, sometimes 1 sometimes 2 blocks. In game i think such train would experience a change in velocity if its max speed isn't 40km/h which would violate the model assumption, but the model cannot know and still shows a theorical max value.


There is (lot of complicated) academic literature about traffic flow engineering, there are MANY models that try to answer the question of wether or not it cancel out and what difference it makes. To me what is the most related to factorio regarding how the wikipedia page https://en.wikipedia.org/wiki/Traffic_flow#Density map them out would be something related to https://en.wikipedia.org/wiki/Nagel%E2% ... berg_model

In the Nagel–Schreckenberg model, a road is divided into cells. In the original model, these cells are aligned in a single row whose ends are connected so that all cells make up a circle (this is an example of what are called periodic boundary conditions). Each cell is either empty road or contains a single car; i.e., no more than one car can occupy a cell at any time. Each car is assigned a velocity which is an integer between 0 and a maximum velocity (= 5 in Nagel and Schreckenberg's original work).

See because you said : "Perhaps something to do with not having infinte stretches of railway line with no junctions..." , Well density can also be regarded as the number of train on a close loop whose lengh is known and as such their max speed would be capped because it is known what will be the distance between them since one can sum up all train lengh and then remove that amount from the loop lengh and what's left is some space to divide by the number of gaps between train.

Now this distance considering signals are everywhere one can say it's the braking distance of the trains, so that will condition the speed at which they will run on this loop, because if they try to go faster their braking distance would reach the train in front of them and they would slow down. If you know how fast train goes around a loop, and the distance of the loop, it's quite easy math then to know in theory how many trains per minutes you are going to see ( this is related to the approach expressed by MEOWMI earlier, knowing how much time a train need to go around the loop = how much time it occupies block / number of block available = time a train is allowed to staying in a block/ size of the block = speed of that train if you are going toward that train of thought, the approaches converge there).

What about changing block length ? I think that's where the "cell" (aka blocks) from Nagel-Schreckenberg model are useful to illustrate the emergence of phenomenon that i think are exactly what you describe, related to block length and trains transitionning from one to another implying a change of velocity overtime and how it would be distributed around many trains in such loops, so as to see the traffic jam propagate.

I know this phenomenon is fun to watch in game because i played with the editor on that, but it was before version 18 and i can't load my maps with many identical loops more and more filled with trains up to the point where it create traffic jams and one can see how it propagate backward compared to the flow of traffic.

My interest for those things is part of what made me think factorio is such a great game, because those things happens in it, and all parameters are known and mathable, unlike drivers reaction time in real life which leads to other models that i could spend lots of time reading about like :https://en.wikipedia.org/wiki/Newell%27 ... wing_model

Edit : The whole page is interesting but the "MFD" seem exactly what we are looking at when looking at farcast's model. I think the 3"fundamentals diagram" are not easy to make sense of in game, but the opposite is easier, once you have observed the congestions forming in game, then looking at the graphs i think explains a lot
Also the difference between free flow = train at max speed= free velocity, and bound flow, which is means critical velocity = speed for max throughput.
https://en.wikipedia.org/wiki/Fundament ... al_diagram

[SoShootMe]

But that doesn't means all trains must hit a block boundary at the same time. So I don't think the optimal distance between trains (nose to nose) must be a multiple of the block length.

This is exactly why I doubt my (second) model. In fact I'm convinced it is wrong, but I am not at all convinced there isn't something else that creates a similar effect that is related to block size.

Also notice that the graph assumes a constant speed for the train. In game that isn't actually what happens when below the maximum speed. The train will reserve the next block and accelerate into it. When the breaking point hits the end of the block it can't reserve the next block so it breaks till the next block clears. This then gives an average speed approaching the speed in the graph. I don't know what effect this has when the train length + breaking distance isn't a multiple of the block size. I think this allows trains to be a bit closer than the formula.

I'm with you up to the last sentence, can you elaborate?

[mmmPI]

But that doesn't means all trains must hit a block boundary at the same time. So I don't think the optimal distance between trains (nose to nose) must be a multiple of the block length.

This is exactly why I doubt my (second) model. In fact I'm convinced it is wrong, but I am not at all convinced there isn't something else that creates a similar effect that is related to block size.

For farcast's model to be accurate, trains must hit a block boundary at the same time, it is what will occur when trains are at constant speed and constant distance. ( and signal are spaced equally ).

Whenever trains do not hit block boundary at the same time, it means there is no constant spacing between trains, or that signals spacing is not the same everywhere or that train speed isn't constant therefore the model cannot be used to predict the exact throughput.

If we do not account for uneven signal spacing ( which happens in game due to curve rails that can't be signaled as tight as straight rails). The uneven spacing between trains come from a variation of speed.

Then we enter the traffic jam math territory with all the complicated models that describe the phenomenon.

[mmmPI]

Hey i have made some other graphs to make some predictions that i then tried to verify in game and attaching everything !

https://www.desmos.com/calculator/x9pc6ycsqv

This is done to illustrate some points that were discussed, including the effect of the block length on the apparition of traffic jam and their disruptive nature on the throughput, and another way of calculating train throughput and max throughput. Hopefully it is more accessible than the wikipedia pages about traffic flows

The basic idea was to create a loop instead of considering the infinite straight line. This introduce a finite distance, which means a hard limit on the number of trains that can fit on such loop, or their size. From this it is possible to math how much space is occupied by trains and how much space is left unocupied, free for train to reserve as their braking distance. The limitation of the distance available for each train as braking distance is creating a cap on the speed a train is allowed to go if we consider equal spacing between trains because going faster would mean reserving the block occupied by the train in front of it.

Hopefully it illustrate what is the maximum throughput described in the other graph.

How to read

how to use graph.png (81.74 KiB) Viewed 2486 times

The Blue curve represent how the number of train impact the throughput. When there is 0 train, the throuput is 0 ( obvious). When there is too many trains, the throughput is 0. ( tail-to-nose distance = 0 = deadlock). Everywhere in the middle there is some throughput. The black dot on the blue curve represent the "max throughput" on the horizontal axis, the blue curve goes no more to the right than 37.88 train per minutes. ( this is the same value as farcast model using the same formulas, this is where one can measure discrepancies ! ) This throughput is achieved with 12.406 trains considering the size of the loop on which they are placed, and the size of the train and abstracting signals for now. This is not possible obviously so it is going to be 12 trains.

But if one wanted to achieve the mathematical perfection, those 12.406 trains would have to run at 159.166 km/h.

The red curve shows what happens in game to the speed of those trains if you use more or less than 12. More than 12, it's looking at the upper part of that curve, where it goes near the origin, meaning 0, meaning if you add more and more trains after 12 , their speed will be lower and lower than 159.66 km/h, because they will not have enough room on the loop for a braking distance implied by a larger speed, up to the point where it's 0 and not drawn , because that would mean more trains and loco that what can fit on the loop and one is not allowed to do superposition yet.

If one uses less than 12 trains, well then trains are not capped at 159.166km/h, one has to go "down" the red curve, and it is going "right", instead they go faster because there is more free room to reserve for braking distance, however they are still capped by the game max speed or by their acceleration if there are too many wagons and poor fuel hence the vertical end on the right part ( if present train speed is capped by game, if not train speed is capped by train acceleration/wagon ratio).

In the desmos graph , one can change the number of locomotives or wagons, or the fuel acceleration/top speed. But also the loop "height" and "width" , the total perimeter of the loop is calculated using values from this thread : viewtopic.php?t=109189 , supposedly players don't only make loops but it's no time to complicate things.

Accuracy

With signals everywhere :

accuracy 2.png (662.88 KiB) Viewed 2486 times

So clearly something is wrong, there is no trains going 325.50 km/h , but using 12 trains on such loops with signals as close as allowed by the game makes the train counter i borrowed from disentius (thanks !) struggle a little bit . With 12 trains, and not 12.406 , they should be going at 164.38km/h that is a hardcoded number by me, as read from the graph on the red curve at 12 trains on the vertical axis, that is the speed indicated on the horizontal axis. This should yield a throughput of 37 trains per minutes and not 74. as if trains were going 325.50 km/h.

But i made a manual 1 minute counter so i count trains like you know 1 2 3 4 ... since there are only 12 trains, in a minute it must have done 3 turn or so, because i counted 37 trains, that's the other hardcoded number, that' why it's called manual count, i only did this when the counter didn't work because i had already produced much intellectual effort compared to my everyday that i felt a little exhausted. Though it is possible to use the editor and go "custom 3600 tick " at speed x4 to count faster and not risk missing the lamps due to the intense focus on trains passing.

Also looking at the speed of the trains in game shows they are "around" the predicted values. I blame the inaccuracies and variation on the impossibility to signal the angle of the loop as close as the straight rails, it is also why i decided to pick such large loops, compared to the tinier one i made initially that were showing higher inaccuracies / speed variation.

1 of them with only 8 trains, which was expected to yield a throughput of 35 and also made the counter struggle but was counted manually at 35.

accuracy 1.png (488.75 KiB) Viewed 2486 times

Exploration and breaking the model

There are 6 of those loops in the linked map :

Then i started to space out the signals but still using 12 trains on the same size loops. ( it made the train counter more accurate ).
This way the difference in throughput or speed average of the train or just general behavior could be explained only by the size of block length. And i wanted to know how far away need the signal to be for the throughput to be effectively lowered, and when a traffic jam would start to appear.

This is the further i placed signals without having traffic jam forming :

loop6.png (315.25 KiB) Viewed 2486 times

It says 1.5 wagons but really it's 9 tiles and i haven't tried 10.
There is only 33 trains per minutes instead of 37, and they are going 147 km/h instead of the 164 km/h from the graph so throughput is impacted but the type of flow for the traffic isn't yet, the trains still hits block at the same time and keep equal spacing.

This is the smaller increment immediatly above that i tried and failed, meaning there are traffic jams visible on the map propagating backward compared to the traffic flow. signals are too far away from each other

loop5.png (192.95 KiB) Viewed 2486 times

i had to use the manual counter because there is high variation on the nixies tube when the traffic jam is sitting on the counter, the accurate number of train in a minute is only 25 trains.

The map contain a mod to switch many trains in automatic mode so it's easy to copy a loop with already 12 trains but the refueling has to be manual so it can be better to reload the map when fuel is exhausted

Train loop test 1.zip

(1.73 MiB) Downloaded 55 times

In case it's unclear what is a traffic jam, there is a loop 4 with a bunch of them, this means there are several different area with trains completly still at any time not directly adjacent to each other, It is from the attempt to place signals 1 train distance away, but then there was not enough block, so i doubled and tripled the signal, and it's not just 1 big traffic jam but 2 or sometimes 3 trains that have 0 velocity at the same time, but trains in between them are moving.

Whereas on the loop 5 it is only 1 area where train completly still several trains adajcent to each other to the point where it's possible to see the traffic jam propagating backward compared to the traffic flow, when looking at the first velocity 0 train of the group of train stuck in the jam, it's a nice traffic jam to study .

Additionnal note : There is no need to place the trains properly at first, they will naturally spread well to be have equal spacing and nice flow when they can, or will always create traffic jam when they can't, assuming the signal spacing due to curve rails is almost always going to be negligble. ( it's around 1 wagon worth of distance, who is going to realistically place signals closer than that and turn often enough that it matters ?). Other loops are easy to make to test.

[mmmPI]

I realized my mistake in using the counter in the save attached previously, the signal wired to the counter has not the proper conditions in the cases where it didn't work.

Here is an updated version where things works as expected as far as i know.

Train loop test 2.zip

(1.72 MiB) Downloaded 52 times

I thought to edit all the previous post, but that's not fair

So here is the updated loops pictures with the working counter :

Loop1.png (538.42 KiB) Viewed 2461 times

The 8 trains one flickers between 34 and 35 with the speed oscillating slightly, because of uneven signal spacing on curved rail or self-correcting behavior by trains ? maybe something else or both, it is consistent with the graphs and the prediction though, trains are not quite able to reach max speed and oscillate around the predicted value like the cases when i had properly used the counter.

The loop with 12 trains is even closer to the prediction :

loop2.png (438.72 KiB) Viewed 2461 times

I think the next step is to plot the speed of 1 train relative to time over the course of several lap of time, to make it visible how an individual train reacts for which this mod could be useful viewtopic.php?p=595393#p595393

[mrvn]

But that doesn't means all trains must hit a block boundary at the same time. So I don't think the optimal distance between trains (nose to nose) must be a multiple of the block length.

This is exactly why I doubt my (second) model. In fact I'm convinced it is wrong, but I am not at all convinced there isn't something else that creates a similar effect that is related to block size.

Also notice that the graph assumes a constant speed for the train. In game that isn't actually what happens when below the maximum speed. The train will reserve the next block and accelerate into it. When the breaking point hits the end of the block it can't reserve the next block so it breaks till the next block clears. This then gives an average speed approaching the speed in the graph. I don't know what effect this has when the train length + breaking distance isn't a multiple of the block size. I think this allows trains to be a bit closer than the formula.

I'm with you up to the last sentence, can you elaborate?

Lets look at 3 trains A, B, C in an infinite series of trains. B is driving faster than average and caught up to A. It is now breaking and at breaking distance from the block A occupies. If B had driven at the perfect speed it would reserve the next block at the time A leaves that block. But B is driving too fast, so A is somewhere in the middle of the block with it's tail. So the distance between A and B is breaking distance1 + a fraction of a block. That's less than the distance with perfect speed.

Now C would be at the other end of the cycle. C has slowed down waiting for B to clear the next block and B just cleared a block at it's tail. So C is at a distance of breaking distance2 + block from B and is now accelerating. Say this pattern repeats over an over. So the interval between trains would be (train length + breaking distance1 + a fraction of a block + train length + breaking distance2 + block) / 2. Breaking distance1 will be a bit more than at perfect speed because B is driving fast. But breaking distance2 is less than for perfect speed because C is driving slow. Lets assume that more or less cancels then the interval is train length + breaking distance + (1 + fraction) / 2 * block. With what I imagine with alternating fast and slow trains the fraction would be around 0.5 so the average interval between trains would be train length + breaking distance + 0.75 blocks.

This is all just napkin math and how I think it would turn out. The result from this would be that the distance between signals doesn't have quite as large an effect on the throughput as thought.

[coppercoil]

I didn't read entire thread carefully, please note me if this was already discussed.
AFAIK this is max theoretical throughput, not a real game case that contains a) junctions of various quality and b) left turns. Is there an interest for real game results?

[mmmPI]

I didn't read entire thread carefully, please note me if this was already discussed.
AFAIK this is max theoretical throughput, not a real game case that contains a) junctions of various quality and b) left turns. Is there an interest for real game results?

This can be used to know if you will need "at least 1 or 2 or 3..." lane of rails to carry enough material via train if you know the maximum theorical amount of train that can fit 1 lane.

From that theorical throughput idealized it can only be the same or lower in game and the factors that makes it lower can potentially be approximated, or at least measured in some cases, so that to gain general knowledge on trains and improve networks

But it will be possible to approach it more easily than on the previously linked saved that are just editor setups with the bridges in the expansion as there would be more possibilities to make junctions that do not have left turn but instead bridges and 3 turn right, which are non blocking, "merge" junction.

This is all just napkin math and how I think it would turn out. The result from this would be that the distance between signals doesn't have quite as large an effect on the throughput as thought.

The model from farcast is not napkin math though ; it include block length (unlike mine which idealized them as always 0 ) and does show how it impact the maximum theorical throughput, the theoric maximum is shown as decreasing if you increase the block length, this one is accurate as a maximum regarding the tests made in game though, it shows that roughly you cap you throughput if you have longer block length and by which amount, it goes from a maximum of 37.88 trains per minutes, to a maximum of 26.7 trains per minute when you increase the block length from 0 to 35 tiles which is the length of 1 of those 1-4 trains. Considering i have made setup where 37 trains per minute is achieved in game like the previous saves linked, it shows a loss of around 30% of throughput is possible without accounting for the traffic jams.

The A B C distance changing can lead to a critical phase where velocity of 1 reach 0, and since train are faster to go from 0 to 50 km/h than from 50km/h to 100 km/h, it leads to faster deceleration ( you lose 50km/h of speed read in game in less tick) than acceleration ( if not from 50 to 100, it can be from 230 to 280 km/h) . And thus a delay, a moment when if looking at a lane the max throughput is not achieved for some seconds or minutes, and since it's a max throughput, there is no catch-up.

length0.png (73.55 KiB) Viewed 2435 times

length35.png (72.57 KiB) Viewed 2435 times

My model consider signals are spaced out 1 tile apart, and tell you how many train you need on a certain given length of loop to achieve that throughput the same indicated by facast's model, the theoric max throughput with space 0. The more space apart the signals are in game, the worse my model will diverge from farcast's because i'm not mathing out the block length at all.

Yet both model are "wrong" considering traffic jams, and the ABC distance changing as you mentionned, since both model assume constant speed for trains and constant flow, which is the conditions for a maximum but not for predictions, unless specific cases like my loops setups

[quyxkh]

Measuring actual performance is a little hard because you can't get braking distance directly and there's signal block lengths, but as a way of validating models I thought I'd measure throughput as directly as possible.

So I put a train on a long oval loop with waypoints at the end of each straightaway and watched for the train's path_end_rail to change. Each tick I recorded the distance from the train's back rail to the path_end_rail (hence the long straights), its speed and other fun metadata.

inadequate method without signal spacing

Code: Select all

/c 
function dist(a,b)
    local x,y =(a.position or a).x, (a.position or a).y
    x = x - (b.position or b).x
    y = y - (b.position or b).y
    return math.sqrt(x*x+y*y)
    end

function gpsl(p) return game.print(serpent.line(p)) end

de=defines.events
trains={}

script.on_event(de.on_tick,function()
    local tname,k,v,cdist
    for k,v in pairs(game.surfaces[1].get_trains()) do if v.has_path then
        tname=v.front_stock.backer_name
        cdist=dist(v.front_rail,v.path_end_rail)
        if not trains[tname] then trains[tname]={path_end_rail=v.path_end_rail} end
        do local _=trains[tname]
            if dist(v.path_end_rail,_.path_end_rail) > 0 then
                gpsl(string.format("nwagons=%d, speed=%g, throughput=%g", _.nwagons,_.speed,_.wagonspermin))
                end
            _.cdist=cdist
            _.speed=v.speed
            _.nlocos=#v.locomotives.front_movers+#v.locomotives.back_movers
            _.nwagons=#v.cargo_wagons
            _.rdist=dist(v.path_end_rail,v.back_rail)+2
            _.rtime=_.rdist/v.speed
            _.wagonspermin=_.nwagons/_.rtime*60*60
            _.path_end_rail=v.path_end_rail
            end
        end end
    end)

Signal block lengths will increase the reserved path lengths so what this is measuring is guaranteed-never-to-exceed throughput, but you can get as close as you want with comically-close signal spacing and you could round the rdist value up to the next multiple of "the" signal block length to get a theoretical maximum-achievable figure for any particular spacing.

So it's a starter kit but it's it's giving measured performance.

Trying it with one rocket-fueled locomotive I get, assuming I didn't botch either the math or the code above, max throughput at 1-20, that gets about 325 wagons/min vs about 263 for 1-12 and 125 for 1-4.