Redesign the entire railway system. Again!

[SLB]

I designed a railway junction with a traffic of 1.6 trains per second.
Here is the traffic test video: https://www.youtube.com/watch?v=M365F87k18A

However, the actual use found that the train pathfinder will take up a lot of CPU time.
The bottleneck of the railway actually fell on the UPS
I don't understand why dozens of trains can take up so many UPSs.

AAVV33.png (913.01 KiB) Viewed 10295 times

[BattleFluffy]

I ran into a similar issue with my very large rail network.


If the train pathfinder is taking ages, then there are 2 factors that are likely to cause this:
1. The trains are having to recalculate their paths frequently
2. The average length of the path they have to recalculate is very long

I will deal with these seperately...

1. In my city for example, I had trains coming from a very long way to the east. They would travel to the city, and their destination was (for example) an Iron Ore unloading station.
Except, those Iron Ore unloading stations would close whenever a train pulls into them. Causing ALL trains on the corridor that were heading toward that closest station to have to recalculate a new path, all the way from the far east to the next station along.

Since a train is pulling into an Iron Ore unloading station every few seconds, the amount of path recalculating gets crazy...

So.. The solution I came up with was to add a Waypoint station on the outskirts of the city called "Return" that the trains will path to first. It is always enabled.
Train schedules are set up so that trains from the far east head to this Waypoint station first, and have no wait condition when they arrive there. This means they get to the waypoint station and then decide on an exact Iron Ore unloading station to go to - when they're already really close, and the pathfinding cost is much lower.

I repeat this trick for outbound trains leaving the city - with a waypoint station just before the first eastern mine.

corridor and return.png (199.96 KiB) Viewed 10275 times

2.When I say the "length" of a path, what I mean in this case is the number of segments that the pathfinder has to check before finding a matching station.
A segment "is an uninterrupted plain sequence of rails, with no intersections, stops, or signals".

Therefore, if you have a great big long straight rail with 2 rail signals on it, that is a total of 3 segments - the rail signals define segment borders.
If you take the same rail and add a rail merging onto it somewhere along the length, then it becomes 4 segments - any connecting or intersecting rails also define segment borders.

So, if you have thousands of rail signals packed very tightly, that means the pathfinder algorithm has to iterate through thousands of segments every time it needs to calculate a path.
Consequently, reducing the number of intersections, merges, exits, and signals on your main rail highways is one way to reduce the cost of calculating paths.

There are other bonus ways though. If you're not familiar with the way A* algorithm works, I recommend reviewing some Youtube videos about it so you can see the general sort of way that it tends to explore toward the goal.

Combined with the ability to artificially increase path cost (as mentioned in the link below) by placing dummy stations (2000 cost increase) or rail signals made red via circuits (1000 cost increase), you can create a system where the most common paths are cheap for the pathfinder, and rarely used side tracks are expensive and therefore it wastes less time exploring them.

I have this page bookmarked, and re-read it often. That page is the source of inspiration for a ton of rail optimizations. :>


Hope this helps you get to the bottom of your train issues! Awesome looking train network by the way. :>

[FrodoOf9Fingers]

Branches make it harder for the pathfinder too, since it had to check every branch.

Reducing branching (each of your junctions adds at least 3 branches the train could take), or adding waypoint stations can help.

[SLB]

1. The trains are having to recalculate their paths frequently
2. The average length of the path they have to recalculate is very long

Thank you very much for your reply
The first question you mentioned does not exist in my station system.
The switch of the station is based on the stock of goods in its site boxs.
The station will only be closed when the boxs is almost full.
Then open the station again when the boxs is empty
So there is no problem of frequent switching at the station.

The second point you mentioned may be the problem.
I only considered high traffic when I designed the intersection.
Completely neglecting the connection of multiple such intersections will cause a great burden to the path finder

I know which direction I should solve this problem.

[ssilk]

