Maximum throughput of a rail line

[mmmPI]

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.

For the part i understand :

There is the additionnal information of the braking research that is required to compare result, as high braking research increase the maximum throughput due to allowing train shorter braking distance, being closer to each other and thus increasing density even at the same speed which would yield more wagons per minutes.

However, from your "about 325 wagons/min" i suppose you have accounted for braking research as this throughput cannot be reached otherwise. 325 wagons/minutes with 1-20 trains represent 16.25 trains per minutes, which is to my calculation requiring at least braking research 8 ( 1.8 modifier )

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

This throughput can be reached with such braking research and even a little more, but only if the trains are allowed to reach max speed or close, which would only allow 3 of such trains in a square of 100 height and 100 width.

Now 263 wagons per minutes with 1-12 trains represent 21.6 trains per minutes or so for this one braking force research 9 is required and this throughput would require train running at around 238 km/h , which for the same kind of loop would require 4.77 trains, so most likely not possible in game to reach on this amount of track
https://www.desmos.com/calculator/yfxtp8stbh

but a sligthlier larger loop of 96 width and 250 height would get this throughput with 8 trains.

And finally 125 wagons per minutes with 1-4 trains is 31.25 trains per minutes , this one would only require braking force multiplier of 1.4 https://www.desmos.com/calculator/ktrchs6ai2
I suppose this is the test where your prediction is the lowest compared to mine, and i'm afraid i have already posted a save game where a throughput of 37 trains per minute is achieved with 1-4 trains, ( which was done with braking research giving a multiplier of 2) so i have to disagree a little on this one and think something must have slipped in the measure because the other results are closer to the max throughput theorized in perfect flow condition.

My guess is that the train was allowed to go too fast but you had braking research mutiplier 2 https://www.desmos.com/calculator/8zxbpcqj5n
The train reached its max speed or around 250 km/h which correspond to around 32 trains per minutes on a single lane but you would have gotten a higher throughput if trains were going at 160 km/h or so , around 37 train per minutes.

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.

I think your method for measuring throughput is correct, but i think your method to estimate the max throughput is not.

I have some data that log the position ID and speed of 12 1-4 trains in a traffic jam on a square loop

train_brake_measure_results loop 1.txt

(2.9 MiB) Downloaded 44 times

Still trying to find a way to import those in Desmos, ideally to graph the speed and position of trains 658 667 694 and so on over the few minutes of recording.

Edit : it appear those data only log something about a train when it is braking and as such it is only the "braking profile" of the trains, the acceleration is not shown.

It would also appear that for train 658, the braking profile repeat itself after 16 occurences of 0 speed. With those it is possible to "math" the speed of propagation of the traffic jam, the average speed of the train during the traffic jam in the stop and go regime, and then compare with the same setup without traffic jam due to signal being spaced closer to each other.

The data correspond to the loop 5 in previous save game

[quyxkh]

I think your method for measuring throughput is correct, but i think your method to estimate the max throughput is not.

I think you're right, leaving off the signal spacing made the numbers not good, here's a fixed version that shows how much space each train needs empty to maintain its current speed, you have to tell it the signal spacing, divide the route length by that rdist should give you how many trains you could conceivably fit and still achieve that speed and (close to that) throughput. At the receiving end you'll need an available stop for each arriving train of course, any train's braking point overtakes the reserved signal ahead of it is going to jam the route when it brakes.

Code: Select all

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={}
sdist=30 --[[ distance between signals in meters, 30 is big-electric-pole interval ]]

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] or not trains[tname].path_end_rail.valid 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, rdist=%g, throughput/min=%g@%gm signal dist (1 train / %g ticks", _.nwagons,
                    _.speed, _.rdist,
                    _.nwagons/(_.rdist/_.speed/3600),sdist, _.rtime))
                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
            _.rdist=_.rdist-(_.rdist%sdist)
            _.rdist=_.rdist+2*sdist
            _.rtime=_.rdist/_.speed
            _.path_end_rail=v.path_end_rail
            end
        end end
    end)

(edit: I added the inter-train interval in ticks, I think dispatching with at least that interval and keeping them on parallel tracks until they get up to speed, then merging onto one track, will work, haven't tested that yet. Any variance in signal spacing would mean you'd need extra buffer in front, so give it the usual spacing plus the largest of whatever shorter spacing you might use)

[mmmPI]

leaving off the signal spacing made the numbers not good, here's a fixed version that shows how much space each train needs empty to maintain its current speed, you have to tell it the signal spacing, divide the route length by that rdist should give you how many trains you could conceivably fit and still achieve that speed and (close to that) throughput. At the receiving end you'll need an available stop for each arriving train of course, any train's braking point overtakes the reserved signal ahead of it is going to jam the route when it brakes.

How do you stop the thing to print if by not reloading the map ? that's my lua level, just letting you know before you attempt to explain more things.

Apart from that urgent matter, i think your previous method was calculating properly the "throughput of trains at max speed" but this doesn't yield the highest "number of wagons per minute".

Adding in the calculation the block length will allow to predict a more accurate maximum that is not too much overestimating the throughput achieved , the higher this block length as it factor in the "needlessly" reserved space by a train that is wasted for density / unoccupied nor by train nor any braking distance. This is what farcast model does.

I understand the idea behind route length addition to math the distribution of trains this is related to density. But i am unable to understand how you do for the braking distance, i'm looking for square roots but are you getting it from the game and not mathing it? cuz the only sqrt i see is used for the distance travelled by the train each tick in the early line ? This braking distance math sounds necessary piece of the formula, also i see a modulo operation rdist%sdist which makes me think this is the addition of the block length but i can't understand what is accounted for when train length>2 block length.

I don't understand what is happening when the command is running , and what's with the available stop ? is this the answer to original question or just a joke ? there is no train it's all invisible ! i understand they are simulated using the game formula and i'm getting the result of the actual game code running, which i don't expect to differ much from the models ^^, but there was 10 ticks unexplained when a real train braking occurs, the game seemed to take always 10 extra tick to have the train come to full stop,so maybe it impact the braking distance, or the way the game reserve blocks, or another explanation lying around behind a bit more understanding of lua as of now i'm unable to use the code as intented

Edit : i understand i need to have a train running for the command to function , it gave me some result, i understand how to tell it the signal spacing, and that i don't have to tell it the length of the total route, it seem to me that if i don't give it the correct signal spacing used by trains it overestimate the throughput printed ?

[quyxkh]

how you do for the braking distance, i'm looking for square roots but are you getting it from the game and not mathing it?

That's right. Each tick I record the distance from the front and back rail of the train to the train's current path_end_rail. Before recording it, I check whether the path end rail has changed since the previous tick. If it has, that's because the braking point passed a scheduled stop. I use waypoints so the trains don't brake, they just go right by, which means the recorded distance is as close as the train got before its braking point passed the stop: that's as close as I know how to get to the actual braking distance. Since the next tick the train would (because it did) pass the stop, it'd have had to brake at the recorded distance anyway if that had been a red signal or whatever.

also i see a modulo operation rdist%sdist which makes me think this is the addition of the block length but i can't understand what is accounted for when train length>2 block length.

The modulus gets me the rewainder, subbing from the distance gets me the lower bound on the length of signal-distance blocks the train can occupy, plus one because the train will certainly at some point not be on an exact edge boundary so it needs an extra block for that, plus one more because its braking point has to enter an empty block.

This is the blueprint I started with, I used it to check the effect of wagon count on braking distance and then started running the code here on the looping trains.

