Page 2 of 4
Re: Non-throughput-limited 8+ belt balancers?
Posted: Mon May 09, 2016 6:15 pm
by ribsngibs
Frightning wrote: If you math out the desired division of the input, you see that after the first splitter its:
1/2 1/2 1
After the second:
1/2 3/2 (!) 0
...
I admit I haven't done a careful proof yet, but I did actually consider the idea of splitting the lanes into more lanes, and the problem inevitably shows right back up when you try to recombine the lanes (you'll end up with two belts needing to combine to one but they have >1 belt's worth of combined throughput between them)
Hi - I'm a bit behind on this thread but I disagree with this analysis. The bottleneck only should only (theoretically) happen when there are intermediate belts along the way that want to have >1 belt throughput. If you put 2 full belts into your forbidden triangle, you indeed get 1/2 1/2 1, then 1/2 3/2(!) 0, then a failure to get to 1 1. However, if you put 2 belts at half capacity (1/2 1/2), instead you get 1/4 1/4 1/2, then 1/4 3/4 0, then 1/2 1/2, non of which is a bottleneck. If you do this side by side and then recombine the inputs, a splitter will have no problem taking a 1/2 and 1/2 and merging it into 1 full belt.
Indeed:
- dubthreesplit.gif (5.46 MiB) Viewed 11996 times
Similarly, splitting each input into 2 and sending one set of 8 to one 8 balancer and the other set to another 8 balancer, and then interleaving and recombining the outputs (output 1a and 1b > output 1, 2a and 2b > output 2). This shows that example (with only the first 4 belts hooked up because too lazy:
- dubeightsplitfull.gif (12.63 MiB) Viewed 11996 times
And I agree with the others that simply placing two 8 balancers in series would work, as there is only a bottleneck in going from, say 4 inputs to 4 outputs, but not from 4 to 8, and not from going from 8 to 4*:
- serieseight.gif (15.62 MiB) Viewed 11996 times
*- I did, actually, see some total throughput fails like the kind you saw. I believe sckuzzle is basically right - a splitter on a compressed belt will stabilize in putting all of one lane's items on one belt and all of the other lane's items on another belt, and sometimes a complicated series of belts can result in another pattern of 1/2 compressed but alternating items. Actually, in the image just above (the two 8 balancers in series image),if you look at the 4 belt segments just to the left of the player character, you can see those patterns - it starts with the 2 left belts with single lane items while the 2 right lanes have the alternating pattern, and then the 2 right ones somehow get "fixed" to the 2 single lane pattern.
The total throughput failures, I believe, are caused by the little hitches in the lane patterns (from left lane to right lane, or from left lane to alternating). If one were to split a single belt into two lanes, the two lanes will have perfectly complementary patterns (if the left belt has an alternating pattern, the right belt will have the exact opposite alternating pattern which will zipper right back with the left if combined again - if the left belt has items only on the left lane, then the right belt will have belts only on the right belt, which will also happily merge right back in if combined). However, in these balancers do not have equal path lengths for all belts. So if there is a hitch which changes the pattern (say, left belt from left lane only to right lane only), the other belt will also switch to the complementary pattern, but if the path lengths for the left and right belts are different, then the "left lane only pattern" on the left lane may collide with the "left lane only pattern" on the right lane. So I think the total throughput failure you see with 1/2 output is when two belts have items on the same lane, trying to merge into 1, and the failure you see with 3/4 output is when one belt with items on one side collides with a belt with items on alternating lanes..
e.g. the simplest case: one belt split into two, combined back into one works just fine obviously:
- simplegood.gif (3.44 MiB) Viewed 11996 times
but simply adding a little dog leg to one belt (just to make it longer), and removing a single item from the belt (to switch the patterns), will result in the patterns getting offset and result in throughput failure. Sorry, big gif ahead:
- simplebad.gif (14.26 MiB) Viewed 11996 times
Keep in mind that one does not actually need to supply a belt with errors in it - I have a video that shows a fully compressed belt which simply starts with a bit of a mistake (the first 5 items are a little funky), which results in a tiny bottleneck, which sends a shockwave down one lane, which switches the belt pattern, which later on causes another bottleneck, which sends another shockwave, switching the pattern again - so a single error may result in a perpetuating series of belt pattern switches. I can post this gif later if people are interested but I am late for work right now!
Re: Non-throughput-limited 8+ belt balancers?
Posted: Mon May 09, 2016 6:38 pm
by Frightning
ribsngibs wrote:
~snip~
Keep in mind that one does not actually need to supply a belt with errors in it - I have a video that shows a fully compressed belt which simply starts with a bit of a mistake (the first 5 items are a little funky), which results in a tiny bottleneck, which sends a shockwave down one lane, which switches the belt pattern, which later on causes another bottleneck, which sends another shockwave, switching the pattern again - so a single error may result in a perpetuating series of belt pattern switches. I can post this gif later if people are interested but I am late for work right now!
NICE WORK!
That gif w/ the swapped lanes shows something really interesting about splitters I didn't know: They will only move items to the
corresponding lane of the other belt.
The explains so much about the weirdness I was seeing, and why said weirdness was consistent across multiple trials: my start conditions were identical (I would just reload the save to run another trial), and if I didn't change the layout, then exactly the same things would happen for exactly the same reasons.
Re: Non-throughput-limited 8+ belt balancers?
Posted: Tue May 10, 2016 3:20 pm
by Shokubai
Frightning wrote:
That gif w/ the swapped lanes shows something really interesting about splitters I didn't know: They will only move items to the corresponding lane of the other belt.
The explains so much about the weirdness I was seeing, and why said weirdness was consistent across multiple trials: my start conditions were identical (I would just reload the save to run another trial), and if I didn't change the layout, then exactly the same things would happen for exactly the same reasons.
The effect is only true on fully compressed belts. Any gap in throughput will throw this off since it alternates items 1 for 1.
Re: Non-throughput-limited 8+ belt balancers?
Posted: Tue May 10, 2016 8:48 pm
by taiiat
sorry if i missed something as i only read the first page, and bit of the second, last page:
i'm far from an expert on this game - but what should help significantly is having Splitters which are faster than the Belts they are attached to.
this will reduce gaps in flow significantly. the Splitters are always the bottleneck, as they do something other than just move forwards, so if they are functionally faster than the belts they're connected to, they are no longer the bottleneck.
expanding the system larger and larger compensates for the bottleneck on each Splitter. eventually getting small enough where it doesn't leave an open gap as it creates less gap than one item worth of space.
alternatively extra Splitters can be placed inline between exchanges to compensate for the gaps created, by splitting the Belt back to itself. that's a bandaid ofcourse...
obviously if you're already using Tier III Belts this is defunct... honestly having a 'Rapid Splitter' that ran on Electricity, would be a late game way to sort and balance things at maximum rate.
but that doesn't solve things currently ofcourse.
- - - - -
additionally, Splitters don't actually move things evenly between belts, you'll notice depending on which side of the Belt it comes into the Splitter, as to where it'll come out of it.
so a belt trying to fully compress one resource must note that. you'll probably end up with self looping Splitters in some form to compensate for it.
that's all i can contribute to this, giant scale spiderweb belts aren't something i've needed to deal with just yet.
Re: Non-throughput-limited 8+ belt balancers?
Posted: Tue May 10, 2016 8:56 pm
by sckuzzle
Taiiat,
Splitters can't split more items than are coming in nor can they combine more items than there is space for on the output. Splitters are never a bottleneck so long as they have as many output slots as there are inputs (so long as they are the same color as the belts they are with).
Try making a balancer system with yellow belts and splitters, then upgrade the splitters to red. You'll notice that any bottlenecks that were there previously are still there.
Re: Non-throughput-limited 8+ belt balancers?
Posted: Mon Sep 19, 2016 8:58 pm
by hansinator
So did anyone find an answer to this topic?
Re: Non-throughput-limited 8+ belt balancers?
Posted: Mon Sep 19, 2016 11:35 pm
by ribsngibs
Yes...ish. It seemed like the easiest solution and definitely most straightforward is to simply place two NxN balancers in series. If you pass only A belts in and take only B belts out, the first balancer will spread the A belts onto N, and the second one will put the N belts onto the B you're drawing from. Should be no throughput issues. Aside from the weird left-right side belt weirdness that you can see on this page of discussion (which can affect even a very simple 1->2->1 belt pattern, so that problem is basically unsolvable imo.
Re: Non-throughput-limited 8+ belt balancers?
Posted: Thu Oct 20, 2016 11:12 am
by Frightning
So I got a pretty complete solution to the version of this problem I posted on math.stackexchange from one David Ketcheson, this solution ignores the 2-lane nature of belts and splitter memory, but models everything else. It shows that the classic 4x4 balancer is UTU without considering those effects (and in my tests, most of the oddities in throughput vanished eventually other than the rare spacing artifact that probably can be explained by the tick rate of the simulation and resulting rounding errors). He also gives 3x3 and 5x5 balancers that are UTU. Attached to his post is a link to a notebook he compiled while working on the problem, which contains algorithms that will iteratively test a given balancer for the UTU property.
Stack Exchange post:
http://math.stackexchange.com/questions ... 16#1950616
Notebook:
https://gist.github.com/ketch/b0e30aae8 ... 79d6b6ca5d
Unfortunately, he has not, as of yet, found an algorithm for producing UTU balancers, and I suspect it's not as straightforward as one might expect, based on what I understand of his solution and the example balancers he found that are UTU (note that the 5x5 UTU balancer he found may not be minimal in # of splitters used).
Re: Non-throughput-limited 8+ belt balancers?
Posted: Thu Oct 20, 2016 9:24 pm
by hansinator
He must be wrong. All the constructions the notebook says are UTU fail miserably when I test them.
Edit: And it is not because of the lanes of a belt. If I put lane rebalancers in between everywhere it fails, too. If you operate with one lane on all belts only, it will still fail.
Edit 2:
In the 4 lane balancer case it will work when there are lane balancers between input and exit splitters and if you make sure that it never reaches max compression on all belts. If you go from full flow of all 4 belts to 3 in 3 out it will fail.
I'm testing various configurations since weeks. You can get an UTU for any balancer if you put two in parallel and lance-balance the outputs. A series configuration will not work universally.
I suggest this lane balancer, it doesn't balance the output lanes but treats the inputs fair. A side-loading configuration does not work because it doesn't draw from input lanes equally.
This one also balances the output lanes but is only for one belt.
Re: Non-throughput-limited 8+ belt balancers?
Posted: Thu Oct 20, 2016 9:34 pm
by ribsngibs
I agree - it sounds like he is new to Factorio and may be solving a slightly different problem? I'm not sure. But for instance, his 3x3 balancer is indeed not throughput limited for any subset of active inputs and outputs (I think), but unfortunately it is not a balancer.
Re: Non-throughput-limited 8+ belt balancers?
Posted: Thu Oct 20, 2016 10:14 pm
by hansinator
Here's an example of what I meant with the parallelization and lane balancing. It is an 8-balancer that has 3 blue belt inputs and 1 yellow belt input. There is 1 yellow belt output, 2 half-lane blue outputs and 2 full blue belt outputs. The construction at the item sources detects belt stalls and lights up a red lamp to indicate overflow. It can detect even very short overflows. The input throughput equals the output throughput. Unfortunately the quality is so bad you can barely see the outputs flowing. But the red light indicators say everything is flowing. All other 3, 4 and 8 balancer configurations I've tried fail and by now I've got dozens of different balancer experiments in my test factory.
It becomes quite huge due to the parallel feeding. A 3-balancer built this way doesn't grow that much in size compared to the single version. My current experiments focus on circuit controlled balancers but the combinator-to-belt ratio is probably bad for less than 8 belts. However, I haven't got a working prototype yet..
Re: Non-throughput-limited 8+ belt balancers?
Posted: Fri Oct 21, 2016 8:07 am
by Frightning
Indeed the question he answered was a simplified version of the actual problem, where belts have only 1 lane, and splitters have no item memory. I think the best way to test his theory in game is to use belts with different items in each lane (e.g. left copper plates, right iron plates) and run it through the balancer. He also did not consider whether or not the design would balance input to output in underloaded conditions (e.g. half input, all output available, does it distribute half to all belts?)
Re: Non-throughput-limited 8+ belt balancers?
Posted: Sat Dec 02, 2017 10:47 pm
by TheRaph
Why so complicated?
I've tried this:
- Balancer.jpg (1.11 MiB) Viewed 10501 times
I've not discovered any throughput problems.
Due to belt going underground are so long it will not perfectly even all out - so if you start with one Belt (filled by a chest) and end with 8 Belts (each end in a chest) then the amount in the chests will not be even. But if it runs and you continusly provide one Belt with thins, they will evenly be provided on output.
The second issue (like with most of the other balancers too) ther is no balancing between lanes. If you provide only the lower lane with items, you'll get 8 Belts with lower lane filleded with 1/8th of Items.
Re: Non-throughput-limited 8+ belt balancers?
Posted: Sun Dec 03, 2017 3:46 am
by d4rkpl4y3r
TheRalph your contraption is not a balancer, though it is pretty close to throughput unlimited. My tool gives following output:
Code: Select all
Loading a 8 to 8 balancer with dimensions 16x13 and 32 splitters
Output balance: 0/8
Input balance: 0/8
Throughput under full load: 100%
Min Throughput with all combinations: 92.1%
Re: Non-throughput-limited 8+ belt balancers?
Posted: Sun Dec 03, 2017 4:28 am
by impetus maximus
Re: Non-throughput-limited 8+ belt balancers?
Posted: Mon Dec 04, 2017 12:29 am
by TheRaph
Hi,
Thanks for link to "command line belt analyzer" - I've try this and it told me the same as "d4rkpl4y3r" has posted.
But now my question to that: Why did this tool say it is not an "balancer" ???
What did "balancer" mean?
I think a balancer is a belt setup where I can input items on some (or all) input belts and they would be evenly balanced over the output belts.
If this definition is true, my balcer is a balancer too.
But if the definition is like as "give some different inputs (eg. red & green) will give a nice color pattern on output side" - thats not true for my setup.
I've tried the following test:
- Balancer3.jpg (1.21 MiB) Viewed 10474 times
On the left side ther are some chests (filled from train). These one fill the (non)balancer with red and green circuits over two belts.
Then on the right side there are chests at the end of the 8 output belts.
Some circuit network prevents the destination chests from beeing unloded into the train again.
I start that setup by setting the constant combinator on the left side to "on".
I waited until the left hand chests are empty.
Now i rad the circuit network state for item per chest-group on the right side:
1st Belt => 5.4k red; 4.2k green = 9.6k
2nd Belt => 5.4k red; 4.2k green = 9.6k
3rd Belt => 5.4k red; 4.2k green = 9.6k
4th Belt => 4.2k red; 5.4k green = 9.6k
5th Belt => 4.2k red; 5.4k green = 9.6k
6th Belt => 4.1k red; 5.3k green = 9.6k
7th Belt => 4.1k red; 5.3k green = 9.6k
8rd Belt => 5.4k red; 4.2k green = 9.6k
So the individual parts of red and green are not the same per belt, but the total amount looks the same for me ...
were is my foult?
Re: Non-throughput-limited 8+ belt balancers?
Posted: Mon Dec 04, 2017 7:37 am
by golfmiketango
Factorio is an open ended game and if something you created is providing enjoyment or useful functionality then it's not wrong.
However when people say "balancer" here on the forums and other factorio places, they mean a very particular thing. They are referring to a count-perfect belt-output-interleaving device which, if and only if the outputs of the device are never blocked, will sort items equally by type between belts (not lanes).
So an m→n balancer with all n output lanes unblocked, after perhaps a single "priming" load has passed through it, fed k*n items of a given type (whether or not other types of items are also fed to it) should pretty much always output precisely k items of that type onto each output belt. Further, it would be said to be "throughput unlimited" iff it's a balancer by that definition, and capable of processing min(m,n) fully compressed belts of materiel without limiting the rate of flow (a delay, or temporary rate-of-flow limitation is probably considered to be acceptable so long as the duration is O(1) relative to all variables).
A good way to test is to put a multiple of n items in a box, and feed this to various inputs of your balancer on only one side of the belt.
If your balancer really balances, then the output belts should all wind up with the exact same number of items on them, which is easy to confirm visually if they're all in a row right next to each other. However since balancers balance belts, and not necessarily lanes, if you supply both lanes with material, the results are much more difficult to interpret visually and you'll need something like what you've done above (ie: put the output into boxes) to test it's correctness.
I don't believe the .net framework tool folks are discussing, above, actually attempts to decide whether the blueprint you feed it is a balancer or not... although I could be wrong. Instead, my recollection is that it assumes your blueprint is a balancer, and tests its throughput properties. I'm sure, if I'm misremembering or confused, someone will set the record straight. I can't really use that thing, myself, without booting an emulator/Windows... perhaps should try to figure out how to build it with mono, as under wine the thing emits no carriage returns (only line-feeds) making it very difficult to understand the output.
Re: Non-throughput-limited 8+ belt balancers?
Posted: Mon Dec 04, 2017 4:11 pm
by TheRaph
Ok ... I've calculated my "balancer" in Excel. I understand now ... this tool from d4rkpl4y3r is right. My creation is not realy a 100% balancer. In some cases it has an inbalance of 30%.
So I do some calculating in Excel and think abaout this and that.
Now her is my solution.
The balancer-check-tool say:
Code: Select all
Loading a 8 to 8 balancer with dimensions 43x24 and 40 splitters
Output balance: 8/8
Input balance: 8/8
Throughput under full load: 100%
Min Throughput with all combinations: 100%
Her is BP:
And here is a picture:
- mega2.jpg (1017.22 KiB) Viewed 10452 times
The red marked square is a 8-belt-balancer with worst-case 50% througput. It is mutch smaller
Code: Select all
Loading a 8 to 8 balancer with dimensions 15x12 and 12 splitters
Output balance: 8/8
Input balance: 8/8
Throughput under full load: 100%
Min Throughput with all combinations: 50%
Re: Non-throughput-limited 8+ belt balancers?
Posted: Mon Dec 04, 2017 10:36 pm
by d4rkpl4y3r
golfmiketango wrote:I don't believe the .net framework tool folks are discussing, above, actually attempts to decide whether the blueprint you feed it is a balancer or not... although I could be wrong. Instead, my recollection is that it assumes your blueprint is a balancer, and tests its throughput properties. I'm sure, if I'm misremembering or confused, someone will set the record straight.
My tool checks if it is a balancer. It does this by using only one input at a time and then checks wether all outputs have the same throughput.
Also for the people who haven't seen it, here is my tiny throughput unlimited 8 belt balancer:
Re: Non-throughput-limited 8+ belt balancers?
Posted: Tue Dec 05, 2017 11:09 am
by TheRaph
d4rkpl4y3r wrote:
Also for the people who haven't seen it, here is my tiny throughput unlimited 8 belt balancer:
Hey that's a great design!
Until now I had change my design a little bit and now it is much smaller than my first one and do the 8/8 - 100% - job.
But is not as genial as yours
- Mega3.jpg (349.59 KiB) Viewed 10421 times