Increasing CPU for trains:
- Double sided trains and train system in both directions (better: two-way system with single headed trains)
- Many junctions
- Many pathes into the same direction (parallel tracks which have all the same number of junktions etc. and eventually interconnected)
- Unused (seldom used) paths
- Possible shortages through trainstops (better: train stops need always the longer path)
- heavy traffic, many trains waiting at signals (better: make new paths without junctions for some kind of priority lane around and let the trains wait at stations or controlled signals)
- Opening/Closing stations (everything which leads to path calculation: https://wiki.factorio.com/Railway/Train_path_finding )
- Long trains (are slower than several small)

That last one could be discussed. I have no real proof for that, but I can say I had some experience with it two years ago and it would be no wonder, if that had changed. It explained to me at that time, that longer trains occupy the tracks much longer and take much longer for the travel compared to small trains, which is because the probability, that a long train gets stoped by another long train is much higher, than with small trains and much more thoughts into that direction. But I have no prove. So don't care about it.

But what I can surely say is that the initial post is a good example of the above points.

[eduran]

Increasing CPU for trains:
...
- Long trains (are slower than several small)

While a single long train might cause more CPU load due to the issues you mention, you have to remember that you can't just replace one long train with a short one. Shorter trains = more trains, which is going to outweigh any potential gain. So I'd say that reducing the number of trains by making them longer should reduce time spent on pathing calculations and also reduce the strain on your network.

[Faldyar]

I've seen what other people do for their trains, and what seems to work for me is for a large stop such as a smelter, or main bus unloader

Has one entrance with a chain signal.
The track then splits into a stacker that is however wide as your needs. The start of the stacker has a regular signal on each lane, and the end of the stacker has a chain signal per lane.
the stacker then converges into a single track and breaks apart into one lane per unloading/loading station. The each station has a standard signal at the start and end of its lane, plus the train stop near the end of its lane.
there is one extra train track line added to the station that has one train stop for each type that the station block can handle, and there is a engine parked there in manual mode for all time.
Each of the stations are wired to enable for a train if the contents of the chests get too low (unload) too high (load).
Each train station can call for a different ingredient if necessary, typically when i am converting from main bus all belt, to a trains feeding main bus, i have 1 train stop per 4 lanes of a product (round up), with all of these trains stops in one station block/stacker, or in the case of a smelter, all of the train stops have a single name like iron ore smelter in.

My ore trains will simply swing by the outpost stay till full and head to their stacker, there is no reason to ever stay at the outpost or repath until they reach the stacker, because the train stop with the permanently parked train engine is ALWAYS enabled. They hit the stacker chain signal and repath to whatever line in the stacker is open, and either stop because all of the stations they feed are closed (other than the blocked one), or continue thorugh the stacker because one of them is open.

No train will ever go down the path with the parked engine cause the signal to it is always red, and the chain signal in the stacker keeps it in the stacker.

Thus if the stations are red, all of the trains in the stacker want to go to the perm parked line, but cant cause the signal is red, however the moment a station turns on, one train will win and begin heading down the line to the new station, and will block all other trains from moving until it clears its station, or another station opens up.

My goal is never maximum throughput through one station like most people seem to have, but throughput through a block of stations that have a job. I really like the 4 belts beaconed smelter row design that takes 4 blue belts of ore and produces 4 belts of plate (viewtopic.php?f=202&t=62264), you can stack as many as needed and the stations can be slow as necessary, the only place that slows you down is the two pieces of track entering the stacker and entering/leaving the stations. Once a train is in a station and unloading, it can sit there as long as needed, so you can unload a 1-4 or 2-8 or whatever onto 4 blue belts and send it to smelting. This way you can have long trains entering smelting and smaller trains picking up plate to deliver to various sources without issue, in general the other nicety you get with this, is that the smelters storage boxes tend to be the same amount full at all times, and you dont have a case of one train car is empty and other has 1000 ore in it, so the train cant move. IMO a good smelter should always draw evenly from the train cars and load evenly on the other end. If during the contruction phase you discover that it has become uneven, you can always send the train manaully away mid operation for a full even reload, so the next arrival has even boxes to work with.

For an optimized smelter the goal is to get a certain amount of raw ore in on trains, and out on other trains per second. It shouldnt matter whether thats done with 1 train stop or 4 train stops and belts or bots This will break down if you cant physically get enough trains through the narrow part of the design per second, or if you cant get a new train in the station after the previous one left before the chest storage in the station becomes empty. If you are moving that much product that either of these happen you will need another station block with a new set of station names, or lengthening the trains (both input and output).

how you process (bot or belt to assemblers) what the trains unload doesnt really matter as long as you can unload each car evenly into your assemblers at full speed for how you want to setup train throughput.

[ssilk]

Increasing CPU for trains:
...
- Long trains (are slower than several small)

While a single long train might cause more CPU load due to the issues you mention, you have to remember that you can't just replace one long train with a short one. Shorter trains = more trains, which is going to outweigh any potential gain. So I'd say that reducing the number of trains by making them longer should reduce time spent on pathing calculations and also reduce the strain on your network.

I tried to explain it: A short train is in general much faster (faster accelleration) compared to a long, and occupies at the same time much smaller parts of the network. So the trains don't need to recalculate so much their paths. And it doesn't need so much inserters, belts etc. to fill/empty, and so on - which also take some amount of CPU.

Far away from a prove. (The truth needs to be tested)

But the simple "the longer I make trains, the lesser the needed CPU" is in my opinion just wrong.

[mrvn]

Increasing CPU for trains:
...
- Long trains (are slower than several small)

While a single long train might cause more CPU load due to the issues you mention, you have to remember that you can't just replace one long train with a short one. Shorter trains = more trains, which is going to outweigh any potential gain. So I'd say that reducing the number of trains by making them longer should reduce time spent on pathing calculations and also reduce the strain on your network.

I tried to explain it: A short train is in general much faster (faster accelleration) compared to a long, and occupies at the same time much smaller parts of the network. So the trains don't need to recalculate so much their paths. And it doesn't need so much inserters, belts etc. to fill/empty, and so on - which also take some amount of CPU.

Far away from a prove. (The truth needs to be tested)

But the simple "the longer I make trains, the lesser the needed CPU" is in my opinion just wrong.

That depends on how you measure.

By long train you seem to mean that it blocks more segements. That assumes that the signals are spaced the same distance for short and long trains and smaller than a long train. If you place all signals one train length apart then a long and short train will both block just 2 segments.

On the other side you say short trains are faster. So their breaking point will be farther ahead. Doesn't that mean they block reserve more segments and therefore block a far longer stretch than a (slow) long train? Isn't the relevant length the length of the train + breaking point? Minimize that and you get the least disruption. Or not?

Next up long train doesn't mean it's slower. You can have trains like LCC, LLCCCC, LLLLCCCCCCCC, LLLLLLLLCCCCCCCCCCCCCCCC. Afaik they would all have the same acceleration and speed. But the longer trains will use up less space (only one breaking point) than twice the number of the next smaller trains. They will also change signals less often and cause half the number of other trains to repath.

Even a LCCCCCCCCCCCCCCCC won't be so bad. Sure it will be dead slow. But that means it will not change signals as often. Overall going from A to B no matter the train length the same number of signals will change. And all other trains being the same every signal change has more or less the same probability of causing repaths in other trains. So does the train size even have any effect? Isn't it rather the train speed? The faster the train the more often it causes a repath.

Overall I think you are wrong about smaller trains beeing better not to mention that small trains quickly reach a throughput limit.



As for the original post: A grid is bad for path finding. Too many equivalent paths causing a massive explosion in potential paths to look at. If you like a grid then try building a fractal design. Combing 4 cells into a medium cells. 4 medium cells into a large cells. 4 large cells into a mega cell and so on. By having tracks going from one mega cell to another without break they can have less signals and therefore be cheaper. They also have less junctions. The path finding will then prefer those for long distances and the number of paths to look at becomes far less.

Another advantage is that short distance trains, which will be slow because they haven't had time to accelerate yet, will be mostly on the short distance tracks. They won't cut ahead and stop the long distance trains as often.

[ssilk]

It's clear that a LCC, LLCCCC, LLLLCCCCCCCC or LLLLLLLLCCCCCCCCCCCCCCCCC are similarly fast. But what I mean is the integral of occupied blocks over time.

To make my following thought a bit simpler I don't distinct between blocks and length. An "L"-train occupies one block with the length of one locomotove per second. One block * second, a blocksecond. So after one minute this train has occupied 60 blockseconds. When it drives it occupies much more, of course. So with that you can calculate:

Occupied blockseconds = LengthOfTrain * time

When it drives, the train occupies blocks in front of it. And the number of blocks are only dependent of the speed and how fast a train can break, cause it will occupy only so much trains, that it can break withing the occupied blocks. Knowing that, the formula looks so:

Occupied blockseconds when driving = ( LengthOfTrain + Speed * Brakeforce ) * timeOfTravel

This formula says: the faster the train, the more blocks it will occupy.
And it says: The faster the train, the earlier it reaches it target and the less time it needs for a travel.
Or: The faster the train goes, the more the occupied blocks depends on it's speed and the less on it's length.
So far so clear and of course when you look at it like so you could think: Well, then it makes much sense to make the trains longer and longer, because the occupation depends much more on speed than on length.

But CPU-wise, only the speed is here a problem: The faster the train, the more signals needs to be switched on and off. The number of signals turned on at the same time is no (not so much) problem.


Till here we have looked only to one train. But the number of occupied blocks becomes a problem, when you have a network with many trains. Because with many trains
a) the chance, that a train needs to stop because of an occupied block rises exponentially.
b) the average speed of trains sinks (because when trains cross paths they need to stop)
c) a stopped train occupies blocks in an area, which other trains need to cross, and the larger the stopped train is, the more blocks it will occupy.
d) the formula "Occupied blockseconds when driving = ( LengthOfTrain + Speed * Brakeforce ) * timeOfTravel" is going back more into dependency of LengthOfTrain, because when the average speed of trains sinks (see a - c) then the number of occupied blocks becomes more dependend to the LengthOfTrain only.
e) stopped trains need much longer time for travel, think also to the time needed for acceleration. The timeOfTravel rises for each stop, which increases again the needed blockseconds, which increases the chance for other trains to stop. This is a vicious circle, which has an optimum when the train reduces the average speed to some point where the occupied blockseconds has their minimum. Think of jam on a freeway: Cars reduce their speed so that they can reduce the distance to the car in front.