0eNqtnU1zE1caRv+KShtmUob07fvVl6psspzZzHoyFCWshqiQJZckk6Qo/vu0TAxGUeAc493gjyN1v3qH4sl9Tr+fv1rfjNe71eYwf/5+vhz3l7vV9WG13cyfz3++Wa2Xs8Ov4+zV9Wy1mS1m68Wr2dXi+mL2w3o8zFaH2e5mM3u93U3fOqwu3/5wMbte7A/jbLFZzsbfx8ub6X8ff/9ye3V1/Nqrcb397fhDN/uP33izuBovZrPFcvnjbrzavhtnvy3ebDf72WE7OxxRF7PdeHyRe5Tjl/Y3V+Oz/23+t/nx8vb13168O77D68Vqt//HEfpsf7N7vbgc97+EF89erzbLl+PmsDqsxv3L16v1YdyNy/eHP67Hn56stxN3e1i9G598+OdsuZ29e7ba7Mfd4clue/l2PDx9fTOun8ivHnaL1ebZ9G5vFuuXV9vl+NPrxXq65rvv7K/HcfnT55/7/eV0Fb8tdsuXt9+ZjZvl/GK+upxuxfz5L+/n+9WbzWJ9HNHxTU+zWR3Gq+knNtOlTn+aKOv5h+kXNsvx9/nz8OHFxfzuem9///YPf7zc3Fy9GnfTD3z6zds38HR/2F5PtOvtfvVx9u/nE+Zpjfli/sf8eV8n9nK1Gy8/frdczPeHxZ+fksX0wn95gf7TC1ze7N6Ny6e37/DMK6Tu9hVid/IKZ5jxE3N/fNdvfj38LfXufbcvqf0ZahLUiKlZUAOmFk7tG6ZWQa2YOggqn1YTVD6t0AksH1cIHBv4vEIvsHxgQexX4BMLYsGCGJnYsCBGJlasEyMTO9aJkYkl68TIxJZ1fGS92LKOj6znW1YaH1nfCywfWR8Flo+sTwIrRpYFVoyMb1kZxMiqwIqRDQIrRtYElo8sdgLLRxbFllU+sii2rPKRRbFllY8sii2rYmRiy6oYmdiyIkYmtqyIkYktK2JkYssKH1kSW1b4yJLYssxHlsSWZT6yJLYsi3+RiS3LYmRiy7IYmdiyJEYmtiyJkYktS2JkYsuS+Fe02LLER5bFlkU+siy2LPKRZbFlIvfIYstM8CG2TCQfWWyZiD6y2DKRfWSxZSL8yGLLRPpRxJaJ9KOILRPpRxFbJtKPIrZMpB9FbJlIP4rYMpF+FLFlIv0oYstE+lHElon0o4gtE+lHFVsm0o/KtyyL9KP2AstHVqPA8pHVJLBiZFlgxcj4lmWRftQqsGJkg8CKkTWB5SMbOoHlIxvElon0YxBbJtKPQWyZSD8GsWUi/RjElon0YxBbJtKPQWyZSD8GsWUi/RjElon0o4ktE+lHE1sm0o8mtkykH01smUg/mtgykX40sWUi/Whiy0T60cSWifSjiS0T6UcTW5bMf5UWaybij9CJPRP5R+jEookAJHRi00QCEjqxatHMTexaNHMTy9abuYlt683cxLr1Zm5i38wpEHEMJKtjIGLfzDkQcRAkm4Mg4iRINidBxFGQbI6CiLMg2ZwFEYdBsjkMIk6DZHMaRBwHyeY4iDgPkkUiEsSBkCwikSBOhKRmzl31givmJs6EJJGKBHEoJDUztyy4Zm5839Jg5lYF18xtEFwztya4Ym7iaEgS4UgQZ0OSSEeCOBySqjnoKPZN5CNBHA9J1cxN7Fs1cxP7VszcxL4VMzexb8XMTeybSEmCOCSSREwSxCmRJHKSII6JJBGUBHFOJGVzsljsWzZzE/uWzdzEviUzN7FvycxN7FsycxP7ZvIScVwkmbxEnBdJJi8RB0aSyUvEiZFk8hJxZCSZvEScGUkmLxGHRpLJS8SpkWTyEnFsJJm8RJwbSSYvEQdHkslLxMmRZPIScXQkmbxEnB1JJi8Rh0eSyUvE6ZGkujNi30xeIs6PJJOXiAMkyeQl4gRJMnnJvSMkX29VxuN/6DjTqoxnqaKl9uffxjF+ya1nuXzb4p+pxik3nOVG3C0tH6mFUBO+t/0d9Swny3eX0pfvLp2lFvnuTqn5LLXqyadKuINs/+aOfJ6a/PSfUs836Dr9KT29B2e3SpwYuWsr50Deb6/7yowbdWOZcZPuLDNu1q1lxi26t8y4VTeXGXfQ1WXGbbq7jLji6MhdeZlxg24vM26v68uMG3V/mXGTLjAzbtYNZsYtusLMuFV3mBl30CVmxm26xUy4vThDcldjZtyge8yM2+siM+NG3WRm3KSrzIybdZeZcYsuMzPu5327XOzebJ/eenzOUrtncRpHuP+353a3moB/GmW6Z8dvrTbvpi9td9OPbG7W67OvOegGNbuWpivUiCvOl9x1qBk36BI14/Z0pjU+1kyDb26za/HVbcb13W3GLfTel/Jo977qwji7lkE3xhm36co44vad7owzbqAzze2xZmo0JkV8Po3HJIvPihGZZPFZuXdm5Vv3vn+0e190P55dS9UFecYddEOecZuuyCPuvfMs35hpyo81U+NBSeLzaUQoSXxWjAklic/KvbMu37j3cXi0e5+1DoBdS9E+AMatWgjAuIM2AjBuwzMNjzVTI1IReWZvTCoiz+yNSkXkmf29MzLfuPd9erR7n7T9gF1L1voDxi3af8C4VQsQGHegMw310WbatHUBXYtRsYjctjcuFpHb9hn/2zU8Wh5hTC0iK+6NqkVkxb1xtXTms1K074FxccbUPVoekb1kgl2Lt0wgbvGaCcb9vKefhdlnRQgwjjiMV/vjL90TZ98eWDj74r2WXLCLitpywbhJay4YN2vPBeMWLbpg3KpNF4w7aNUF4zbtukDc2mnZBeMGbbtg3F7rLhg3at8F4yYtvGDcrI0XjFu08oJxq3ZeMO6gpReM27T1AnGNBcYEuEYDY8JU44ExYaoRwZgw1ZhgTLBpVDAm2DQuGBNsGhmMCTaNDcaEjEYHY0JG44MxIaMRwpjAzxhhTOBnlDAm8DNOGBP4GSmMCd+MFcaEb0YLY8I344UxQZgRw4ggLBoxjAjCohHDiCAsGjGMCKWiEcOIUCoaMUwwc8tagMG4RQswGLdqAQbjDlqAwbhNCzAQ14hhRFgTjRhGhDUx9FqAwbhRCzAYN2kBBuNmLcBg3KIFGIxbtQCDcQctwGDcpgUYiNt3WoDBuEELMBi31wIMxo1agMG4SQswGDdrAQbjFi3AYNyqBRiMO2gBBuM2LcBAXCOGEXlJNGIYkZdEI4YReUk0YhiRl0QjhslmblkLMBi3aAEG41YtwGDcQQswGLdpAQbiGjGMyEuiEcOIvCQaMYzIS6IRw4i8JBoxTDRzy1qAwbhFCzAYt2oBBuMOWoDBuE0LMBDXiGFMXmLEMCYvMWIYk5cYMYzJS4wYxuQlRgxj8hIjhjF5iRHDmLzEiGFMXmLEMCYvMWIYk5cU+NzyT9ATn0R//7nlr+ZnX8I+uTwX8OTy4p9dnjO5If7p5Yzrn1/OuP4J5ozrn2HOuP4p5ozrn2OOuNU/yJxx/ZPMGdc/ypxx/bPMGdc/zJxx/dPMGdc/zpxx/fPMGdc/0Jxx/RPNEXfwjzRnXP9Mc8b1DzVnXP9Uc8b1jzVnXP9cc8b1DzZnXP9kc8b1jzZn3PZQG0B+6Ent2DpvAyDXIg6hfLIBIG7vbQCIG70NAHHTQ20A3zHT7G0A6FqKtwEgbvU2AMQdHmoD+I5737wNIJMnp3feBoC4wdsAELf3NgDEjQ+1ATx4psnYakoQ15K9DQBxi7cBIG59qA3gO+794G0A6FqatwEQrrHVZPFZMbaaJD4r3FZzagN4+EyNrSaJz6ex1STxWTG2mmQ+K+WhNoDvuPfV2wDQtQzeBoC4zdsACNfYakS2mLit5tQG8PCZGluNyDOTsdWIPDMZW43IMxO31ZzaAL7j3hdvA0DXUr0NAHEHbwNA3OZtAITLbTWnNoCHz9TYakRum4ytRuS2ydhqRG6buK0mdI9277O3AaBrKd4GgLjV2wAQd/A2AMRtD7UBPHymxlYj8ulkbDUin07GViPy6XTv4I6zAeTvtwGklLwNAF1U9jYAxC3eBoC41dsAEHfwNgDEbd4GQLi58zYAxA3eBoC4vbcBIG70NgDETd4GgLjZ2wAQt3gbAOJWbwNA3MHbABC3eRsA4ZbO2wAQN3gbAOL23gaAuNHbABA3eRsA4mZvA0Dc4m0AiFu9DQBxB28DQNzmbQCEa+wxJmQ09hgTMhp7jAkZjT3GBH7GHmMCP2OPMYGfsceYwM/YY0z4ZuwxJnwz9hgTvhl7jAnCjD3GBGHGHmOCMGOPMUGYsceYUMrYY0woZewxJpQy9hgTEBl7jAmIjD3GBETGHmMCImOPMWGNsceYsMbYY0xY05K3ASBu9jYAxC3eBoC41dsAEHfwNgDEbd4GALi567wNAHGDtwEgbu9tAIgbvQ0AcZO3ASBu9jYAxC3eBoC41dsAEHfwNgDEbd4GQLih8zYAxA3eBoC4vbcBIG70NgDETd4GgLjZ2wAQt3gbAOJWbwNA3MHbABC3eRsA4Rp7jMhLsrHHiLwkG3uMyEuysceIvCQbe0w0c8veBoC4xdsAELd6GwDiDt4GgLjN2wAI19hjRF6SjT1G5CXZ2GNEXpKNPUbkJdnYY4KZW/Y2AMQt3gaAuNXbABB38DYAxG3eBkC4xh4j8pJs7DEiL8nGHiPyknz/kUlfrerf1mfOVPXjWaqo+N79bdy+5Naz3CzdBfUr7oJ/r65m/9pu3sym93X2xfgKxrsI5eQiwlluxXaEckstPaEOeJD9HfUsp8l3V7sv3106R713vIS9u1NqPksN+mNWI+Faf0Ut4MOb7aqdUs8usDhYcvcpPb0HZ1c4w1W7U23Uk/+3KfdX7T+Lw251+Xb23wl4mPBnX7BovUet5AZVrfdg3EHrPRi3ab0H4pZO6z0YN2i9B+P2Wu/BuFHrPRg3ab0H42at92DcovUejFu13oNxB633YNym9R6IazQynZib0ch0Ym5GI9OJuRmNTCfmVpPWezBu1noPxi1a78G4Ves9GHfQeg/GbVrvgbhDp/UejBu03oNxe63aYNyoVRuMm7Rqg3GzVm0wbtHaC8atWnvBuIPWXjCuV1AgbvMKCsb1CgrG9QoKxo1aB8G4SesgGDdrHQTjFq1mYNyq1QyMO2g1A+M2rWYg3GKUL6kKbtCaBMbttSaBcaNWFjBu0soCxs1aWcC4RSsLGLdqfQDjDlofwLhN6wMQ16hbRF5SjLpF5CVFnDgpIi8pRs8i8pJi9CzBzC3rWj3jFl2rZ9yqK+6MO+iKO+M2XXFHXKNgEXlJ6YOumzNur+vmjBt13ZxxfeObcX3jm3F945txfeObcX3jm3F94xtxo298M65vfDOub3wzrm98M65vfDOub3wzrm98M65vfDOub3wzrm98I27yjW/G9Y1vxvWNb8b1jW/G9Y1vxvWNb8b1jW/G9Y1vxvWNb8b1jW/Ezb7xzbi+8c24vvHNuL7xzbi+8c24vvHNuL7xzbi+8c24vvHNuL7xjbjFN74Z1ze+Gdc3vhnXN74Z1ze+Gdc3vhnXN74Z1ze+Gdc3vhnXN74Rt/rGN+P6xjfj+sY34/rGN+P6xjfj+sY34/rGN+P6xjfj+sY34/rGN+IOvvHNuL7xzbi+8c24vvHNuL7xzbi+8c24vvHNuL7xzbi+8c24vvGNuM03vhnXN74Z1ze+Gdc3vhnXN74Z1ze+Gdc3vhnXN74Z1ze+Gdc3vgm3dr7xzbi+8c24vvHNuL7xzbi+8c24vvHNuL7xzbi+8c24vvHNuL7xjbjBN74Z1ze+Gdc3vhnXN74Z1ze+Gdc3vhnXN74Z1ze+Gdc3vhnXN74Rt/eNb8b1jW/G9Y3vv3JfXMz3l7+Oy5v1uJ8//+X9vScNHP/cl3DvJ25/4PTZ7p//vJh/eHH8ypeI6e/Wv0ecVqy/0gh9cXyvx0cYHF95fTNe71abw3St68Wr42MM5j/vFm9XE2m5miCby3F2GPfH778bd/uPFzuE6d+FfR36GHLuP3z4P7AxXxU=

Copy blueprint

[mmmPI]

That's right. Each tick I record the distance from the front and back rail of the train to the train's current path_end_rail. Before recording it, I check whether the path end rail has changed since the previous tick. If it has, that's because the braking point passed a scheduled stop. I use waypoints so the trains don't brake, they just go right by, which means the recorded distance is as close as the train got before its braking point passed the stop: that's as close as I know how to get to the actual braking distance. Since the next tick the train would (because it did) pass the stop, it'd have had to brake at the recorded distance anyway if that had been a red signal or whatever.

That's convoluted in the good way , if i understand correctly the braking distance is then updated twice per lap if there are 2 train stop acting as waypoint which is the minimum to have the train going continuously, more stop without conditions on the loop would update the data faster but a larger loop would decrease the rate of printing by the command.

The imprecision for the braking distance is then in the order of the train speed in tile per tick, which is no more than 1.38 tile or meter but no need to worry about anything related to block length or signaling.

I'm unsure if i understood correctly how farcast''s brakemeter function because it had to overcome block length imprecision to measure the braking distance ,but i think it does something similar where you could increase the precision of the measure by averaging the (braking distance) result over long period of time ( several braking distance measurements of trains with very close signals), because following the law of large number it would sometimes be very little distance added, sometimes the maximum of those 1.38 ? Those math were necessary i suppose to make the formula saying a locomotive is 36000 Newton of forward force, friction is 1800 newton per rolling stock which is how the braking distance is mathed in both models.

At this point there is the question of speed variation there shouldn't be one or the averaging would mean nothing. I think to establish the original formula the braking was measured in lab conditions which allowed for averaging potentially forever to increase precision of the measure.

I understand the command print a "snapshot" result like a driver going on a circular track that would know its braking distance because it has some flexible measurement stick in front of the car whose length vary with speed, and there is some spectator in the public that measure the time it takes for that stick to cross the finish line knowing the speed of the driver. The stick is the distance between the front of the train and the red dot shown as the braking point of the train in debug, so it's not only varying according to speed, but also based on the car's weight and tire friction and air-resistance of the car wether it's raining or not, so the driver and his buddy spectator could potentially study all those by changing 1 factor, then another to extract datas about the car.

I'm not sure how works the combinator contraption from xKnight, improved by farcast that achieved the in game measurement originally, the averaging braking distance from acttual in game measurement, but having a method to measure brake distance "at any time"( wherever one adds a waypoint) allows then all the previous extraction of data, that's like the magic stick, the command you propose using is giving the result under the form of a "snapshot" that if averaged would yield the value used for the models by changing 1 factor at a time like the number of wagons, or loco, or fuel or air-resistance profile of the front rolling stock. The value used for braking distance in the model already comes from the game, so i did not doubt their validity. I'm impressed and happy to see how it can be done using lua command. That's different than what the mod i used to get the data does but it's the same langage, it gives me example i could reuse combined or modify

(edit: I added the inter-train interval in ticks, I think dispatching with at least that interval and keeping them on parallel tracks until they get up to speed, then merging onto one track, will work, haven't tested that yet. Any variance in signal spacing would mean you'd need extra buffer in front, so give it the usual spacing plus the largest of whatever shorter spacing you might use)

Wikpedia refers to this as " The inverse of flow is headway (h), which is the time that elapses between the ith vehicle passing a reference point in space and the (i + 1)th vehicle." And then they add " In congestion, h remains constant. As a traffic jam forms, h approaches infinity. "

You are calculating it, from result you measured, like the braking distance implictly embedding train length in the difference between front and back of train. So you would never read "0" instead the command would just not print anything until a train actually move. It would be impossible to know the throughput if a train is stopped anyway.

The "headway" one can also measure also by measuring how many ticks between 2 times a signal turns red. That's how the train counter from disentius i used in the save game functions. It send pulses when it detect an edge in the signal color red and "somehow" measure how many pulses in a minute. And thus how many trains per minute. Which i transformed into speed because i embedded the length of the loop in the calculation and the number of trains on my loops. 12 trains, 868.xxx meters long loop, if you know how many time between 2 trains, you know the speed at which they go, that's the same "snapshot" result that would need to be graphed overtime to represent how a train behave in a traffic jam, or in a situation of stop and go traffic .

I know this is not really necessary to answer the question of the maximum throughput theorical or practical because that would only occur in suboptimal condition for traffic far from the maximum. But i think it is fascinating how simple rules yield very complex system with nice graph to look at.

