From OpenTTD

EN   FR

Contents 1 Carrying capacity of your network 1.1 Signal distance (SD) 1.1.1 So what signal distance should I use? 1.2 Train length (TL) 1.3 Quantifying carrying capacity 1.3.1 Train Density (TD) 1.3.2 Theoretical Maximum Train Density 1.4 Carrying Capacity (CC) 2 Making your network more efficient 2.1 Splits 2.2 Merges 2.2.1 Cyclotrons 2.2.2 Parallel cyclotrons

[edit] Carrying capacity of your network

This page is intended as a theoretical treatment purely of carrying capacity. Junctions and networking are much more important. Disclaimer over, let's consider the various factors that affect your carrying capacity.

[edit] Signal distance (SD)

This is a fairly obvious one. Widely-spaced signals will result in a lower carrying capacity. With an SD of one signal every N tiles, the minimum gap between two full-speed trains can never be less than N+1 (Figure 1). When trains are this close together, you have reached the theoretical maximum train density. In practice, reaching this density is impossible.

[edit] So what signal distance should I use?

• Two tiles

An SD of two gives a minimum gap of 3, and is the optimal practical solution.

• One tile

An SD of one is fraught with problems. Even a track split causes a signalling gap. It would be possible to join angled rails with a signal gap of 1, but this would result in a considerable increase in build complexity.

• Half tile

Angled track is capable of double density signals. This may be of theoretical interest, or for shaving a few millimeters off a near-miss situation.

Whatever SD you choose, one important consideration is consistency. The capacity of a track is determined by whichever individual signal gap is the largest. Thus, a track with one signal every two tiles, that has an anomalous one-off gap of three or four tiles, will suffer from greatly diminished capacity and can potentially jam and violate rule 1 (Figure 2).

In the openttd engine, trains move slower on angled track (thanks SmatZ!), and thus require an increased signal density to prevent bottlenecks - if using an autosignal setting of 2, you will need to manually increase the signal density on any angled rail you have to 1.

[edit] Train length (TL)

This is a double-edged sword. A longer train will increase the likelihood of incurring a realistic acceleration penalty, making construction more spread out and complex. However, a longer train length increases the maximum cargo capacity of your network. Note that when using engines that have a front and rear sections, the additional 1/2 tile taken up makes shorter train lengths even less favourable.

Typical values of three to five tiles are normal, with four being a particular favourite for high-speed networks.

[edit] Quantifying carrying capacity

[edit] Train Density (TD)

Your network will carry a certain number of trains, and assuming you have a standardised train length, we can define some metrics. The Train Density (TD) for a track is given in units of trains per thousand tiles, and can be calculated by counting the number of trains on that track and dividing by the length of the track.

Typical measured values for an unoptimised network of 4-tile trains are a TD of 25 (trains per 1000 tiles).

The maximum TD before traffic jams become self-propagating can be measured by permitting a queue of trains to accelerate from a halt and then measuring the train-train distance when all trains have reached full speed, and using the formula

1000 / (TL + train gap)

For example, a fully-laden 4-tile Chimaera (top-end MagLev) was found to have a train-train distance of 12, giving critical density of 1000/16 or 62.5.

Because this critical density incorporates information about acceleration and time to reach top speed, it can also tell you about the practical capacity of your network. For example, using trains with a lower top speed actually makes it easier to have a dense network. The average train-train gap is much smaller for rail than for monorail or maglev. Repeating the previous example but using the electric rail T.I.M gives a train-train distance of only 6, and a critical density of 100. Slow doesn't mean better, however, as the reduced line density will be more than compensated for by quick turnaround times.

It is possible to run a network at higher than the critical density, but it is ill-advised.

[edit] Theoretical Maximum Train Density

Simply put, this is the train density if your network is entirely filled with trains at the minimum distance between each other. You will never reach this.

This is given by 1000 / (TL + SD + 1)

For example, 4-tile trains and a signal distance of 2 will give a theoretical maximum train density of 140.

[edit] Carrying Capacity (CC)

Since TL alters the carrying capacity of a line, comparing TD across different TL is meaningless. In order to compare efficiency figures between different personal preferences, we need a new metric. This new metric will simply be a measure of how many units of cargo your network is transporting per year, per track. It will be directly proportional to the average quantity of cargo per track tile, and also to how fast this cargo is moving.

Work on this unit is pending.

[edit] Making your network more efficient