So what I want to say with this is, that I'm not a Mathematican, but what I see here is, that there must be an optimum between
- Average length of trains
- Average speed in a train network
- (Used) Length of a train network

because the average speed affects the number of occupied blocks in the network, which affects the chance of trains to stop because of red signal.

And that affects the used CPU, cause - see above - what's really expensive is not that a train occupies blocks - but , when a train needs to stop (because of blocked signals) and needs to recalculate it's path. You can of course argue, that if there are longer trains, you need less trains. Less trains, less recalculation. Bu we will never know the truth cause both setups are so different in it's game mechanic, that it cannot be compared. [Someone needs to build a pseudo-test-setup to find out, what's the truth. Not worth it. ]


So, after all of this TL;DR: Now, after writing this I want to say that the longer the trains the less CPU cannot be true. There must be an optimum train length, which in general depends on the size of your rail-network. And in general I would also say, that this CPU-maximum might be very near to the transport-volume maximum, because it means, that there is a optimum between occupied and free blocks. I don't say anymore, that the smaller the trains, the faster, because the formulas also shows nicely, that the minimum used CPU might be much more dependent on the size of the train network and other factors, tham just the train-length.

[mmmPI]

It's clear that a LCC, LLCCCC, LLLLCCCCCCCC or LLLLLLLLCCCCCCCCCCCCCCCCC are similarly fast.

I read something that is a little different recently in this one viewtopic.php?f=5&t=72132, if you account for air resistance ( which i didn't know was in the game) then you have a speed advantage for train that have additionnal locos after the first 1.

You can of course argue, that if there are longer trains, you need less trains. Less trains, less recalculation. Bu we will never know the truth cause both setups are so different in it's game mechanic, that it cannot be compared. [Someone needs to build a pseudo-test-setup to find out, what's the truth. Not worth it. ]

With my potato laptop, every setup is a test setup for CPU usage.

I had always assumed that longer train are better for CPU because of this reasonning but prefer smaller train for aesthetic and lazyness when you have to move or build stations you have more work to do. I started reconsidering

Most of the time i use the 'Waypoint station' that i call 'entrance xxx' without any condition when a train arrive after a long travel so that he recalculate his path to 1 of the many station only at the end.

Network build as a tree ( or mutliple ) instead of grid , so in case a train stops, he still has 1 way to his waypoint, i had never known the train would still recalculate if it starts to jam. ( Is it ? )

Double headed train 111 or 121 up to 141 train but 1 way rail system of 2 4 6 lanes like roads and cars or truck that would only drive backward to park for the load and unload are my favourite but LC train or LCC are ok too for my personnal taste. And i thought to increase it a bit for better performances.

My rule of thumb is to never have any train idle or stop on the main trunk of any trees, so i place the station far enough in the branch that the train slows down not in the main network to reduce the time each train need to clear junction.

Decided to use a mod to drastically increase train speed, didn't accounted for the increased number of signal changing in advance, so i am interested in the topic before i fry my venerable ancient machine.

small trains quickly reach a throughput limit.

I like using many small trains for aesthetic purposes, and i have to agree , when you see 10 small trains taking the same turn in a row, you think that 1 big train has less gaps between wagon, and carry overall more materials through the junction per time.

But smaller train let other trains go through the same junction more often, allowing conflicting train to slow rather than stop, if you were to have those 10 small trains in conflict with a 10 wagon trains for priority on the same junction, the 10 wagon trains would probably never stop but only slow, since the small train clear the junction very fast. but the 10 small train will jam when they wait for the long one to clear.

While if you have 2 long train instead of 1 long and 10 small. the two long train arrive at the junction at the same time, one of them will have to stop completely for the duration the other need to clear the junction, and you don't get to choose which one.

So i would say different ressources or situation can require different lengh of train, this is why the 'average train lengh in the whole network' has a meaning, it also means the numbers of 'smallER' and 'longER' trains. To achieve a situation where trains flow is CPU-optimal.


Now i have no idea if a train start slowing before a junction, does that mean he starts recalculating his path because one block of it has been turned off ?
Or does the train recalculate only when he stops completely even if the same path is valid ? Or none of that ?