The modulus gets me the rewainder, subbing from the distance gets me the lower bound on the length of signal-distance blocks the train can occupy, plus one because the train will certainly at some point not be on an exact edge boundary so it needs an extra block for that, plus one more because its braking point has to enter an empty block.

This particular reasonning is troubing me of some sort, the number of single block to account , 1 or 1+1, 1+rewainder rounded up ? This is because in one way it is true that it is making modeling more accurate because it shows that the theorical maximum is influenced by how close are signals, if further aways it induces more reserved block and thus forces a lower density of cargo.

But then this matters more when spacing is "high" , but then when spacing is "high" there is a increased / induced risk of speed variation of the trains inside a block. There is no more condition to use the rest of the model that assume all trains have the same speed to generate "train / minutes" from 1 measurement, as with your lua commad, or with the models that assume "perfect flow" aka all trains have the same speed.

It leaves me unable to fully agree with anything incuding my own model because given the deterministic nature of factorio, the traffim jams are chaotic but not random, and i know there are some math to describe those emergent phenomenon that's just i'm just unable to pratice but there's plenty documentation exploring many direction that's more than a life time worth of hobbyist things x).

I can't picture mentally what's being calculated if it amounts to 1 or 2 blocks how and when. I read 3 different approach from this page https://en.wikipedia.org/wiki/Traffic_f ... f_analysis some of the documentation regard such case as a matter of periodic boundary conditions https://en.wikipedia.org/wiki/Periodic_ ... conditions, which is tough unknown-to-me math for this case. but would look like it's one way to go to make a good approximation of general train flow from a detailed description of the behavior of 1 trains when changing blocks that is related to the first approach the cellular automaton one.

I think the second approach is what we are currently using, all of us on this thread, density and mean velocity to make up for the precise description of the behavior of a single train overtime like the in the first approach.

Also at this point i have to admit i'm more interested in the endless rabbit hole discussion than in the answer or the solution, the worst math i feel comes from the "certainly" in your sentence x)

Not in 3D not even in 2D but in 1D a train to me is like a particle that has a % of probability of being "accelerating or "decelerating" when there is a repeating speed variation with periodicity oscillating between 2 value of speed ( 0 and max in extreme stop and go traffic around a loop). And this is correlated to its current state, it is more likely to accelerate when slow and vice versa. The better its braking power/acceleration ratio the more it would change the shape of the braking profile toward brake for small time, accelerate for longer to achieve a periodic variation between 0 and max speed as in stop and go traffic. Following that trend of thought it would be possible to estimate the optimal speed a train should go based on its acceleration and braking capacity so that it minimizes the effective distance it occupies when maintaing a certain speed given its length and braking distance relative to its density of cargo. But also to predict where you would see a train and how fast it would go if you were to take pictures at random interval over the same rail boundary. And roughly the badness of the traffic jam and potentially how to measure the flow by measuring how much time a train is staying still in a stop and go traffic.

It ressemble what i can picture as necessary to model uneven signal spacing, or speed variation, or traffic jams which to me is the all the same roughly at first, until you consider the positions as signals can't move backward when speed is reduced or none so traffic jams are really the worst to model.

But the models https://www.youtube.com/watch?v=Q78Kb4uLAdA and experiments https://www.youtube.com/watch?v=7wm-pZp_mi0 are quite fun to look at and very explicitly ressemble factorio's traffic jams

[mmmPI]

New graph with more bells and whistles.

While experimenting with signal spacing i have been able to achieve a higher throughput than the supposed maximum in game with a lower speed than the model predicted with a signal spacing of 35 or 34 or even 33 32... I think it shows there is some (very little) inaccuracies that i can't figure out.

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

According to this setting, the max throughput is 25.242 train per minutes achieved with a speed of 233.24 km/h per trains. 1-5 nuclear fuel train, with 2 braking reseach multiplier, and 35 signal spacing. Going down to 34 or 33 or even 32 to make up for the little inaccuracies of my setup related to curve block measuring not an exact number of tile still shows something not corresponding to the following save game :

throughput excess.png (441.3 KiB) Viewed 3026 times

Too much throughput for signal spacing according to model.zip

(1.33 MiB) Downloaded 45 times

The counter counts 25.83 trains and flickers to 25.80 per minutes, the average speed is at 214.94 km/h. However in game a train can be seen changing from around 207 to 221 km, or so 7km/h fluctuation around mean leading the train to sometimes decelerates because of the front train preventing reservation sometimes accelerating which leads to wildly different measure on the lua command but maybe something else too.

0eNrtXV1u48gZvMqCj4HksP+7DSQve4Mgb8HAkGXaJiCRBkU5O1n4ADlILpaThJRtSSabVBVHO/ZkPA8D2KZKza6vuptff+z6PblebbOHKi/q5PL3JF+WxSa5/MfvySa/Kxar9nf114csuUzyOlsns6RYrNufqkW+Sp5mSV7cZL8ll+LpyyzJijqv8+z587sfvl4V2/V1VjUX7D+53FaP2c18BzBLHspN85myaL+owfFpOku+JpdzlTbgN3mVLZ//ap9mPUy5x9zUDdzdfT2Ial5QxVtUGUFVOKrDUTWOGnBUA6MKgaNaHFXhqA5HJdjyOCrBVsBRCbZECsNKgi4hcFiCL4HLSxKECVxfkmBM4AKTDGW4whRDGS4xxVCGa0wxlOEiUwxluMoUQZnEVaYJyiSuMk1QJnGVaYIyiatME5RJXGWaoQxXmWEow1VmGMpwlRmGMlxlhqHsoLLloror5/9c3DXX9kGtuBBGKq3ccaPLKm8AF88XphctU3nx2PyqrJpriu1qFVtC4RI0RJgoXIKWCBOFS9ASYaIU2vH+fB2P69MyS2Jcn5YITYXr0zJhguvTMWHiQT6dOR+f+BTpiNDUuD4dESYa16djHp0k2PFenq3jNT5/OiI0Na5PT4SmxvXpmTDB9emZMHEon+F8fOKTq2dCE9enZx7rcX0GIkzMQZ+rclmuyzp/zGKYFu33Oltv2k8V2+UqW1Tz2222akatp9iX47NsIGLU4EINRIwaXKiBiBeDCzUw8QILNaRMvDgclqHM47AMZQGHJSizKQ5LUGbhuTJQqTuJwxKUWYXDEpRZjcMylBkclqEMVxmTvrO4ypj0ncVVxqTvLK4yJn3ncJUx6TuHq4xJ3zlcZUz6zuEqY9J3DlcZk75zuMqY9J3DVcak7xyuMiZ953CVMek7h6uMSd95XGVM+s7jKmPSdx5XGZO+87jKmPSdx1XGpO88rjImleZxlTGpNI+rjEmleVxlTFrL4ypj0loBVxmT1gq4ypi0VsBVxqSYAq4yJsUUcJUxKaZgsPKE0I5JsfIEFQOFNeZenyGlewvrYrDuTRHG/KVQI1JIoC5eelaGC3O6nCIcVNY2t5hv6vJhpJhChk7Hzpr7fMkPJC6JfUMAm64813SRpljbX5cMo233SfQrBNh4p9jGS6zxDun4EG+8whofUrrnNdT4/VPsaONFGm+9AVuvx7p+lizLoq7K1dV1dr94zMuq/dgyr5bbvL5arspNdvVa9XS7WG2y2f6PVba42f+trrZZmw5bFHfZVbmtH7b1VbxaqmnAXZVlxYmrnnYtK54busunifa/3UePa6nym7Yv7KFZu188fXl6inbaYfhZVHl9v87qfDlfluvrvFjUzc0PL1Gl73aejHfeAfiq+fNNvr+B27zaRO73Ma/q7Y6514Fxd8W8ym7aztpkLUoL1YREW5A2b4KmfMiq1/j4U/PJob4cxSb72Bx16O43bVaj2+uzRLYQLX4XIHZ5nCRHk2TSdyIpWyzv4ywpm6btCPytVP3KEiXsgYcBKj3KhOeZkB+OCWFEh4c/T+DhGX+IiljAd7tZ9gTkejzMhihzPNaYGCMhMPTVwg+GR+DDw3+88HgPjfpTGm1DFtLoUQElSoJNPzU60M19XQVco4HHGp0wU/irZToYHgJbir4+GY4uReMr0aOi2PGVqGPX0XhdbHjdbO8+LYoorsYebV37aL1D1QjqYUV+ky3zm6wCV5YOlOEL6lmWlQfttVFWrh8W1a6Zl8lfp64nW5yHr03rtkV9dVuV66u8aFCeHw6oidN2hTSsOTsoqZHVUVwph2eDdXaTb9fzbNW0tmpG04dylUXTzBdvKSRW073p+sTiWrbNbhqYNSK4LrdV+0JJM43MhLJfonfjuGDcr9u+azD+bTwU/zJtLj5bIIpTqy5iGRVbdI8N/g6d/z0btsZMD9tTS9o0MsX1w9bOmhlrJnQaD93Ahe5+OfMZusNrjf5iBF9dxNaiY6EbwNA9eisBDF2rJofuyZWetENDrNbROJUCTZD7/SoiinNYP+3vPyuy6u7rPC/qrLpdLLORjTjZD/rr7e1tE9+b/F/ZLg/8+i/67Yc1VpH/lmfzenudzTfrxSq+8bUnwJAENO0cigM9sQmabYIbbIKhmiCn94KKx120UZZqlOo3ajiz+zr0TRj5fn078s2l0E57Zdt60jdj4H///R8ykSvTXu/00o4SHl7cRE71D9t9utdZg8mbo1druOD6cXvHdXtHpZFFdrSz+EyXfSvGD5BkUX90gmWg20/mo9syM0jRKp1Ogwb3vv54Guy3Jxyn8NC+0tUN9lFahseOo5fOYB7cR5ODFm2p7XswIQPJRJe6YYHI6cR8GIHY3r7Z9xqqugPRaWLQLP3xi49QxlHYt2ToKKqevJ0tws+9na24zWuFbl6riUlg4T+TwG97XMNJ4O6lvWSqOy3kwYcw9Q1p4RdSp0dlL0mhHJhfG8itqem1Fd99xPiAtRXq9FoWra1Q02srPhAT77Vvq04lohW+b6scjzU6V+CbAnpw31aFafs333ce+eBJcHUqCU5Qpbj9G4VmqXQ6ff+Gn19OyUYLZH7ZbTsO5sW1mFwW9JFGtneYXnbDwej0otEnQS0nlwV9Ti+9bu7rROFjvOCxxkaWSAgMfrUeDA81bY/1c3oZIa7PLEGV5IJAoeOAnr7HSk8vp2UTYvPJSC2ANuQeazdvYqKoFjttJXh34Z1Iw/7UD2EuvJd+ty3VPf0jdSI4ZWWQzXwmze4/EYwS2HEs4ugMmCn7wN07J/eBtZ+2CSssGSRmcM17dHIMtSV1aMKPtiWlext2prcDatDdkaMTcqj9TppB7eO6jjZKTN6yeWnXz7tztuvV0eWgQZeDZvrGwMeh4f12bAy7MWDQ8j0zsfxGsIUnZrD8xuiJw+4PW2ZiekUlxoKVAGZiodAP3Fm9iiUz+Fhh7PTR3vzsG/TGsYPMMA9u+nBvPveBDVsqYdAXkPFz3vbnHwgFPNEcHfSGeUmI9PSpCuLonDfsCIguavycd4E+fakL6UNqX8/iEumFT71pn8b6T1+NGqS3xnkZnG3WwkZISzx8EYfEvb5q1CVGRXEVfTJFc5sG6UbNHU0hRE/Whze7bPTNLmvosynQxlvubIrRxpt44x19NgXaeM+dTTHaeB1vfKDPpgAb71LubIrRxqto4x34ziFErox/haRPv4j0z//H6RdwbcrRWXrQu6CjvIg4L5p+FxSNW0M7GwUE1tLWRhCso72NIFhPmxtBsAE7BFnYC/UyAR/AO/OwI89AFvgBfHtrJeSe8AP49t5KEKykzZUgWEW7K0GwGjxWXCqQ2dMrKfx0vr2jE3QrlnZ0gmAd7egEwaLGCCo9X8cH2kUKuZWQ0i5SEKygXaQgWEm7SEGwqHGJcqf5BB9J8HP99s5V0K0Y2rkKgrW0cxUEixojaH02IQVPu2VBtxJot6yAWHultFsWBCtotywIFjUuMeJcfMpU0Q5d0K1o2qELgjW0QxcEa2mHLgjW0Q5dEKyn3bIg2EC7ZSGwhImlJSgjTCwtQRlhYmkJyggTS0tQRphYOoYyQ7tIQbCWdpGCYB3tIgXBetrRCYINtKMTAkuYWHqCMsLE0hOUESaWnqCMMLH0BGWEiWVgKDO0wREEa2mDIwjW0QZHEKynDY4g2EAbHCGwKqUNjiBYQRscQbCSNjiCYBVtcATBatrgCII1tMERBGtpgyMI1tEGRxCspw2OINhAGxwhsDqlDY4gWEEbHEGwkjY4gmAVbXAEwWra4AiCNbTBEQRraYMjCNbRBkcQrKcNjiDYQBscIbAmpQ2OIFhBGxxBsJI2OIJgFW1wBMFq2uAIgjXQVlT7EpzTNj3rVpQkPCOZ1AvhGcmkXgjPSCb1QnhGMqmX41qi0aofK08zi2XQJWEoyaR7iFohJt1DGEoy6R6r0Y4P5+t4Q7tIQbdiaRcpCNbRLlIQrKddpCDYAPLpbMOnFIdE00WauvirS80ELJvnVBOcTpvhqglF4dVL7h2gm3CqZLJehFPlYNbryyzZLO+zm+0q2+wqZw6zSvtzMzW11Q/NtHN04e667qnn3cqXboVStyiqW+HVLVfr1t51baK61ktdN6O3BkFf2hvd1Q5dJterbfZQ5UXd9NNqcd1Od8nfy/KX9XZ5/0t9X5Xbu/v2fcdZ8phVm+d+8kK7Zu3um+d0Y+TT0/8AFPiPiQ==