Ok, so now that we've defined the parameters that we had already intuitively understood, how can we use them to improve our networks? The golden rule of network optimisation is that trains on the network never slow down. There are two possible parts of a network where this could happen, splits and merges.

[edit] Splits

For a track split, one must ensure that there is not a longer-than-normal signalling gap at the split point. This can be taken care of by careful or over-abundant signalling.

[edit] Merges

Merges present us with a unique problem. For a trivial merge, trains on the mainline could potentially be stopped by a sideline train. There is already a body of work on Priorities by our colleagues in the cooperative circuit. A perusal of this link should familiarise you with the principles of priority merges.

Consider a typical non-junction merge, at the exit of a pickup station. A tightly-packed optimised stream of trains enters the station, but because of differences in loading times, this order is disrupted on the station exit, and you end up with two tracks of loosely-packed trains. One of these lines, designated the main line, will have, on average, train-train gaps large enough to fit a third train into. Simply connecting the two lines together will not work, and a priority merge is required.

Note that, because trains that drop off cargo always spend the same length of time at a platform, it is possible to dematerialise and reassemble a tightly packed stream of trains, even one above the critical density! (Figure 3) A first-pass merge using a priority block will reduce the traffic ratio from 1:1 to about 3:1 in favour of the main track (Figure 4). Adding a second priority merge straight after the first one would be a futile gesture, since trains on both lines would continue at the same speed and the mainline train would simply claim priority again. Introducing a delay by a loop of track, followed by a second priority merge, will reduce the sideline to a mere trickle of trains and will have filled in most of the available slots on the mainline. Existing solutions would involve a pre-acceleration track, however a cyclotron eliminates the need to lose momentum.

[edit] Cyclotrons

Consider a sideline that loops back on itself after a failed priority merge. A train in this loop would continue to re-test the mainline for entry conditions, once every 8 * 'TL tiles until it found a space large enough to merge with the main line. After the cyclotron was empty, the next waiting train could pre-accelerate and be injected into the cyclotron, ready to continue the cycle. This system has some flaws, however, as it has a capacity of one train and there will be many missed opportunities due to the train being in the wrong position in the accelerator. The design is pictured here for reference. Junctions are a large and well-trodden area of openttd; I have restricted myself to unbranched feeder structures. You will find that a highly-optimised stream of trains does NOT weather a junction well.

Refinements to the cyclotron are possible. There is enough space on the track loop to contain two trains, and a system of priority signals will enable a second train to optionally enter the cyclotron. With two trains in the cyclotron, there will be a doubled chance of entering a slot on the mainline. In order to prevent a traffic jam inside the cyclotron (which would be disasterous), some delay tweaking is necessary, but the end result is exceedingly useful.

The injection delay assumes that the second injected train is accelerating from standstill, and there is a small chance that second train has in fact chanced upon the cyclotron entrance at full speed. In this case, the timing will be wrong and the second train will almost certainly cause a jam within the cyclotron (and consequently on the main line). This can be compensated for by some additional signalling to filter out full-speed trains. The filtered out full-speed trains can either be diverted onto a second loop, or simply drained of momentum by a signal.

A cyclotron incorporating all the optimisations discussed, and some additional fixes, is shown in Figure 5 .

A savegame containing all of the techniques discussed above is available Here (version 0.7 or higher required to open).

Editor's note: Whilst I would like to defend my cyclotron refinements, experimentation has proven that pre-acceleration is a more robust system. The two have been combined in the savegame linked previously.

Feature availability
< 0.5	0.5	0.6	0.7	1.0	Nightly
☒	☒	☒	☑	☑	☑

[edit] Parallel cyclotrons

An attempt to minimize the drawbacks of the full featured cyclotron leads to parallel, small, 1-train cyclotrons. In this design, an array of cyclotrons, each handling one train, may be fed simultaneously. They may have different loop size in order to prevent synchronization between the cycling trains, giving more chance to find a slot in the flow of the main line. Each loop still needs it own acceleration lane so the trains enter the loop at full speed. If a train happened to enter the loop at low speed, it would get a chance to join the main line at non-max speed and cause a possibly large traffic jam.

Figure 6 shows a parallel cyclotron with two loops.

A savegame with the example given in Figure 6 is available Here (version 0.7 or higher required to open).

Advantages over the full featured cyclotron:

• Can handle more than two trains
• Faster fail-and-retry pace
• No need to synchronize the looping trains
• Easier to build and remember

Drawbacks:

• Bigger when using more than one loop