EDIT: trains recalculate in the two cases.
I add the link again because it is only written like 4 times in the thread and i still asked the previous questions that are answered there :

https://wiki.factorio.com/Railway/Train_path_finding


Oh and also smaller trains, need smaller junctions and stations and are easier to design, test , move , build, ect,

[mrvn]

Update: As pointed out factorio has wind resistance. So with trains build like LC, LLCC, LLLLCCCC, LLLLLLLLCCCCCCCC the longer the train the faster it is. Most notably between LC and LLCC. The wind resistance is the same no matter the train size. So the more locomotives the train has the less power of each locomotive is spend on overcoming wind resistance. Speed and acceleration increase with the number of locomotives.

I looked at ssilks blockseconds argument and I want to give a different spin:

For a single train ssilk gave this formula: Occupied blockseconds when driving = ( LengthOfTrain + Speed * Brakeforce ) * timeOfTravel

But I think talking about travel times is the wrong approach and breaks down when you switch to multiple trains. The CPU usage we are concerned about is the time per tick. If the train takes longer to reach it's goal then that means there are a lot more ticks and for the same CPU time overall the time per tick would go down. For the time per tick the time of travel isn't the right factor. So I would like to modify the formula like this:

Occupied blocks ~= (LengthOfTrain + avg. Speed * Brakeforce) * number of trains on the move

Correct would be the sum over all trains with the individual length and speed but lets use the above approximation for the argument.

Lets go further in the argument:
a) The more blocks are occupied the higher the chance that a train needs to stop. More trains => bad.
b) avg. Speed sinks => occupied blocks sink => good?
c+d+e) longer trains => more occupied blocks => bad?

But here is something not considered: The factory needs a certain items/s moved. This means

b) avg. Speed sinks => more trains needed => occupied blocks rise => bad

And short trains simply don't carry as much. There is a direct correlation between train length and number of trains.

c+d+e) Longer trains => less trains => occupied blocks sink => good.


Overall all these are factors that affect the carrying capacity of the network. How much goods the network can transport per second and it's a chaotic system. The system might be perfectly fine until one train breaks and then 2 other have to break causing 8 more to break and suddenly the network can only transport a fraction of items per second from what it was before.

But one thing is clear to me: The network starts of behaving linear. 1 train carries X item/s. 2 trains carry 2*X items/s. 3 trains carry 3*X items/s. But only at the start. As the number of trains rises the interactions between trains become a disrupting factor until the network breaks down to congestion. There is a optimum of train size, acceleration, speed, breaking force and number of trains that will transport the maximum number of items/s, But it will be a very fragile system. Any deviation form the optimal route, even a train being just one tick late loading items, will have a cascade effect that puts the system in a death spiral. I want to stay far away from that critical point.

And that's where I disagree with ssilk: The main factor that I can influence is the number of trains on the move. The fewer trains move at any time the nearer the system is to the liner part. And that means longer trains. Make the trains long enough and all other factors become irrelevant. Say I need 128 LC trains to move enough items/s with one train leaving a station every second and taking 64 seconds to arrive on average. Then, ignoring all the above, 64 LLCC trains could move the same with a train leaving a station every 2 seconds. 32 LLLLCCCC trains with a train leaving a station every 4 seconds. 16 LLLLLLLLCCCCCCCC trains with a train leaving a station every 8 seconds. Or 1 LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC train leaving a station every 128 seconds. Taken to the extreme only one train is needed at all and it's only moving 50% of the time. There can't be any blocked segments and no repathing so all the above talk can be ignored as it doesn't apply to just one train. You don't even need any signals at all. How will that not result in the minimum CPU usage for the train? Clearly longer trains will (eventually) minimize the time spend on re-pathing.

On the negative side such a long train will need a long station. Lots of inserters to load/unload. So CPU time goes up there. It's also totally boring to have just one train. It's a balancing act.

Note: Juts one monster train won't maximize the item/s moving through the network. The argument above is for a fixed item/s throughput and minimizing re-pathing costs.

[ssilk]

I like the change of the formula. Makes really sense.

But one thing is clear to me: The network starts of behaving linear. 1 train carries X item/s. 2 trains carry 2*X items/s. 3 trains carry 3*X items/s. But only at the start. As the number of trains rises the interactions between trains become a disrupting factor until the network breaks down to congestion. There is a optimum of train size, acceleration, speed, breaking force and number of trains that will transport the maximum number of items/s, But it will be a very fragile system. Any deviation form the optimal route, even a train being just one tick late loading items, will have a cascade effect that puts the system in a death spiral. I want to stay far away from that critical point.

Exactly of what I was watching in all my games. The system works perfect for hours, I put a new train in and some minutes later I have had a complete deadlock with dozens of trains.

And that's where I disagree with ssilk: The main factor that I can influence is the number of trains on the move. The fewer trains move at any time the nearer the system is to the liner part. And that means longer trains. Make the trains long enough and all other factors become irrelevant. Say I need 128 LC trains to move enough items/s with one train leaving a station every second and taking 64 seconds to arrive on average. Then, ignoring all the above, 64 LLCC trains could move the same with a train leaving a station every 2 seconds. 32 LLLLCCCC trains with a train leaving a station every 4 seconds. 16 LLLLLLLLCCCCCCCC trains with a train leaving a station every 8 seconds. Or 1 LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC train leaving a station every 128 seconds. Taken to the extreme only one train is needed at all and it's only moving 50% of the time. There can't be any blocked segments and no repathing so all the above talk can be ignored as it doesn't apply to just one train. You don't even need any signals at all. How will that not result in the minimum CPU usage for the train? Clearly longer trains will (eventually) minimize the time spend on re-pathing.

Ahhh, that becomes a bit irritating now. But as you say: Building such long trains makes no sense anymore, cause they need so much space to fill them, that it will reach to the next station.
Indeed the train is then nothing else than belt; I've seen games that tried to built a factory around this idea: The "main bus" is then just a train in a circle with many stations and each wagon hold some kind of item.