Copy blueprint

I have not been able to explain it so far, despite my attempts at adding an equivalent of the math for block length under several forms to represent the discontinuities as described by SoShootMe or other number of formula to represent the fact that trains occupies an amount of space that is modulo or not the size of block, or that they occupy 1 minimum, but need at least always a second to enter to. This by changing the formula for q(y) in this graph https://www.desmos.com/calculator/cbacif3nds

Currently showing [floor((Length of train + braking distance + speed in tile -1 )/size of block)+2]*block length. So that a train is counted to take at least 2 blocks all the time even in case of small train, but this is not correct for small trains in long blocks which may explain the underestimation of the max throughput. I have tried many things there x).

i had this realization that in the extreme case of a small train and very long block. It is only possible to know how many time a trains occupies 2 block by knowing its speed. But this will have to lead to density variation because most of the time a train will occupy 1 block, but sometimes 2 blocks. With the approach we are following so far it seem to me impossible to make up for this fact precisely. And the other approach used in real life looks quite complex, if anyone has an idea or is able to share some informations that would be appreciated

[quyxkh]

Anything up to about 1-14 rocket-fueled trains can reach the game's speed limit of 1.38m/tick, you're showing 1-5 trains stuck at around 1m/tick. So they're hitting congestion, they're braking. Trains brake faster than they accelerate, and that sort of speed variation makes traffic effectively occupy more space. Much more space. If you want maximum throughput, build trains whose maximum throughput *at their full speed* is highest, and dispatch them so they only have to brake at their destination stop or at another controlled-dispatch station, or send their drivers here to LA where we'll teach them how to avoid and (less intuitively) kill standing-wave traffic jams. Sadly that skill was clearly lost in some pre-game apocalypse, so long trains it is.

[mmmPI]

Anything up to about 1-14 rocket-fueled trains can reach the game's speed limit of 1.38m/tick, you're showing 1-5 trains stuck at around 1m/tick. So they're hitting congestion, they're braking. Trains brake faster than they accelerate, and that sort of speed variation makes traffic effectively occupy more space. Much more space. If you want maximum throughput, build trains whose maximum throughput *at their full speed* is highest, and dispatch them so they only have to brake at their destination stop or at another controlled-dispatch station, or send their drivers here to LA where we'll teach them how to avoid and (less intuitively) kill standing-wave traffic jams. Sadly that skill was clearly lost in some pre-game apocalypse, so long trains it is.

In order to get the max theorical throughput you would also have to place signal everywhere , which is good to know for certain portions of tracks but you wouldn't want to do that on everysingle track of your network.

My previous post was regarding the influence of signal spacing over throughput, i know 35 tile away signal is not optimal for throughput so is 1-5 trains, or their speed, but i thought it would allow to see wether farcast model could be improved by SoShootMe remark regarding the space in number of block a train is considered to be occupying.

The modulo block length rounded up thing. I tried a situation where there should be a descrepancy between a model that doesn't math block length at all and a model that does, which is the case, farcast model is not suprisingly closer than a model who think block length is 1, but it's still off, surprisingly, it's slightly underestimating the throughput.

Or more visible, there is a 10km/h descrepancy between the supposed optimal speed for those trains, and the speed at which they are running in game to provide a throughput supposed to be "optimal", my trains run 10 to 12 km/h slower than expected, and yet achieve a tiny little fraction of excess throughput.

Adding the limitations that makes the curves look like discontinuous to math the block length when thinking about it more makes it to me obvious that is not going to yield proper result without math like integral and probabilities which are not used at all atm. Because if the trains slows down and accelerate a little, one need to know how much distance was travelled during one or the other phase, and when it started, the distance travelled is integral math, and the "when it started" i'm not sure.

I am not sure what should be achieved with trains achieving their max throughput at their max speed ? If they "never" have to break, then they will always reach that speed no matter the signal placement and there should be no descrepancies expected. I need to try with more than 1 train on the loop right ? otherwise it doesn't matter if there is some wasted space for density there is no impact if there is no need for braking. How many of those trains should i put on the loop ? 1 ? signal placement no impact, 2 ? they may start to brake, or if they don't no impact ?

I'm testing with 1-32 trains atm

Edit : i can confirm if trains don't need to brake, there is no need to math block length, the result of throughput is the same as with block length 1, but then if trains need to brake the proposed way of modelizing the interaction of block length and throughput are not properly modelizing what is happening in game, although one can get very close

Taking the case of 2x 1-32 trains on a 188 rail long loop signaled very 35 signal and 1 block for the U turn since it's around 35 tile, this time farcast model overestimate the throughput in trains per minutes https://www.desmos.com/calculator/79v5xlzmbm , at 11 instead of the measured 9.91 in game, that my model that doesn't account for signal spacing correctly predict for 2 trains : https://www.desmos.com/calculator/sbkbs30tix , the purple curve at 2 trains says 9.946

9.91.png (242.25 KiB) Viewed 2992 times

0eNrtXVtuHEmSvEt9LsjaiPB4uAuYBWbnBvu7aAgUmVIXQFYJxaJ2ehs6wB5kL7Yn2cySWEwyX2bZiWaxpfloDMViVKSbWzwszSN+X324fag+7zfbw+rd76vN9W57v3r3n7+v7jeftle3zb8dfvtcrd6tNofqbnWx2l7dNT/trza3q68Xq832pvrn6p3/+svFqtoeNodN9e3vjz/89n77cPeh2tcfOP3l9dX+0+7yv64+7bZ1c5939/Xf1P+3/qK6nWRlHbIl8SFdrH5bvbsMtk4xWNaS6q/b7Td1w1ff/sKtfU7mXDTNQbPPIuJc0ePfbrZf6k/u9nUb24fb268XnS6Fpy497L9UN5fHZ+rpkn7ribi6AzebfXX97be5p03BHjM7WZuU748ovvtk2CPE09fdH+ref/r1MPAQ9Re2vqv1EKGn1YS3mvBWM95qwVstYMC9WyTgij+E4Q9hcKve4616hzdLZId/ovLt7np3tztsvlR9bRYk4vWgct/8xfbh+ra62l9+fKjqQUe+9n1xwJ+HyEsveLNEYnqcm55IFY+TMzC5grMzMLlS8GYZyHAaBgYynIeBgCzgPBQCsuDxZgnIAs4yISALOMuEgCzgLBMGMpxlkYEMZ1lkIMNZFhnIcJZFBjKcZZGATHCWJQIywVmWCMgEZ1kiIBOcZYmATHCWJQYynGWZgQxnWWYgw1mWGchwlmUGMpxlmYAs4iwrBGQRZ1khIIs4ywoBWcRZVgjIIs6ywkCGs0wZyHCWKQMZzjJlIMNZpgxkOMuUgCzhLDMCsoSzzBi5AGeZEZAlnGVGQJZwlhkDGcyy4hjIMt4sA1nBm2UgU7xZBjLDmyUgyzDLCiO7ZI83S0CWA94so8oJ3iwBWY54swxkOMsY9SPjLGPUj4yzjFE/Ms4yRv3IOMsY9aPgLGPUj4KzjFE/Cs4yRv0oOMsY9aPgLGPUj4KzjFE/Cs4yRv0oOMsY9aPgLGPUj4KzjFE/FGcZo34ozjJG/VCcZYz6oTjLGPVDcZYx6ofiLGPUD8VZxqgfirOMUT8UZxmjfijOMkb9MJxljPphOMsY9cNwljHqh+EsY9QPw1nGqB+Gs4xRPwxnGaN+GM4yRv0wnGWM+mE4yxj1wzucZka9D8d5xugf3uFEYwQQ73CmMQqIdzjVjMItYWYMdbJ23hevY/aAAhkyvIOZqI5KloK3SyWL4u1SyWJg8L1bLvi4xUQZwcd7j7fLZChuIVHKaYN7SJSz2kQU1LIgqAl/GCZDcY+JUkYb3GSilNOm5TIZD36ICwYfnlOV8vfgJhSlDD64C0Uphw9uQ1HK4hNAh6aKXw5U3KWijLTmcZuKCpUsOFOFSpaCBl8XDD4+4QqVoThTGU3P40YWZUQ9jztZlFH1fMvKMg5qTMuBihtdlNESPe500Uh5THGmRipZMhj8FBYMPj7hRipDcaYmKkNxpjIqpsfNMMrImD56FFRbDlTcK6OJskHjTGXUU4+7ZZSRT31EN7E5Lxh8fMLNVIbiTM1UhuJMzVSy4EzNlGnegaCWBZUJ3G6jjFrscb+NMnKxxw03yujFPqGbWF1QmcD9OMqo1B435GihMhRnqlLJgjNVqWRB5SZdUJnAHTvKyOMet+woo4973LOjlECe0U2sLahM4JYepVR53NOjlCqPm3qUUuVxV49SqnwG5SZzCyoTuOlHqVcBuOvHKFUet/0YpcqXgAZ/QWUCdwUZ9SoAtwUZpcrjviCjVHncGGSUKl9Aucn8gsoE7hsy6lUAbhwySpXHnUNGqfIKbmItIMoEVp3tcWORUa8CcGeRUao8bi0ySpXHvUXG1d1mFFRbENSCPwyVoThTKVUeNx8ZpcobuIk1ycsFH/cmGfUqADcnGaXK4+4ko1R53J5klCpvoNxkURYEFZ9wqVcBuH3JKFUe9y8ZpcobuIm15BYLfsDdTUaVVePuJovU6QU4UxlVPuDuJmNU+eAiCmpZEFR8wmVeBQTc3WSJShacqYlKFnQTm+OCwccn3EwdsIEzlVHlA+5uMkaVD7i7yRhVPnhQbrLilwMVPz/HmFcBAXc3WaGSBWdqoZIF3cQWXTsn5p5O0nHr4099EJSooeTiXfIupMe/QmDBp+JC5S7OYUavDy3f0+gpb9ZsHftOeZPeVtHNrca1uJhPhAi6jjlqlL7T7CTX472mLNmshBDsCU8AGdwxlR71zlCeP2vpbVeeHfp3+f1gwJ4Tz/y6dWbf9Fl5oWWLajq8vbw/7D6PnF0X7AXgF/WTfo/e6u+r3q9IYOcljnT+YnW92x72u9v3H6pfr75sdvvmz643++uHzeH99e3uvnr/eF7ix6vb++ri9Mt9dXVz+t1h/1A1qF9tP1Xvdw+Hzw+H9/3nLNYd+LSvqu3Ep74ee7b91tHjOWq++c/xT9unMG5umnN30lO3mn/wX3/5+rU3aBnD5XEDNYrLv/fjUkBcsrJJpVjnHwf3OUllWOeLC2TnW96vsc6fivJnRL5lAxvvvGS28wHr/OP+eEbkBRyLSnFs57Gx6FSANSfy4FikLrKdxwh78uDPiTxI2Ma6SXYeI+zJlDgn8iBhG/sH1/mIEfZp/ucjH0HCNq+myM5jhD29dJkR+Zb7a/Qr4vzRuGUEG49PlL/8FB/RKb7lcrvabw6/3lWHzfXl9e7uw2Z7Va8zR5S1egmbOiD1Be+p4ff1r282pwf4uNnf9zzvl83+8HBE7nEZe/zE5b66aYJ1XzWtNE3VGdGcVn1Z58zuc7V/TI9/qf9yKJajbZMxjq2AHv8l9UT9YhWaJpr2XzaQYJAyDVJjdHsVkKqr61/7UZLsXKN5/lGo/sEClfITDgNQFhSJwiMRzg4Jn/wLHP51Bg7f2h+Coi/hX4Y5dAjUxeFiCLLMtzVGxoh/ddLB9FA+PfT80uM1OKqTHDWUo0aDkN1Pjg6EucsrwzmqfFujHMW/Oruh9EjYSv2kLs5Y7CZ0pV7YlTpu+TYd0PZ8b7uCXssR1jH6+CQuh7gurrmloytjOpVcgqWUJQRXB7SoBCforRxtu/j4vRyPM2xEnvRpwXtTXW9uqj242i3g0PC91UWWuk/jgWt+uPt8tT92893q3+aucZt2Pv9W9+5he3j/cb+7e7/Z1q1827BQA0V6Se7hcWB4XTyyYutn79NS+K662TzcXVa3dW/39Qj/eXdb9b47Xz+HkFjh55f9nljwh6bbdQermpgfdg/75gacemq7EOd+6X2awiXjaS35pybjf4yn4t/mrQ8WS8Q0taoklnaRWzQmdN/Qqr4A0zal+Wk7GRDt6XYnbfNFPYvWqRv7U9e41D0tsX6m7vD6p4sUsdji1lIJXU63am3A1M0yP3WnAlKGh1jtzdNWSc/Ee189rSJ62wnsruJ0mVK9RDqTXUXuCDDLbyr6gW3c5S9nytElQGOkwfJTeGDSuQHTvLj5o3vuObA0Wc3BMrgya5WFbTf/3FSXh4cP1eX93dVt/w1a6+cgjKrujzGfEfJ/PJ8BLoOPJdYbk+Mc2J4L/u9//pcU2XN6OTqNRCdR0cl/gejEwVhkKhb6F4iFTExrI8F62iKc5t1qW+0//Xa52R6q/cer62rkFrWXe+I69B8ePn6s11X3m/+ujmcsPv6v99t1zrefrK2hO7xS325Eolh+sh0lctlRBmeXVv0i14XIdkEGu+CpLoTZUcjWv9rq7VSgOiXdTr05DrtOdDp6QEHf6LUqPjlM3+wQWLrhGxzzSpyZXG83OtKJTu6RlnqDxb/Bz8/JeAbr3/A6u5Iyud4tqMJT8nwYIuhC+ctuQ4qS25CRsYN/Q/9YA3E+dNBj8dKrIJFYJBQliM4H5mwI8noCSiksMBkFBi1+VF3L6QXeEZewtlJvbXtrS2K0rN6L1H+gMTmrH0GiYKcnhNZpBLTcJueSLa9H4+bQBU7XCWC2tI5zoOW2swHmlZYbml+u8pSd+F7qqMM4hZlynJC7Ru0sXXVwclaZqYLJW13Y6+C6XeNMFewtx+KiQ4ih6CTUkOLXorlValpHymmy3sK6ekYqUjS6nELMSQk3irLGg3b6epZTfsJ4oBEZSTrvycxdiOTe92TKWRFycM+ebXpQ/xHe5+rUm3dV+H1uz0fH3ucqulFVeh3+hLU7lwn81eyROmVpVNxs0v3oy7ZscHWA9G3sq7srEY/mj/H5E84vf17B42xucnWHbqaNNWXkEOfPRjaRpxaAuaeeQIPFev7p92m0zpfC5h/9Of90M8xPjE4W4CGi56Njg4+h44fxRpoT1j/nny7VLiZxGER4apVpQs0/THIN2vONt/PI+S1PXq3WzeLUHGOo0tM66Q6cYyTMnmNMpnIxgfub2G+1Ns73nyW9xvzyBnz/lmHff+gYpCyTlQA2qCVZ5geK9EoDxZlVLhtXpwyfF9M69hGr2PH5OQyxt1WdXaLu7ccuUTfOE26oJ9xsXhGV159FVM8jrvBgajo+Q8qkmUHc0KpLnJtfVvUd1PlZ+XINK85j9SkDtSni/OzzEv70EeP81pDf0mQ8kcA1pLgw+7yEM0LilTZ7nTB3iSLojqvDKaStkbmiLwUGvzoOpofMq3/8c+eR8xZ9OsB1kSWgClwSCDoOxPn1j+z8AtAmIfPLsWx3qK5MXJp91Mc5jWyvMb3Eyeklo2mVZx/18XN66YS5y5OCDxyJb2t0ZMn4V+tgepR5Nco/p5cR4LrIElBlLgkKOg7o/BplfnqZoo2XvvlkuJZeWufWYzXKL3WT1Neqd7iv0yVX9OTr9Hn9aNbsemhSjtE58SloLNzR1NI68H5OOdnLx+bKycSHebVcjZGHyhA/uOD1Mq+y5akLb8z01YzOF53ovPwXUGAUH+eVTfEIDpC6t1PzC3C+9+uHLcD5FtXRtaBH14I+z64vOB8YXs0x3uHgpJgo6N4PvbgiWVzrs/oCH9YhZtfv5dTis6WSsvkQ6pEhJtTLKV5nFxf49MOf5SHeyFQJDk0Vmw9M/OGrPiSQVR9HIkDABDe76uN8GPNK1Y2dKE/zJQ/iML/65nwI8kprDXnpeZXIAuMN5UuYV+ji3+rxCBIG18dB5lUiveFYdHYPI4yOMzMlvtnopMFYpJmZQh62IqGzBQ1lsFMzTyt601S+GF/AhcFglZnBesvZfNGZZ4aio3/oLCef/shZThJmnqbkyXOERAanRXEz5a83yyXp2HQkgFySmec+veGBxzrBGnQsSZivuqUf/LyVjnYzLfYM4yDzZbf0wx/r0ZE3p5FArVcS6WtAvQCvlVq3102YfB9fVrnpy0VF/kB5tQ/s8m+i8KVZDQJbxb4St4HyNpGZ5dXfn+1nedvN9yCOvnmNcAVs30fHXkUL+ipadH5lJp3IcaIyU5KbTtuGeyOVMyI2rzLzZ+q282fK85wcnLo9Hx1NXVS0im5+wRefulN+1ASYwBu2Bes3VUQ/r+Drz03b869RkBTQGoXOR6fKu+qUG0zGQN7X/nKZEXpbFdQTI+ucwvfzyo7N+7VLxwvcu68icyyW699KTYjkioQYvp1HA7yLjJG+0enlMk162wUP0KmXvmu1p/ucbB1Eg/Ze6FSyeZ98NKt3fCGY6eOV9siDZvr6eN+p0+sHtXDXx3vf4ffEjV4S5x+a4v2PXrQuU/fA9a2uhoYYmTg0RSJ1aAqzZOy+QAoenVrnH5pyTvnzCm5x0ck5BH2Jndzskyd+krhnK3Exuc4cZNLkvsVTJCYWzzLoFk9+9skTZ5Qer1Y1GCerBhNqA0phdmn/n47EeVV8d7ZVXWbJxHyITmmtK0PH13OSR9ZzE+8pbnf31SleH69u76un3u2rq5vT75pNTbNevdp+qt4PxXlzqO4asI6hm/gUFfWEirKtO01Hl6rNADm5VP1771K1dcHp6Fdkm70aTuhSvrBL+YQt5YtL8+OjWOeLy2znDeu8zI986zK+8c5HNvKte/JGO19kduRbV+iNd74ktvMCdV5dmR/5iHVenbGdxwirzcg8N/IgYTUK23mMsE+n886IPEhYLYXtPEZYc/NH4wIS1jxL2IIR1uJ81aOAhLWY/upTPHw2jhTh7pefk1SRvl8eTaqEqpEnNc2QZjMqRpb1s8O8rUeExOTG1j0wk0+SiCdRvNlCNGt4s4Y327pFY6pZ74lmPQinj0vB2brOYPJJiMRsXUgw2SyRJRrxZoksQQ/Fz8EvFveMPwmTmDg7A5OYODsDkyU4OwORJeZQOHUpOFunLE8+CZGYhrMzEFliODuFyJLWwabjcZe0WNzxeVWIxDScncIkJs5OYbIEZ6cwWQLeX5VjWAjO6PB5NeKJGR3OzihEszg7YyKaFTTutljc8Xk1FuJJcHZGI5rF2ZmYLMHZmZgsURDOlBeDE59XE5GYHmdnIrLE4+xMRJa0TiUZj3uWybhj9e/R4/NqJhLT4+zMRGJ6nJ2ZyRKcnZnJEvC0g1zcYnDi82pmEhNnZyGyJODsLESWBHRPWspScQ/4vFqIxAw4OwuRmAFnZyGyJODsVCZLUMVI42Jw4vOqMomJs1OZLMHZqUSWCLonNb9U3AWfV5VITMHZaURiCs5OI7IEr9bJRmSJoIqR6WJw4vOqMYmJs9OYLIHZWRyTJeCetLi0VNyjw5+ESMzo8WaJxIwBb5bIkih4s0SWRFAxKj4sBic8rxZCuo8x480yWVLwZpksUTTutljcDX8SIjETzk5CR48JZyeho8eEs5PQ0WMCFaMS8lJwpog/CZGYCWdnYLIEZ2dgsgTckxZZTGJI+LwqTGLi7CR09JhxdhI6esw4OwkdPWZQMSpxMYkh4/MqId3HjLOT0dEzzk5GR88ZjftiEkPG51VGus84OxkdPePsZHT0grOT0dELqBiVtJjEUPB5lZHuC85ORkcvODsZHb2Ae9KSF5MYCj6vMtI97jEqjI6Oe4wKo6PjHqPC6OjqUDgXkxgUn1cZ6R73GBVGR8c9RoXR0RXdk5bFJAbF51VGusc9RoXR0XGPUWF0dNxjVBgdHfcYFUZHN3zuZERt3EdUGFEb9xEVRtTGfUSFUZgNnx8ZhRn3ChVGYca9QoVRmHGvUGHkXtwrVBi512CWKSH3JtwPpIT2mnA/kBLaa8L9QEpor8kJ3qwRzcIsU89AlvBmGcgy3iwDWcGbZSBTvFkGMpxlhCqZcF+PEqpkwn09SkiEyeMsIyTChHt3lJAIE+7dUWEgw1kmDGQ4y4SBDGeZMJDhLBMGMpxlhHiWcH+OEuJZCjjLCCUr4R4cJZSshHtwlFCyEu7B0cRAhrMsMZDhLEsMZDjLEgMZzrLEQIazjNB4kuAsIzSehHtplNB4Eu6lUUJwSbiXRgnBJeFeGi0MZDjLCgMZzrLCQIazrDCQ4SwrDGQ4ywj1I+GeGCXUj4R7YpRQPxLuiVFC/Ui4J0YJ9SPhBxeqMZDhLDMGMpxlxkCGs8wYyHCWGQMZzDJj1A/c22KM+oF7W4xRP3BvizHqRxK8WQIy3L9ijPqB+1eMUT9w/4ox6kcqeLMMZIo3y0CGs4xRP3CPijHqB+5RMUb9yDjLGPUD96EYo37gPhRj1A/ch2KM+pFxljHqB+41MUb9wL0mxqgfuNfEGPUD95oYo34UnGWM+oH7SYxRP3A/iTHqB+4nMUb9wM+sMUb9wD0jxqgfuGfEGPUD94wYo360PCO3u+vd3e6w+VL1X9U1XRB8qO6OpyxtH65vq6v95ceH6rb53r4vxk+uMUZ2wZ0jxsguuHPEGNlF0dPqi1svUI+d8GNrjJF5cNuIMTIPbhsxRubBbSPGyDyqKJalxlKSnW4esLUL5XgTQQ+wseSsMSbvnQTvYjT46oGEW06MUZ5wy4kNKk+/XKzur3+tbh5uq/vjUWxPo0/zc73VqYem1oeOn3l5bNqz4+1+ado8nvv2bvXh9qH6vN9sD3WXbq8+NKPQyl9KqH/8Uu3vv/VBfSz12lSD+HrP+PXr/wO5c+Mr

Copy blueprint

[mrvn]

Anything up to about 1-14 rocket-fueled trains can reach the game's speed limit of 1.38m/tick, you're showing 1-5 trains stuck at around 1m/tick. So they're hitting congestion, they're braking. Trains brake faster than they accelerate, and that sort of speed variation makes traffic effectively occupy more space. Much more space. If you want maximum throughput, build trains whose maximum throughput *at their full speed* is highest, and dispatch them so they only have to brake at their destination stop or at another controlled-dispatch station, or send their drivers here to LA where we'll teach them how to avoid and (less intuitively) kill standing-wave traffic jams. Sadly that skill was clearly lost in some pre-game apocalypse, so long trains it is.

Those long trains are really slow to accelerate and take forever to get up to speed. Total killer when they hit a junction and have to wait.

[mmmPI]

Those long trains are really slow to accelerate and take forever to get up to speed. Total killer when they hit a junction and have to wait.

I made this one => https://www.desmos.com/calculator/mmalpgpa8o

It should model how the train accelerate in game, for what i've tested it shows the correct speed of accelerating train over time and the max speed it will reach.