But such long trains make more sense if the factory is really big and from one station to another it is miles. That was the reason, why I added the factor "size of your train network". Which really isn't exact enough cause what I really mean is the average time of a block to be occupied.

It's also totally boring to have just one train. It's a balancing act.

Indeed it's super interesting (for me) to have hundreds of trains running. I really like the LTN mod and it is quite interesting to have 100 or more trains running with it.

[mrvn]

I like the change of the formula. Makes really sense.

But one thing is clear to me: The network starts of behaving linear. 1 train carries X item/s. 2 trains carry 2*X items/s. 3 trains carry 3*X items/s. But only at the start. As the number of trains rises the interactions between trains become a disrupting factor until the network breaks down to congestion. There is a optimum of train size, acceleration, speed, breaking force and number of trains that will transport the maximum number of items/s, But it will be a very fragile system. Any deviation form the optimal route, even a train being just one tick late loading items, will have a cascade effect that puts the system in a death spiral. I want to stay far away from that critical point.

Exactly of what I was watching in all my games. The system works perfect for hours, I put a new train in and some minutes later I have had a complete deadlock with dozens of trains.

And that's where I disagree with ssilk: The main factor that I can influence is the number of trains on the move. The fewer trains move at any time the nearer the system is to the liner part. And that means longer trains. Make the trains long enough and all other factors become irrelevant. Say I need 128 LC trains to move enough items/s with one train leaving a station every second and taking 64 seconds to arrive on average. Then, ignoring all the above, 64 LLCC trains could move the same with a train leaving a station every 2 seconds. 32 LLLLCCCC trains with a train leaving a station every 4 seconds. 16 LLLLLLLLCCCCCCCC trains with a train leaving a station every 8 seconds. Or 1 LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC train leaving a station every 128 seconds. Taken to the extreme only one train is needed at all and it's only moving 50% of the time. There can't be any blocked segments and no repathing so all the above talk can be ignored as it doesn't apply to just one train. You don't even need any signals at all. How will that not result in the minimum CPU usage for the train? Clearly longer trains will (eventually) minimize the time spend on re-pathing.

Ahhh, that becomes a bit irritating now. But as you say: Building such long trains makes no sense anymore, cause they need so much space to fill them, that it will reach to the next station.
Indeed the train is then nothing else than belt; I've seen games that tried to built a factory around this idea: The "main bus" is then just a train in a circle with many stations and each wagon hold some kind of item.

But such long trains make more sense if the factory is really big and from one station to another it is miles. That was the reason, why I added the factor "size of your train network". Which really isn't exact enough cause what I really mean is the average time of a block to be occupied.

It's also totally boring to have just one train. It's a balancing act.

Indeed it's super interesting (for me) to have hundreds of trains running. I really like the LTN mod and it is quite interesting to have 100 or more trains running with it.

Absolutely. Such a long train is purely theoretical. Would also only work with LTN (which would program the schedule as needed) or your train-as-main-bus design where the train stops at every station in turn. Highly inefficient. As said it's theoretical and just mend to show that the optimium isn't at a certain train length. At least that's what I think. Because with train length going to infinity the number of trains on the move goes towards 0 and I see no factor working against that limit that would make any train length better than a longer train.


As for it being totally boring to just have one train gave me an idea (and why I reply at all): How about a new series of achievement for number of trains on the map? Maybe one for 10, 100 and 1000 trains? The achievement for train path > 1000 tiles could also be made into a series: 100, 1000, 10000, 100000 tile path.

[mmmPI]

As for it being totally boring to just have one train gave me an idea (and why I reply at all): How about a new series of achievement for number of trains on the map? Maybe one for 10, 100 and 1000 trains? The achievement for train path > 1000 tiles could also be made into a series: 100, 1000, 10000, 100000 tile path.

You mean placing 1000 locos on a parking with just a tiny space between them while hoping the one loco you made go in a circle full speed will get you the other one in the meantine ?

That's what l would do, then i would search on the internet "factorio how much time one loco 100000 tile achievement" and would probably be handled a blueprint that gives the achievement if you let it run 1 hour or something, and that would be a bunch of concentric circle that has its roboport included and refuel too.

That might be a very big number of circle though, and a good challenge to try and make it the smallest/ fastest ect , maybe even more complicated than just getting the achievement as a automatic milestone for this I approve.

Occupied blocks ~= (LengthOfTrain + avg. Speed * Brakeforce) * number of trains on the move

I am not sure how to understand brakeforce if i want to replace with real values, isn't the formula saying that the higher the brakeforce , the more block occupied ? I guess 1/brakeforce is an easy fix. Else it's nice .It gives a good understanding of the dynamics involved in one picture.

On the negative side such a long train will need a long station. Lots of inserters to load/unload. So CPU time goes up there.

That is the only thing i am not convinced.


I would say many small trains need many stations unloading at the same time to achieve the same thoughput of material which would mean the same number of inserter.

Let's compare 4 situations

1 =>LCCCC unload during 4 minutes
2=> LC LC LC LC unload during 4 minutes

3=> LCCCC unload during 1 minute + 3 minutes the station is iddle
4=> LC unload 1 minute another LC the next minute another LC the next minute another LC the next minute.


1 and 2 have same number of inserter and thoughtput,
4 is the same as 1or 2 excpect at lower scale
3 has the same throuput as 4 but is not good for CPU only because it create spikes during which you use more while you could have ditributed it better.

Now i understand you refers to situation 3 vs 4, but i see 1vs2 when comparing long vs short train. So i think there is something more that i cannot word precisely yet.

[mrvn]

On the negative side such a long train will need a long station. Lots of inserters to load/unload. So CPU time goes up there.

That is the only thing i am not convinced.


I would say many small trains need many stations unloading at the same time to achieve the same thoughput of material which would mean the same number of inserter.

Let's compare 4 situations

1 =>LCCCC unload during 4 minutes
2=> LC LC LC LC unload during 4 minutes

3=> LCCCC unload during 1 minute + 3 minutes the station is iddle
4=> LC unload 1 minute another LC the next minute another LC the next minute another LC the next minute.


1 and 2 have same number of inserter and thoughtput,
4 is the same as 1or 2 excpect at lower scale
3 has the same throuput as 4 but is not good for CPU only because it create spikes during which you use more while you could have ditributed it better.