It uses geometric series math, but i'm not sure how it's called in english, one can change the 0.0075 in the air resist upper fraction to 0.01 to represent a forward facing wagon, otherwise it's just forward facing loco and number of wagons fuel.

[quyxkh]

Those long trains are really slow to accelerate and take forever to get up to speed. Total killer when they hit a junction and have to wait.

Yes, but you gave the parameters: train length, acceleration and braking, and signal spacing, in the first post. Congestion and route length are pretty obviously important, so I took their exclusion as intentional. Kinda feeling jerked around here.

[mmmPI]

Yes, but you gave the parameters: train length, acceleration and braking, and signal spacing, in the first post. Congestion and route length are pretty obviously important, so I took their exclusion as intentional. Kinda feeling jerked around here.

The maximum throughput is indeed achieved with long trains you are correct ! to me it seem to be always achieved when you use the maximum number of wagon before the train isn't able to move them at the max speed. If you use 2 nuclear fueled loco, this means the optimal number of wagon is 77 per train for around 500 wagon per minutes throughput (predicted) but those trains would take more than 10 minutes to reach their max speed.

If you use trains with 20 locos and 77 wagons, the max throughput in theory is only 477 wagons per minutes. But the trains reach their max speed in less than 6 second.

Instead with 20 locos the optimal number of wagon seem to be 960 which would yield a thoughput of 650 wagons per minutes. Which at this point you may realize a minute is too short for the train to move all its wagon accross a certain point.

Surprisingly it is possible to achieve better throughput with only 16 locos and 760 wagons, for 677 wagons per minutes but that's only in theory because those would need around an hour to reach their top speed.

If you use 250 locos and 8000 wagons, the trains would reach top speed in around 10 seconds for a max throughput of 686 wagon per minutes. But only 200 locos and you get a better theoric throughput.

I was wrong when i said removing locos always gives better throughput, that is the case for given number of wagon, if you remove locos and can still move the trains to the optimal speed, the best throughput will be achieved when there is no "needless" locos which are just wasted density of cargo when the train is already at max speed.

So there is a tradeoff, the longer it takes to accelerate the wagons, ""the better"" for theoric throughput, because that means one is using just the right amount of locos and not too many to achieve the best density when max speed is finally reached ( even if takes hours ).

I think those trains are not made to be used in junctions though, it would take a while for a 250-8000 trains to clear a junction with 680 wagons per minute only. That's 1.3M ore per minutes, for a total of 16 M ore in the train. The train would be around 115k rails long which is more than i use in many games to make a full network lol.

[quyxkh]

Max throughput on a single line over a given distance seems like the figure of merit to me, I don't see any reason to include congestion because whatever the shortest inter-congestion distance is will have at most the congestion-free throughput for that distance, so that will be the best possible throughput for the entire route. With rocket fuel a 1-4 train takes almost a full km to hit top speed but hey, the farther out you go for ore the less often you have to redo your outposts, so… sure, a 1km multilane acceleration buffer feeding 9km of single lane 1-4s at about 125 wagons/min, 2-8s would at least double that, if you smelt at the outpost end you should "easily" pump over a million plates per minute over a single line.

[mmmPI]

Max throughput on a single line over a given distance seems like the figure of merit to me, I don't see any reason to include congestion because whatever the shortest inter-congestion distance is will have at most the congestion-free throughput for that distance, so that will be the best possible throughput for the entire route.

That's a way to see, i agree that the throughput of a lane is limited by the segment that has the lowest throughput. it makes it easier or even possible at all to average the flow of a traffic jam when it's happening on a loop. In a game you can also have some grid-like network and wish to math the max throughput of a block egde, whose signaling is going to be always the same. Or a tree-like one , where knowing the throughput of the trunk signaled more heavily compared to the branches could help.

Bridges are supposed to get rid of any congestion anyway

Also in real life "free flow" is used to describe the state when cars don't have to slow down due the car in front of them and can reach easily max speed, it is usually the prefered configuration, because in real life "synchronized flow" is more a self-regulating mechanism than an objective, it happens when density of car increase, then they have to slow down a little and if it's not critical density , it improves the flow because the braking distance increase with the square of the velocity so the overall multiplication density*speed= flow increase as density increase more than speed decrease due to density including a part of velocity squared so that it returns to "free flow" "hopefully".

The trains all have the same behavior regarding reaction time, so it's a little bit better than human drivers and they can really achieve wonders during synchronized flow but when density increases a tad more it breaks into traffic jam, which is bad, though the best throughput is achieved just before, which makes it very prone to disruptions. The critical density of rolling stock/rails is one that doesn't work well because the effective density in game depends on factor like speed and block length.

With rocket fuel a 1-4 train takes almost a full km to hit top speed but hey, the farther out you go for ore the less often you have to redo your outposts, so… sure, a 1km multilane acceleration buffer feeding 9km of single lane 1-4s at about 125 wagons/min, 2-8s would at least double that, if you smelt at the outpost end you should "easily" pump over a million plates per minute over a single line.

Well to me, wether you use rocket fuel wood or nuclear fuel doesn't matter because 1-4 trains are the best for throughput going at around 158km/h when you have 2 as braking research multiplier because i suppose that's when their braking distance is the closer to 35 tiles which is the length of the train. You can achieve at least 145 wagons per minutes !

Max from model is expected at 151.518 wagons/minutes, but that would require a very precise loop length so that it fits better the number of trains than 7 trains on a 106 rails long loop. ( should be 7.034 trains ).To double that you'd need at least a 2-15, a 1-15 would not do with rocket fuel but with nuclear fuel it could reach the speed required. A 2-8 could only get you as far as 214 wagons per minutes, but 250 wagons per minutes would be required for at least a million plate per minute which is in theory possible with only 2 rails lanes using 1-4 trains, but as you see in practice it wouldn't quite fit with the loop design.

145.png (231.52 KiB) Viewed 2763 times

2 decimals digits for all three counters

0eNrtndtuG8nVhd+Fl4GkdJ2rDCQ3eYPcBoZAS22bAEUKPDjjDPwAeZD/xf4nSbdsi22yyP4WyWQ8QeZiAFrkrsPaqw6rdtX+dfJuvm2fV7PFZvLm18nsYblYT9787dfJevZhMZ33/7b5/NxO3kxmm/ZpcjNZTJ/6T6vpbD75cjOZLR7bXyZvzJe3N5N2sZltZu3X3798+Hy/2D69a1fdF15/+bBdfWofb18M3Eyel+vuN8tFX1BnJ+bmZvJ58ubWNLGz/jhbtQ9f/9x9PDBqd0anqw/L279PP3RfrRg1d02TsrHh1fids/3nrozlataZnX79fnNnSnEuR+OLb6J3zjTBx5xC39RP3ReXq87CYjufV+rjaH3SXS4+uEGF0mFNLCrTv5a53nR9+uHj5mjX/lDYoGttxWzgZpNgNnKzRTCbsNliBLMZ4ln89fAsvClOaIppuF3FT4zhdhVHMTtuz5cPy6flZvapPTSaGoO7vhu/1v3PFtuHeTtd3b7ftvO+8FrpjrdK8VOD2do1TLEbuF3JayK3K3lN4nYlr8ncroQbZmUyCm624XYV3KzhdhXcrOV2Fdys43YV3Cznm5Vw43yzEm6cb1bCjfPNSrhxvlkJN843p+DmON+cgpvjfHMKbo7zzSm4Oc43p+DmON+8hFtgK7Hkw13jggnxCisxx8noJWfhZPSSs3AyeslZCuz8YK/X+Z4z1Sse6jlTg+KhnjM1KM7iOVOD4izeU1DLFUHl02ZQPNRzpgbJWThTo+QscGOZYrxi5/M5NSoeGjhTo6RAcKZGxVkCZ2pUnCU4tmNNDmMq7FgDn3mT4qqBUzZJXsMpmySv4ZRNktfwyTVJXsNZmRXcImdlVnCLnJWS3hg5KzXBkc+fkuIYOd8kyTFyvkn6X+R8k/S/yPkm6X+R801S4CLmW5YUuNRwuwpuyXC7Cm7JcrsKbslxu5LCj/mWJQUuwZ1lNuHO5HT5MixF3hDJURK3KzlK5nYlR4G7ymztdTo+c4ZKGmPmDJU0xswZKmmMmTNU0hizp4CWKwEaeEMUz8ycoZKomTlDJVEzw91kdvFKHc/nUElFLZyhkopaOEMlFbVwhkoqamE7yewdwlPYRRY+y0r6beFUlaTUwqkqSamFU1WSUgufTCVVs3BGSqqmaTglgxaOwDkp6Zqm4aSUNEbT8HlTEhlNw0kXNfA466IGHqdd1MDjvIsaeJx4UQOPM0/S3QwP2MmS8GZ4xE5OWiQQZ54kvRkejZMl7c0YumTN7i5ZG6+iwxserJOz5jKclllzGU7LrLkMp2XWXIbuLktzRWR5OE+WxEbD43mypDYaHtCTtXBD6ygA6S6msBecG2PzckBSQSIlb7JxMZQYU6GRuYZHAmUt/nEQCnQysrk0xyKbXdVshLGnKdwFU34IgLR3tvPravd1o3/xqViXSzfRxVyKN76J1L95nO1uhHc/tjZVDecfAstvvwWfV6KC3d1rM7uGj4eIm0Eo0YjpoJoeRBONmE6yaUNNF9m0haaLkU07alqGcRBZNGJahzFQ0zqMkZrWYUzMdB8hrZrO1LQOY6GmZRh9Q03LMHpDTcswesjGZGQYvaOmZRi9p6Z1GAM1rcMYqWkdRspGq8NI2Wh1GCkbrQxjoGy0MoyBstHKMAbKRifDGCgbnQxjoGx0OoyUjU6HkbLR6TBSNnodRspGr8NI2ehlGCNlo5dhjJSNXoYxUjYGGcZI2RhkGCNlY9BhpGwMOoyUjUGHkbIx6jBSNkYdRsrGKMOYKBujDGOibIwyjImyMckwJsrGJMOYKBuTDiNlY9JhpGxMOoyUjVmHkbJRV3ESZaOu4mTKRl3FyZSNuoqTKRt1FSdTNuoqTqZs1FWcTNmoqziZslFXcTJkY9ZVnJypaR3GQk3LMJaGmpZhLIaalmEskI1ZV3GKo6ZlGIunpnUYAzWtwxipaR1GykZdxSmUjbqKUygbZRXHNpSNsopjG8pGWcWxDWWjrOLYhrJRVnFsQ9nodBgpG50OI2Wj02GkbPQ6jJSNXoeRslFWcayhbJRVHGsoG2UVxxrKRlnFsYayUVZxrKFsDDqMlI2nVZybycNysVkt5/fv2o/TT7Plqv/dw2z1sJ1t7h/my3V7//0Rt/fT+bq9ef3jqp0+vv5ts9q2fZzAdPGhvV9uN8/bzX398beuAh9WbbsY+daXl5otvlb0JfLY9P97+enwabjZY98ZcVet/h/Ml7dfvlR7bTfQTFezzcendjN7uH1YPr2bLaabrvGnwjD9fu/Zeu/tLN93f36cvbbg/Wy1rjT402y12b5g9z0s4uUbt6v2se+tddtb6U2tN9P+gb3bjmbL53b1LR5j8oful8c686RtsZPDoEdf/qU/Zdvv9puJ7U309vcN1L5eR4mO2UEfR+iYHfVxpMi+1au8v41vtdOHj3XncrFp+hXbpR72F9W/fNy5T/0bfQAbciBL5zhZ0bWDIDqMcvz5UDbB7GH8xzMw/mr/GMy1MWAfQnswpqQDjG+ODUhFt3VqfKq417GifT7qenShIiv+1tKFiqz4W0sXKrLibwehjZQw/SHBT0eY32JEzKMjYqIjIt1hyecudhDPiQH2/xsRj0F4OIoVPCzZoNs6OSLywTg0R12PLrmSPhnTbbJ8LmdpWG6Wz+UsDcvN8rmcpWG5WT6XszQsN8vncpaG5easw0i3yVmHkQ6pWYeRboCKDiNlY9Fh3LGxj+tf3K43y+eTVyMOx/7191sGk+mk+hQrpWWJavUH8bknL0uU/qir23q63cU2d+d89/HwpoRL0TZdXUzTlJJKN6M3+B14y18DLLvXYPYuSpiqYQff0d/N0w0xS6PrU74bdN0eNqFqekfjx/Zh9tiuqGjj4ALjm9mrKDa7VUXTf3h6nq5e6vlm8udzpZrezvPnrnbbxeb+/Wr5dD9bdFa+Cm/KcmNfKrMn9lfx6GLhxA6+ugYYBE0/tY+z7dNtO+9qu+oWis/LeTuiv3zFUFCqDlY5I8KV7evd1bDtOPZuuV31ySc6rr6tNiVprrjb/f9HXfGvpx3xT+ftX67mhn5s1Stsxmuy0CkZku6ZBjHz1GnL+U47qozYmnx64LTxpluK1x23aI67G/z/57jHd1CHMPE9k9X0qdrmreq4g2sT0HGHmxjZcceoHEp9eL2xxVc9ld7NKI05sZBIVdOWXrSNu6VP1RC9pZgGC1GDFjuDmxivuLWLdvXh8+1ssWlX76cP7cknJ8wBW99t37/viLme/aN9eY/l+3/V4ndrrcXsl1l7u9m+a2/XT9P52M66ET0nHFVRB9c6xDoYsQ6x2XfXPgyL0SxJlUyVjjp+8vp9CD1jBP3LjyPorTU++exiP5/9MJb+/z//Tzxo7RDb661oKkupam9lqbfif0NvHZyYhnS0e8q5zmR+t91zQL1DMkZKxsHlJNG91BEjxPoEV62Vflq4e3ymgdEa/3ZtvFe6Lj38OC2MHxmb3eHYcnIDepxeg1tgOhDmZzmkSP/uA4oj3VrGOr4PZGA0dTIOu+eLfhpCxIMIif8UFPsdPUqJSGMmBjcOdWR+Gob40h9l/yaDlVWRcRSZ3YJ80/6yeZ5PN99mttsPy/njyBFMjTSfOhy+9Y+tSrmDi5xnFGlGiqwnLUtykQG3sroXHNz7pCV6XKLJ1SLLJY0c6VdXzdnWXNLIMSSrG8jB9VFaZML9Wj26GdwqpSXGy3xncNn0jDaOdKupN9Jf0sixIqvDQNJHnsIZUu/YeEmR5hxSJnnkKQ1uZb1EeeQZHvSeR8pySSPNGRTJ8shThGmr2sgsjzzF8iLruSvtJa0c89eqPpjlsafwmbI+EGR57Cl8qqzOWzlc0sizBtgcL2nkWQNs1ocePnEdaaU+9qQLl3a5XNLKsSKr7lP0wSdfNtwVfGhxiv9107p4kb+9E9q36ifZmf0227IwequgHFXvYAqF0sS7ZJpdQFBHmCPxQD5lk0zHwRKTcV3lsvsWSKQkWLCDO9fyAV9PrYPDuCNHxvQCdtld0X8xX7UVxaCjYn90XF+1mugx3OtQXQ7CweqW83lHUN/M//70eNccDeEtZx5O/G774uAQcP9Q+3hnuebMk4jfcWeVgzPUfLR3dHHAHGfu+ELSNbo20NACbaiW6M4Xz8ZKrG6aXaNLA5aWWKoFhvN1rNFONdUS4/k61minxmqJ6XyJZ7TEXC0xn699jPZqUy1R1yMzLbHqqaY5X/kY7dQqG405f4N+nuMYe74KMVpilRzmAkVg1HFstcQLBIHREqvjuAnnbyLPc9UohortL1jr7pjkuLFysM+vd1CWN6CHluvuVeSMDbmAvhhc0z69Jfi+m81xfLfsrJGvIeSMethaMUvHfn2rVKLXegfRjof1reLG05W8XiDZx63eD0FOtJHjgQ5RtRzRFaL4PUFQTge03t0gejepFkEJuDs9oZXH+UeyapmmH9lp9tAyzj6ym6KoZUrD3cRALePcIyqCPPWIiiC94pgaGUH6ZGUjI0hfrGxkBHHaERlBnHVERpA+HmtUBHHOEaMiiFOOGBVBnnFERZAnHFERxPlGrIwg5aCVEaQctDKCONmIjCDONSIjSDnoVARxphGnIogTjTgVQZ5nREWQpxlREcRZRryMIOWglxGkHPQygjjFiIwgzjAiI0g5GFQEcX6RoCKI04sEFUGeXURFkCcXURHEuUWijCDlYJQRpByMMoI4sYiMIM4rIiNIOZhUBHFWkaQiiJOKJBVBnlNERZCnFFERxBlFsowg5WCWEaQczDKCOJ2IjCDOJiIjSDkoazI4l4isyeBUIrImwzOJqAjyRCIqgjSPSJY1GZpGJMuaDM0ikmVNhicRkRHEOURkBOn7b7ImgzOIyJoMTiAiazI8f4iKIE8foiKIs4fImgxOHiJrMjh3iKzJ8NQhMoI4c4iMIOWgqsl4nDdE1WQ8ThuiajKeZw2JqmWcNCSrlikHvYwg5aCXEaQc9DKCOGGIjCDOFyIjSDmoajIeZwtRNRmPk4WomoznuUJUBHmqEBVBnCkkyghSDkYZQcrBKCNIORhlBHH+BxlB/BaxiiDOZqBqMt7il4hVBPEz+Kom4/Er+Kom4/Ej+FlGEL9CLCOIHyGWEaQczDKClINZRpByUNVkPH4OXNVkPH4NXNVkPH4MXNVk/CBOZiwg8DVSC9n13G5S7AZutyh2I7ZbjGI3cbtOsZu5XQk3HiBaFNwGkTGjdhXcBnExpy729SFTrw92vxrfu9KnXt7z/Fnv1ChO4x23qziN99yu4jSDoJmT762npkAURp9U9z7ytkiOmrhdyVExYZORfKVwu4qvDMJoTmNq4tUwHQTYjLZF8c/AeWoUXwmcp0bxlUFozem+t+56fY8n1mQV/wycp1byT85TK/kK56mVfKVATF1zNUxjw9ui+GfkPHWKr0TOU6f4SuQ8dYqvRD6fOsVXIueik3DjXPQSbpyLXsKNc9FLuPE50yu4Jc43r+CWON+CglvifAsKbonzLSi4Jc63IOHG+RYk3DjfooQb51uUcON8ixJunG9RwW0QXnNy85fMnS22XHn3lzkro+I1mbMyKV6TOSuT4jWZrlZTpjCML20yp2xSXDVzyibJVTllk+QsnLJZcha6XM3heqAWPn9mxUMLZ6okchbOVEnkHATpnO78Yq/Y+XxylZTVwpkqKauFM1VSVgtnqqSsDuJ2RkAtAFQLQeUzryLnhoYzVZFzQ4OZmhVFNTSW23WKXcftBsWu53Yl3AK3K+GGyZiNhFvidiXcMrcr4Va4XQU303C7Cm6G801R/YLhfFNUv2A43xTVLxjONyvhxvlmJdw435yEG+ebk3DjfHMSbpxvigIXLNtZ9tGOJqYr7yyD5axU9L9gOSsV/S9YzkpF/wv81Zus6H/BwvPK7AuFd3QpFiynrJdclVPWS87CKRskZ4E7yz6m82qd7/j8qSidwXGmKkpncJypitIZeLhPVpTO4KAGlKO7Iqh8clXk1cBjgXKUnIUzNUrOAneWfbzq9Tqfz7yKpht4oFBWVNXgOVMVVTXwGKCsqKqBxwBlReAMPAYoJwk3TsYk4cbJmCXcOBmzhBufNrOEG+ebojWGwPmmyH6Bx/JkRfYLPJYnK7Jf4LE8+bjs9/Zmsn742D5u5+365W3t3eah/9ztirtiumr1+Qj60MX+BKvbawx+9vKr3cOH05eHD394CPFtX0q/neg/zrft82q22HS1/NSu1l+rkY1PxaZuZ2267vry5V8UzYk1

Copy blueprint

I have not been able to make the integrals for acceleration to compute the speed from the physical /second units due to not knowing how to model the drag that's not in equations i could find online that's why i instead tried to model how it behave in game tick per tick but maybe i will have more chance making the integrals of the speed computed this way to find the distance travelled during the acceleration to 158 km/h depending on which fuel is used, so that one can build curvy loops to buffer speed at first and remove/straigthen tracks later when changing for better fuel in game ? At this point the math are complex and precise enough that i feel it requires being used for something more fancy than just maximizing throughput. Things like flying trains or signaless networks

[quyxkh]

I might be in the minority here but for me, before first launch rail line throughput just isn't a factor at all. I do the first few launches with 1-3 ore trains feeding what gets built up to a ~25k/min smelter complex, for a rail line that's *nothing*.

[mmmPI]

I'm pretty sure anyone reading this discussion is already in a very tiny minority, i won't blame you for that I had tried on several occasion to bring water to nuclear plant with trains, or bring steam to turbines, or other silly things like that, which require a lot of throughput and had issues / tried to optimize.

I usually do my smelting on site and not on centralized smelters to avoid carrying ore by train and such kind of considerations so i hardly even experience throughput issues in real game.

Most of the time it comes from junctions too close to each other leading to long chain of chain signals but the math for those are much harder than the math for throughput which are not easy already ... maybe eventually who knows as i said i'm more interested in the discussion tha in the actual "solution" for best throughput, having a tool that can help mathing things out precisely can be helpful when building contraptions with signals networks too, knowing how many tick a train would need to clear a block of very small length can be used to act as trigger or measure.

I play many modded games where i don't do many launches but just try new systems, so throughput is not as much as concern as the precise math

[farcast]

New graph 2, Electric Boogaloo

New graph, new model, this time including acceleration.

Velocity formula comes from something I did a while ago, I messed around with regressions to find a good formula for train velocity until I got something that was suspiciously perfect. I later looked up formulas for linear drag models and what I found was actually the right formula to use, and the proof was one of those black magic proofs that separates dy/dx. I can't find which page I found it on now. It's similar enough to what mmmPI shared. What I'm trying to say is don't ask me how the formula works 'cause I don't know.

Initial conditions are as follows:
-Train speed is at its minimum (x)
-Stop point is at a signal
-The block in front has just opened up
-Identical trains are packed as close as can be for the minimum speed

The graph calculates the time it takes for the train to speed up until it hits the next signal, then slow down until it reaches the minimum speed. At that time the next block should open up and the cycle repeats. From this time the average speed is calculated, and then throughput comes from the time it takes to travel to the starting position of the train in front (train length + minimum braking distance + signal block length).

Whether or not block length evenly divides train length + braking distance, I don't think it matters. It should just affect whether train acceleration cycles are in phase or out of phase... did that make sense? I hope it did.

The new model gives significantly different results for low starting speeds, but the difference between the new and old models disappears as signal block length approaches zero. I think that's a good sign. Another good sign is this matches mmmPI's 1-5 train test result.

I had to use newton's method to find the travel time, and I can't think of a way to directly calculate max throughput from this, so you just have to get by without it.

Lower starting speeds might need a different S_0 for newton's method to get an accurate result.

Edit: fixed the graph so it doesn't completely break when a train can't reach the game's max speed.

[mmmPI]

New graph 2, Electric Boogaloo

New graph, new model, this time including acceleration.

Velocity formula comes from something I did a while ago, I messed around with regressions to find a good formula for train velocity until I got something that was suspiciously perfect. I later looked up formulas for linear drag models and what I found was actually the right formula to use, and the proof was one of those black magic proofs that separates dy/dx. I can't find which page I found it on now. It's similar enough to what mmmPI shared. What I'm trying to say is don't ask me how the formula works 'cause I don't know.

As far as i'm concerned this look more complicated than what i did, and also than what i attempted . I will look at the "linear drag model" online because that's what i couldn't do. I can try to explain what i did because I figure i would probably not be able to understand the graph i made in a few month, and i don't know how long are Desmos graph available , i think i know why the formula worked, and hopefully there is enough similarities that it could be helpful to understand your graph but i'm not seeing them yet

1) How to make a model for the train speed over time in tick (easier method with working example ) https://www.desmos.com/calculator/sd5of8hkgr :

Long

I went to the wiki and grabbed those formulas that describe the game code run each tick to update train speed :

Code: Select all

train_speed = max(0, abs(train_speed) - train_friction_force ÷ train_weight)
train_speed = train_speed + (10 × number_of_locomotives_in_moving_direction × fuel_acceleration_bonus ÷ train_weight)
train_speed = train_speed × (1 - air_resistance_of_front_rolling_stock ÷ (train_weight ÷ 1000))

Looking at this formulas, one can see 3 operation in sequence,
1) the train speed is decreased due to friction ( subtraction)
2) the train speed is increased based on the number of locomotives and trains fuel ( addition )
3) the train speed is multiplied by a number between 0 and 1 to represent the air resistance ( multiplication )

Then one can combine the operation 1) and 2) into a "flat" part that is added every tick, and deal with operation 3) as a multiplication.

This is akin to an arithmetico-geometric serie where each "(Un+1)" term is defined by "a*(Un)+b". Where adding "b" represent operation 1) and 2) combined, and multiplying with "a" represent operation 3).

In Desmos i defined 3 parts, one for each operation roughly.

1) Friction = ((number of rolling stock)*0.5)/mass of train
because the wiki state :
Where train_friction_force is the total friction of each wagon and locomotive (0.5 for any type of wagon including locomotives)