Now i understand you refers to situation 3 vs 4, but i see 1vs2 when comparing long vs short train. So i think there is something more that i cannot word precisely yet.

Yes and no. The thing is with many small trains you have many small stations that all handle trains at the same time (2). As the train grows you combine all the small stations handling e.g. iron ore for a smelter into one big one (1). But then the train grows even longer and now you have one train handling iron ore and copper ore (and eventually all other goods). The stations do have to be larger but since they are for different goods at different places in your factory there would be no combining. So you get into the 3+4 case. And it would be more like "unload during 1 minute + 4353 minutes idle". Think about it. There is only one train. How many trains full of iron ore and copper ore will it need to fill a train with rocket control units for example. The rocket control unit station will be idle a long time between trains.

If you redesign your factory as the train grows to keep combining stations then the end result would be just two stations. You load stuff on one side, ship it to the other side of the factory, unload and run it through the factory again. Each loop would refine the goods more. At which point you might as well just remove the station and connect the sub parts of the factory directly.

[ssilk]

Occupied blocks ~= (LengthOfTrain + avg. Speed * Brakeforce) * number of trains on the move

I am not sure how to understand brakeforce if i want to replace with real values, isn't the formula saying that the higher the brakeforce , the more block occupied ? I guess 1/brakeforce is an easy fix. Else it's nice .It gives a good understanding of the dynamics involved in one picture.

Of course, it's 1/brakeforce, but the formula is not math, it just says, that it depends on brakeforce, now how, the rest was explained in the text. But - well - it's misleading.

I would say many small trains need many stations unloading at the same time to achieve the same thoughput of material which would mean the same number of inserter.

Let's compare 4 situations

1 =>LCCCC unload during 4 minutes
2=> LC LC LC LC unload during 4 minutes

3=> LCCCC unload during 1 minute + 3 minutes the station is iddle
4=> LC unload 1 minute another LC the next minute another LC the next minute another LC the next minute.


1 and 2 have same number of inserter and thoughtput,
4 is the same as 1or 2 excpect at lower scale
3 has the same throuput as 4 but is not good for CPU only because it create spikes during which you use more while you could have ditributed it better.

Now i understand you refers to situation 3 vs 4, but i see 1vs2 when comparing long vs short train. So i think there is something more that i cannot word precisely yet.

Well, I thought a while about it and now I try to fiddle out the different effects in detail.

a) It's chaotic

To calculate what length of train is optimal (for your situation), you need not only to take in account how one train behaves. You need to calculate how they behave in your current network with your current work-load. Which soon gets extremly chaotic.

b) ... but there are computeable parts

There are non-chaotic parts, which can be calculated, that is mainly how many "space" trains occupy. For the example above: A LCCCC train occupies a spces of 5 compared to a LC, which occupies only 2. But that is only true while you are standing. When running you need to add the reserved tracks, which looks for some speed X like so:

Train without speed:
LCCCC => 5
LC => 2

Train running at maximum speed, "R" is the reserved tracks (I just took some numbers):
RRRRRRRRRRRRRRRLCCCC => 7 + 5 = 20
RRRRRRRRRRRRRRRLC => 7 + 2 = 17

This says, that the longer the train and the faster it goes the "better", cause the "R"-part gets bigger compared to the length of train. The ratio (17 / 20 = 0.85 versus 2 / 5 = 0.4 ) between both types of trains gets more and more equal, the faster a train goes.

b1) Dependency to travel-time

This is a simpe thought: The longer the train needs to travel, the more blocks it needs to occupy, not only due to the length of the travel, but also due to the time it takes. Cause (see below) with the time the chance rises, that another train wants to occupy the same block.

c) Speed is limited!

There is a natural limit for b): when the R's cannot get longer! This happens because trains have a maximum speed. Which means: There must be an upper limit, where it makes no more sense to make a train longer. Without thinking much about it: It is clear that the ratio get's more and more to 1, the faster the train goes. So the longer the train the better. But the speed is limited, and so the advantage of train with the length of N to a second train with the length of N+1 goes to zero. I think that is simple to understand.

Now comes the other aspect: A train with the length of N needs to travel longer paths, because of his length. Ok, this is a bit difficult to understand. Let's say we have a circle with two stations. Now I put in a train with the length of 1. Then you need to add one block more space to the circle as space for the train station. The length of the track the train needs to drive from station A to B is now one block longer in average.
Now I do that with a train with length 10. I need to expand the train station to 10 blocks and that is only possible, if I add nine more blocks to the circle; this train needs to travel 9 more blocks compared to the first train.
It is of course thinkable to place the train stops so, that longer trains have no effect on travel-length. But then you need to make the belts longer! So the length of a train has an effect on how much longer the track ist.

This and the train speed limits somehow the length of trains, where trains are still effective. I would say, that this limit is somewhere when the ratio (see above) between a train with the length of N and a train with the length of N+1 is over 0.98.
This depends of course the train configuration:

LC -> reaches max. speed, but low acceleration, average travel length is 1 block longer (length / 2)
LCC -> does not reach max. speed, average travel length: +1.5 blocks
LLCC -> reach max. speed, high acceleration, average travel length: +2 blocks

This influences very strong, how much "R's" need to come into the calculations. And that it makes no sense to have very long trains on short distances.
And because there is an upper limit of R, all the other effects that I will be explained below have a much, much higher effect to the troughput of a train network, then just the pure length.

If there is someone, which can make a formula out of it and fill with real Factorio-values this could be calculated.

I estimated how much this should be (and there is a much space for discuss in it), but I think a ratio of more than 0.94-0.98 makes no more sense to make a train longer. That might be a train-length of 3-9 and a total length (including the R's) at max-speed of 30-60 or so. Again: we need numbers from Factorio game to calculate that correctly.

d) The chaotic parts

Other effects come in to play when you have more than one train in a network, where trains have a chance to cross the paths of other trains, and they are mainly chaotic nature. There are two effects:

d1) Trains that need to stop

A long train running at full speed takes less space ratio compared to a shorter train (see above), but (!) once two train cross their path, one train needs to stop. And for a stopped long train the ratio is bad quite bad, compared to the short one. This means that a stopped train occupies more space in your train network over time, which means, that there is a higher chance, that a third train needs to cross the path of the stopped one.

This is extremly chaotic, it could be that a network runs hours without problems, and suddenly due to some random crossing of trains the network comes to a deadlock. But mathematically I would explain it as a chance for a stop:

ChanceThatATrainNeedsToStop = ChanceThatTwoTrainsNeedToCrossTheirPaths

Which is (please prove me wrong, I thought only 5 minutues about it):

( OccupiedNumberOfBlocksOfTrain1 * OccupiedNumberOfBlocksOfTrain2 ) * time

And what you see here clearly is, that the chance is quadratic to the occupied number of blocks! So the length of train comes more back into game, than you might think at first!

d2) Stopped trains need time to accelerate

The chance for a train to stop another train is highly dependend to it's length and how long it will need to clear the track, which needs to be crossed. Which is dependend to it's speed and length. That influences the time, that a train needs to clear an area.

So this is the second chaotic element: When a train was stopped before a crossing it takes time for him to accelerate back to maximum speed. In other words: The longer the train, the longer it takes to clear a crossing. And the higher the chance, that another train needs to stop, because see d1).

This results in the same effect: A train system works perfect for hours and at some point a train needs to stop, which forces another train to stop and if the trains cannot clear the neuraligic point fast enough (cause they are too long), this swings up to a massive jam or even deadlock.

So the strength of this effect is extremly dependend on the next two, e) and f)!

e) Chance of crossing another trains path

The chance, that two trains cross their path is dependend on how much trains you have.
I would add this to the above formula:

( OccupiedNumberOfBlocksOfTrain1 * OccupiedNumberOfBlocksOfTrain2 ) * time * NumberOfRunningTrains^2

This seems to be quadratic (or exponential?), because one train will have no effect (it's the same train), two train will double the effect, three trains will double the effect of two and so on.

f) Influence of "neuralgic points"

If there are no crossings then the chance that two trains cross is very low. So it's clear, that the chance that two trains cross their paths depends on the number of "neuralgic points" you have in your network.

The formula looks then like so:

( OccupiedNumberOfBlocksOfTrain1 * OccupiedNumberOfBlocksOfTrain2 ) * time * NumberOfRunningTrains^2 * NeuralgicPoints

A "neuralgic point" is hard to define; I would say of it is the number of blocks multiplied with the chance that two trains need to occupy a block at the same time.

NeuralgicPoint = ChanceThatABlockIsOccupied * ChanceThatABlockNeedsToBeOccupied

which can also be written as

NeuralgicPoint = ChanceThatABlockIsOccupied * NumberOfRunningTrains^2

Here comes - the third time now - the quadratic number of running trains into game.

Summary

This is far away of beeing correct! So be careful, I sure when we look deeper into it will be much more different. But this is mainly to the complexity of this subject.

So what you clearly can see is, that the optimal length of trains is extremly dependend to the number of trains you run in your network: The current formula contains three times the number of running trains in quadratic (or more) depenencies. This makes the network very sensitive to changes when you are at the train-network limit.

But what you also can see is another effect: Reducing the length of trains shifts this sensitivity to more resilience against the chaotic effetcs. This is mainly due to the effect of d2): A short stopped train can clear the neuralgic point much faster, than a long train. But there are also some side-effects in the other parts.
So we can say as summary (till now): Shorter trains are less effective for train networks with low traffic. But with rising traffic the shorter trains will be much more resilient to chaotic effects than with longer trains.
And a second can be said: we speak here not between a difference of LC versus LLLLLLLLLLCCCCCCCCCCCCCC or so, but more to the difference between LCC and LLLCCCCCC. Much more above or below makes no sense because of the effect of c).

If someone has an idea of how to build mathematical formulas with real Factorio relevant values out of it, we could verify, how important which effect is.
Until then I would say: An optimal train size must be between 3 and 9, perhaps 10, because of c). If it's more to 3 or more to 10 depends very much of how much trains drive in your network, and how "neuralgic point free" you build your network.

But - as already mentioned: shorter trains have other advantages, like smaller train station, less inserters needed and so on, so this is n

[mmmPI]

I do not want to single out every point with a " yeah but " i would like to point out that some different network topology makes some formula not applicable or different.

tree network lane2.png (44.81 KiB) Viewed 8906 times

Situation 1 makes neuralgic points in serial, which increases their weight compared to situation 3 where whatever lengh/ speed / number of train you do in blue , it is very unlikely to affect green but it could because of the yellow lane.

While if you where to jam the yellow line in situation 3, depending on the number of train it could jam the whole factory , or have no effect at all or anything in the middle.

While most of the time our network looks like situation 2, where some segments are more connected with others and we expect the trains to follow the path we make for them, but at some point the algorithm finds out it's better differently and it's stop being intelligble.

this affects several points that were sumed up for the UPS cost, we should quantify the degree of interconnectedness precisely on which portion ect if we wanted to apply the formula with real value, or make different setup, modifying 1 part at a time at there would be a different optimal train lengh for each situation.

You could have results like LCCC is the best if you add a train that has less than 3 wagon on the other lane that share one portion of track, but LLLLLCC would be better if you add a 6 wagon train on the other lane that share the junction but LC is the best if you don't change anything at all, and LCC would give almost the same result for this particular train but would reduce effiency of another lane by 10% that you plan to add trains on ect.

You could on the other hand plan your network for predictability, especially if you build big ! I think for UPS effiency and formulas that's what you prefer.

But what you also can see is another effect: Reducing the length of trains shifts this sensitivity to more resilience against the chaotic effetcs. This is mainly due to the effect of d2): A short stopped train can clear the neuralgic point much faster, than a long train. But there are also some side-effects in the other parts.

It is what I feel from experience, small trains resist more to chaos when it happens also because they are worse than long train when long and small are both fast

As explained by B) and C) if i understood correctly, (R/lengh-of-train is bigger for small trains meaning lots of blocks reserved for few materials) whey they become both slow, small train didn't lose much.

This is the case because the weight of the train is not taken in account when calculating R, only the speed else longer train going same speed would have more R reserved than small train. ( Or do they ? x)