2) TrainAcceleration =( 10 * number of locomotive * fuel acceleration bonus)/mass of train - Friction
That's the second lane of the wiki, combined with the first one, to get the "flat" b part in the "a*(Un) + b" serie.

3) Rresist = 1 - {0.0075}/ (m/1000)
Where 0.0075 is the air resistance of the front rolling stock, it would be 0.01 for a front facing wagon.

So from this point the serie can be expressed as ((Un+1)) = (Un)*Rresist + Acceleration, where Acceleration is "b" and Rresist is "a". in a nice and clean => ((Un+1)) = a(Un)+ b where (Un+1) meaning the following term compared to (Un) which is the nth term or the speed reach at tick n.

That is not what is required to make a (cool) graph on Desmos though, because that is giving the next value based on the previous one not based on some "time" factor, which would be instead the rank of (Un) in the serie so the number "n". The "speed" at time 170 tick, is the 170'th term of the serie. And Desmos only allow 10000 elements in such serie not-cool.
So it would be nice to have a way to calculate the (Un) term based on its rank "n" which hopefully exist and i found in late highschool math program but that sounded like a good hischool unlike what the latest graph from farcast is about which is too complicated for high school i think

The method require first require to find the maximum of the serie, what is the value of the (nth) term so that the value of "(Un+1) = (Un) " that is in normal langage, the speed at which the train will not gain any more speed , the "max speed" , but in math langage considering "(Un+1)=a(Un)+b" it also means finding "n" so that "(Un)=a(Un)+b". I can't find the precise name of this number in english in the wikipedia pages, i called it the "Reason" but later realized it's not how it's called, it's more like the 'fix point" sorry for the confusion x).

This number , the maximum speed, can found by solving the equation if "(Un)=a(Un)+b" or giving to wolfram alpha in case, one can find the form MAX = -b/(a-1)" which is also MAX = b/ (1-a)". Which considering trains value means that "the max speed" is equal to TrainAcceleration as computed in 2) divided by 1 minus Rresist

Max speed = TrainAcceleration /(1-Rresist).
(called Rreason by mistake in my graph)
Rreason = b/(1-a)

(note that acceleration is noted "b" in the rest of this post, and Rresist "a" which may be confusing i'm sorry)

At this point everything is explained on the graph except for the last formula :

S(x)=(Rresist ^x)(0-Rreason)+Rreason

The 216 multiplication is just to transform tile/tick in km/h


We're doing some progress because then it's only a matter of using a "known" formula whose demonstration is adapted from textbook :

coming from Un+1 = a*Un+b, the definition,
and knowing Rreason = a*(Rreason +b )
We can write
Un+1 - Rreason = a*Un+b - Rreason
Un+1 – Rreason = a*Un+b – (a*Rreason + b)
Un+1 – Rreason = a*Un+b – a*Rreason – b
Un+1 – Rreason = a*Un – a*Rreason
Un+1 – Rreason = a (Un – Rreason)

At this point we can pre-emptively create Vn as a serie, and define it will be equal to Vn=(Un-Rreason).
If we do that we can try to look at Vn+1, it would be Un+1-Rreason. Oh wait, but that's also a(Un-Rreason).
Therefore Vn+1=a(Un-Rreason) and Vn=(Un-Rreason). So to go from Vn to Vn+1, the only operation is multiply by "a", this is the definition of the geometric serie, Vn is one, and the ratio of the serie is "a"

This leads to the following : Vn+1=a(Vn)

but from previously we also know Un+1-Rreason = a(Vn)

Now the good thing is geometric series are """easy""" to use; if Vn+1=a(Vn), that means you start with a number V0 that you multiply by "a" a number of time "n", because V1=a(v0) and V2=a(v1) and V3=a(v2) and so on if you try to replace things V3 can be expressed in function of V0 and a, that's V3=a(a(a(V0))) if we calculate this, (V0*a)*a*a or v0*a^3, so V3 is V0*a^3, guess what is v4 , v0*a^4, v12 ? v0*a^12 so Vn = (a^n)*v0

Therefore :
Vn = (a^n)*v0

But also since we defined it this way
Vn=(Un-Rreason)
thus v0 = u0 – Rreason
and Un = Vn + Rreason

which leads to
Un = ((a^n)*V0) + Rreason
Un = (a^n) (u0 – Rreason) + Rreason

And this is the final form of this math, we can now use this as a function and not as serie, because that's f(x)=a^x(0-Rreason) +Rreason or rather
S(x)=(Rresist ^x)(0-Rreason)+Rreason since we defined a as the Rresist.

2) What i attempted to do before but it didnt work and i think that's what farcast did properly x) :

shorter

acceleration = thrust / mass

Acceleration is in m/s²
Thrust in Newton, which is kg m /s²
mass in kg

But then what to do with the drag i thought ? I went back to your other post

Drag with a forward facing locomotive in front: 450 Newtons per (meter per second)

the 450 unit is kg per second i thought (kg m /s²)/(m/s)

I tried modelizing this, to represent the acceleration in function of time. And then i wanted to take the integral of that to know the speed. But i couldn't find how to combine the drag in the equations as you cannot just add some kg and some kg/s, so i tried multiplying the 450 by one variable supposed to represent time so it would only be kg to add with the mass of the train, and the integrals looked good, but it was not the correct speed in game, tried different things to see if there was some 2 factor or squared or conversion unit missing, but nope.

In the end i found it easier to work with the 0.0075 air resist to model the train behavior rather than the 450 drag but i will look at linear drag model.

The graph calculates the time it takes for the train to speed up until it hits the next signal, then slow down until it reaches the minimum speed. At that time the next block should open up and the cycle repeats. From this time the average speed is calculated, and then throughput comes from the time it takes to travel to the starting position of the train in front (train length + minimum braking distance + signal block length).

Whether or not block length evenly divides train length + braking distance, I don't think it matters. It should just affect whether train acceleration cycles are in phase or out of phase... did that make sense? I hope it did.

The description of what the graph does seems clear, but i'm not sure i understand why you made it do that, and i'm no way near capable of telling if it actually does /checking for mistakes in the math .It will take quite some time to think if it's covering properly what happens in game from thought experiment and testing in game loops :p. And even longer to try and understand the math used to represent what you describe that is supposed to be what is happening in the game.

I'm not sure why the "at this time the next block should open up and the cycle repeats". I still think it may matter the block length dividing or not evenly the train length+braking distance in such case, maybe as a "worse" division would means a longer time for the train to wait before being able to re-accelerate.

To my intuition the block length modulo or not the train length +braking distance, may/might act somewhat similarly as difference in reaction time of drivers as if some trains re-accelerate when the train front of them has just started , or sometimes leaving a long time = distance gap . Not sure the analogy is correct there.

I think there is a set of equations that can predict the flow on a loop on which occurs a certain traffic jam because it will be periodic, i think it will have to do with modeling the behavior of 1 train and the density of that one train over time considering its velocity impact its braking distance and also its position impact the amount of block it occupy.

I was watching the loop of train for a long time thinking, if that one train is stuck at 0 velocity in between 2 blocks, it's not the same as if the same train is stuck at 0 velocity inside 1 single block in both case the braking distance is temporarily 0, but the effective amount of space occupied by the train goes from simple to double, in case of block sized like the train. Now if you look at the loop for hours, ( and log the train velocity ) it occurs that the same pattern repeated after 16 occurences of velocity 0. Which makes me think that this is where the modulo block length modulo loop length lies.

If the loop is a certain size, it means the traffic jam will propagate at a certain speed reverse to the flow and as such trains will periodicly come to a velocity 0 at the exact same position relative to the loop. Sometimes the traffic jam will do a lap of loop, and immobilize train slightly in a different position due to the speed at which it propagate not being a modulo necessarily with the speed at which the trains run so this leads to different kind of traffic jam/loop relation, in the case i observed it was requiring 16 times for the train to stop so that it would have the same exact pattern of deceleration. I suppose that value "16" could be mathed out related to the speed of the traffic jam propagation and the length of the loop. The speed of the traffic jam propagation sounds like the "delay" between 2 trains following the same braking/acceleration pattern due to stop and go traffic but this number used to divide the difference between the position of the 2 trains when it occurs. If you have 100 trains 1 meter apart that start accelerating 1 second apart from each other, it will look like 1sec of time happens and 1m further something happens, so that's 1m/s wave propagation.

And then you get the question of position of train relative to the block it occupies and block length, because in factorio train are not points 1 meter apart, so their length increase the speed of propagation of the wave, also if there is lots of empty room behind a train in a single block, but if the train is slow to accelerate and clear its own length, it takes more time for the following train to start moving , which lower the speed of propagation of the traffic jam. As such i think longer block length would impact the cycle of braking acceleration, them being out of phase is one thing, them looking different / different time accelerating braking or starting at different speed, would be more problematic to calculate density from the behavior of a single train.

At this point the model you are making that is on a straight line, is not going to yield the same results as one that tries to math out the resonance between the loop length and the traffic jam.

I had to use newton's method to find the travel time, and I can't think of a way to directly calculate max throughput from this, so you just have to get by without it.

I don't understand this, isn't your graph showing the max throughput ? I don't see what i do have to get by without. It seemed to me you detailed earlier how you did calculate max throughput. Was it only "some predicted throughput" considering the interaction with block length ? And there is still a way missing to know what is the optimal parameter for block length to maximize the new way you calculated "some predicted throughput" ? to me it seem like clicking on the graph shows the maximum throughput that's enough to make tests

Although i'm not sure what it means to calculate the maximum flow of a "traffic jam", the minimum throughput makes sense to me. It would represent a traffic jam so bad only 1 train can move at a time and the flow would be the acceleration inversely proportionnal to the number of train factored by their length. I suppose the "maximum" would be something like only 1 vehicule being impacted by the traffic jam otherwise there would be no traffic jam at all and considering this is the segment of a network where there would be the lowest throughput, on a loop , there couldn't be an average higher than the throughput occuring due to that specific interaction at that specific location but then there's a whole range of possible intermediate throughput when there is 2 or 3 or 5 or 12 trains that are experiencing the "stop" phase of the "stop and go" at the same time. This is also part of why i said earlier than the models may give different results.

On a straight line, it may be possible to calculate how much time a traffic jam caused by 1 train running out of fuel for 10 second before manual refuel would need to disappear, or IF it will disappear, given a number of train per minutes piling up behind it. that would be pretty cool math. Going into looking at junctions, considering 1 train is blocking the path of another for x second is similar situation.

Having speed overtime and block length and train lengh allow to know when the last driver in the formula race starting grid will start moving by modelizing the increasing distance between the first and second car, and then second and third, and delaying the acceleration of the second car when the first one has clear "block length" no ?

Then it is also possible to know if that amount of time is more or less than the time the lane was stopped due to junction, and thus the number of trains that piled up behind the first one, and thus the rank of the last driver ? which keeps increasing as long as there is at least 1 standing vehicule.

There is plenty of experimental data on junction throughput waiting for someone to corellate throughput and some value to help people designing them


Edit: actually i may have spotted something, i think there is a "k" factor missing in the vmax or the V0(max), as it doesn't show properly the correct speed cap when set in km/h i think it is stuck at showing 82.8 when it should be multiplied by 3.6 to show in km/h

[mrvn]

Max throughput on a single line over a given distance seems like the figure of merit to me, I don't see any reason to include congestion because whatever the shortest inter-congestion distance is will have at most the congestion-free throughput for that distance, so that will be the best possible throughput for the entire route. With rocket fuel a 1-4 train takes almost a full km to hit top speed but hey, the farther out you go for ore the less often you have to redo your outposts, so… sure, a 1km multilane acceleration buffer feeding 9km of single lane 1-4s at about 125 wagons/min, 2-8s would at least double that, if you smelt at the outpost end you should "easily" pump over a million plates per minute over a single line.

But why would you want full speed? Staying below full speed gives you a higher throughput (in many cases).

This also isn't about just plates. Ore and plates actually are the most boring part, just use bigger trains. They have so much throughput that it's worth it.

But consider all the other items you transport, especially with heavily modded games. And those items frequently become expensive and slow to produce. The more complex an item the more the amount condenses from the huge ore train down to even 1-1 trains. And soon you will have to transport that stuff to the spaceport to ship to another planet.

[quyxkh]

But why would you want full speed? Staying below full speed gives you a higher throughput (in many cases).

Because no matter what, whatever lower-than-full speed you like, you get not just a little better but massively better throughput with trains long enough that that *is* full speed.

consider all the other items you transport, especially with heavily modded games. And those items frequently become expensive and slow to produce. The more complex an item the more the amount condenses from the huge ore train down to even 1-1 trains. And soon you will have to transport that stuff to the spaceport to ship to another planet.

Seems to me if you're not shipping huge quantities you don't want rail at all, you want belts or bots. A sushi train… hunh. Is it insane to even wonder if there's a sane design using one?