Many small trains would still barely functions during chaos but they tend to become chaotic faster, I suspect the same phenomenon that happens for car with the time it takes for 20 cars to start after a red light, and the last one starts moving the light is red again already which means they need to accelerate 2x for the same junction, sometimes 3 times of even more if the jam is on a long portion . but i have no idea how one would put that into factorio formula.

To measure the thing i imagine you need to have the "lanes", the general efficiency of the network would be the average efficency of each lane, lane sharing more tracks have more influence between them than lane just sharing a single junction. Depending on the junction and number of train, each junction gives a different score ( that's logical with what already exist).

Efficiency of the network is troughput of material delivered per amount of time , which is number-of-train-reaching-a-destination-full-of-usefull-material*number-of-cargo-wagon-per-train/Time. Because if your train are empty 1/2 of the time its is way less efficient than if they do all their trip while fully loaded.

The time delivery without the quantity is not enough.

It is more "logistic capabilities" rather than efficiency, maybe for UPS we also need to include/ per rail , as it factors a lot for the pathfinding.

Lots of the formulas explained above describe the math for those straight shared track portions in the ideal case. They loose a bit of precision if you account for the fact that average chances of 100% that a block is occupied is very bad, and if you add some more block that are never used elsewhere it will not make it better even though with too general formula it could look like and for this not to happen i think you need a map or mutplie formulas for multiple portions ,=>the "lanes" , or the same datas it gives i think.


I like the idea of trying to make a formula that could help predict the consequences that you might not see at first glance when trying too reach limits. It would be better than trying to predict each possible cases but i'm far from having one

[mrvn]

Summary

This is far away of beeing correct! So be careful, I sure when we look deeper into it will be much more different. But this is mainly to the complexity of this subject.

So what you clearly can see is, that the optimal length of trains is extremly dependend to the number of trains you run in your network: The current formula contains three times the number of running trains in quadratic (or more) depenencies. This makes the network very sensitive to changes when you are at the train-network limit.

But what you also can see is another effect: Reducing the length of trains shifts this sensitivity to more resilience against the chaotic effetcs. This is mainly due to the effect of d2): A short stopped train can clear the neuralgic point much faster, than a long train. But there are also some side-effects in the other parts.
So we can say as summary (till now): Shorter trains are less effective for train networks with low traffic. But with rising traffic the shorter trains will be much more resilient to chaotic effects than with longer trains.
And a second can be said: we speak here not between a difference of LC versus LLLLLLLLLLCCCCCCCCCCCCCC or so, but more to the difference between LCC and LLLCCCCCC. Much more above or below makes no sense because of the effect of c).

If someone has an idea of how to build mathematical formulas with real Factorio relevant values out of it, we could verify, how important which effect is.
Until then I would say: An optimal train size must be between 3 and 9, perhaps 10, because of c). If it's more to 3 or more to 10 depends very much of how much trains drive in your network, and how "neuralgic point free" you build your network.

But - as already mentioned: shorter trains have other advantages, like smaller train station, less inserters needed and so on, so this is n

I think you are still underestimating the effect of short trains requiring more trains to transport the same goods. You said yourself: "the optimal length of trains is extremly dependend to the number of trains". A train half as long needs twice as many trains and due to the "quadratic" in your formulas that would weigh in 4 times as much.

Also you have to consider this:

Train without speed:
LLCC => 4
LC LC => 2 * 2 = 4

Train running at maximum speed, "R" is the reserved tracks (I just took some numbers):
RRRRRRRRRRRRRRRLLCC => 15 + 4 = 19
RRRRRRRRRRRRRRRLC RRRRRRRRRRRRRRRLC => 2 * (15+2) = 34

So you see, shorter trains are actually longer.


And here is another factor towards the chaotic:

The reserved length and breaking force aren't linear. Going faster isn't always good. In fact there is a optimum speed and if you go faster the space between trains increases more than you make up for by going faster. Trains at max speed transport fewer goods than optimal.

[mmmPI]

I feel a bit sorry for ssilk because i can only notice what i disagree with some of the post while lots of it is quietly approved and is the basis for further reflexions.

So you see, shorter trains are actually longer.

And here is another factor towards the chaotic:

The reserved length and breaking force aren't linear. Going faster isn't always good. In fact there is a optimum speed and if you go faster the space between trains increases more than you make up for by going faster. Trains at max speed transport fewer goods than optimal.

I was conducing experiments to understand how the previous part applies in the game and I am not sure how to understand "R" anymore,

Can 2 trains reserve the same block ?

In the case of a X junction, the middle crossing track, can be the last "R" of a train that goes fast and has a lot like 7 so it means in 7 units of time it will physically be there if it keep same speed. While at the same time the same block can be the first "R" of a another train that is only 3 block long.

Next unit of time the loco of the 3 block long train is physically at the "R" crossing, next unit of time another loco occupy the block physically , next unit of time a cargon wargon. then 3 units of time with nothing, then 7th unit of time after initial situation the first train first loco is physically present at the block.

Would that makes any of the two trains slow down and not happened as describe ? I am unsure how to test the set-up in the game.

I see that the same idea that mrvn pointed out about reserved lengh being non linear.

I have made some setup in creative mod to visually depict the "jam" thing, you just have to turn on/off the constant combinator to run a setup, the 2 first I use to see the differences of traffic flow and roughly it shows when and how trains start to slow when they can't reserve blocks, up to the point where some of them are completly stationnary, like in a real traffic jam and it's propagation in the opposite side of the normal rotation of train, and also some of the slowest speed they can get before reaching the point of complete deadlock.

20190701144512_1.jpg (486.62 KiB) Viewed 8724 times

I tried several signaling for blocks, no wagon testing.

The other setups are to test behavior when there is no block at all, i just added and removed loco to try things. Last one was an attempt at replicate the "train ballet" trains runs full speed and never collide, based on previous observation, looks like an atom.

20190701144719_1.jpg (507.16 KiB) Viewed 8724 times

Here the save instead of the blueprint so no need to manually put (all) train in automatic.

Frog 9C.zip

(4.87 MiB) Downloaded 114 times