Kovarex in a row anyone?

[asheiduk]

Playing a little bit I've found a solution which reduces overfilling the centrifuges quite a bit:

It depends on the timing of the input inserter which grabbing some U-238 after grabbing the required U-225.

[...]
Unless it's case B and the timing is magically exact right on the inserter speed I sill see overfilling. Is that what you referred to with "it depends on the timing"?

Neither A, B not C catch the important points although C get nearest.

Let's only look at the first centrifuge at a point in time when it is working (i.e. it has swallowed 40 bright U235 and 5 dark U238) AND has additional 4 U 235 and 12 (a full swing of the stack inserter) U 238 in its input slots. When the fifth cycle completes the following happens:

• The first inserter (ejector) puts the two dark U238 onto the outer lane of the belt. These are ignored and queue up and are transferred onto the inner lane.
• The ejector swings three times and puts 3*12=36 pieces of the bright U235 onto the belt.
• The injector takes these and puts them into the input slots with three swings also.
• The input slots now contains 36 new U235 and 4 older ones and 12 U238 and hence the next cycle starts. Therefore all 40 U235 and 5 U238 are swallowed leaving 12-5=7 U238 in the input slots.
• Both input slots can not accept more items. The inserter will first pick from the inner lane and hence adds 12 more U238 (total: 19 U238)
• While the inserter does this swing the ejector will put the remaining U235 from the output slot onto the belt. Because it was the fifth cycle an additional U235 has been generated due to the productivity modules. Therefore this last swing will put 6 more U235 onto the belt. These will pass the inserter which is still feeding U238.

So in this (basic) cycle the first centrifuge will only overfill by up to 4 pieces. There are some complications though:

• Dark U 238 is only picked if there are less then 10 in the input slot. But if so a full load of 12 U238 is added so the maximum is 9+12 = 21 U238 in the input slot. In this case two cycles can start without feeding U238 and in these two cycles the inserter will also grab the remaining pieces of U235 and put them into the centrifuge. This increase the maximum overfill by at most 3 pieces U235. This will not accumulate however because the ejector can transfer up to 12 U235 onto the belt while the inserter is busy with U238.
• The following centrifuges work the same but are offered additional U235 from "upstream" which they will grab if they can. But even the next 5 centrifuges will not fill up to ~80 pieces of U235 as they get less from the previous centrifuges than they spit out -- on average.

Much longer chains than 6 centrifuges can overfill up to 80 pieces of U235 but in my setup the 6th centrifuge has ~32 pieces overfill.

So I think that this setup is ideal for bootstrapping because it is quite simple and the first centrifuges barely overfill so the next ones can start working earlier. When 6 ore more centrifuges are working then increased overfill is usually not a problem anymore.

[mrvn]

Makes sense. So it's not count perfect but by distracting the inserter with dark uranium the overfill is kept to a minimum.

Will try this for my next reactor.

[Khagan]

Playing a little bit I've found a solution which reduces overfilling the centrifuges quite a bit:

So it's not count perfect but by distracting the inserter with dark uranium the overfill is kept to a minimum.

This is a nice trick, and seems to be quite robust. I've adapted the uranium processing design I posted earlier to use it:

uraniumProcessing2.png (430.58 KiB) Viewed 5199 times

Two observations:

• For my particular version, I find that the first three centrifuges have minimal overfills (occasionally a few more for the third), but the fourth gradually accumulates to the usual maximum.
• More generally, while avoiding overfill is useful when you are just starting Kovarex and U235 is in short supply, in the long run it can be counter-productive, since it leads to downtime between each cycle of the centrifuge. I measured a stable production rate of 8.7 to 8.8 U235 per minute, compared to a theoretical rate of 9.6/min. For my 'bargain basement' version, with no high-level modules, this reduction is arguably OK when set against the reduction in capital cost represented by the absence of overfill. But the relative reduction is worse the faster your centrifuges are running; and the more they are pimped out with expensive high-level modules, the more it costs to make up the shortfall with extra centrifuges.

[mrvn]

Doesn't that improve over time? As new light uranium comes in from the sorting of uranium ore the first centrifuge should be getting overfilled more and more. And along the chains the centrifuges should pick up from the output of the previous ones. The not-overfilling thing with the inserters picking dark uranium only works on the output of the centrifuge itself.

[asheiduk]

Doesn't that improve over time? As new light uranium comes in from the sorting of uranium ore the first centrifuge should be getting overfilled more and more. And along the chains the centrifuges should pick up from the output of the previous ones. The not-overfilling thing with the inserters picking dark uranium only works on the output of the centrifuge itself.

See my reply here and try it out yourself: The first centrifuge will only overfill ~6 pieces maximum. This leaves room for 6 more pieces to be reduced nearly every cycle. So as long as the centrifuges transforming ore to U 235/238 do not produce more than 6 pieces of U 235 in one cycle of the Kovarex centrifuges there will be no significant overfill for the first centrifuge.

[asheiduk]

[*] For my particular version, I find that the first three centrifuges have minimal overfills (occasionally a few more for the third), but the fourth gradually accumulates to the usual maximum.

I think this is because you use blue inserters which can transfer at most 3 pieces in one swing. But overfill is reduced only by one swing each cycle. So only up to three pieces of overfill can be reduced each cycle. Try stack inserters and the overfill of the fourth one should go down, too.

[mrvn]

UPDATE: the inserter for size 11 was actually size 1 and some modules were missing. Fixed now.

The stack size matters it seems for the little magic centrifuge setip. So I've run this setup with stack site 1 to 12 an timed the first output:

covarex-fist-output.png (3.41 MiB) Viewed 5122 times

There is some difference in the time for each stack size. But size 12 is neither the worst nor the best. Size 5 seems to be optimal at 22:48 minutes. Worst is size 1 at 25:54 minutes.

So next I emptied out all the chests and run the game for 216000 ticks, 1 hour, to see how much each stack size produces. I did that 3 times. Here are the overall numbers:

covarex-1-hour.png (1.93 MiB) Viewed 5122 times

Things are still stabilizing after the first output was produced. So the first hour production is less than the second hour. But third hour production seems pretty much the same as second.

Notably stacksize 1 is the worst not just at startup but also in production. Production increases till it hits stack size 4. After that is is pretty much a wash.

Note: This is all stack inserters with different stack sizes. I didn't compare other inserter types. Fast inserters might be different than stack inserters at the same stack size.

A lot of stack sizes, but not all, had a big overfill between 40 and 80 uranium after the 3 hours. Those that didn't I'm not sure if that is just luck and they have 80 overfill at other times. Generally only the last centrifuge is affected, or affected the most at least.

Which makes sense. Distracting the inserter with dark uranium only works when the centrifuge starts a new cycle. In between cycles the inserter picks up all light uranium that comes by. The first centrifuge gets basically no outside light uranium. The second centrifuge gets the surplus from the first. The third centrifuge gets the surplus from the first 2 and the fourth centrifuge gets the surplus from the first three. All that surplus adds up and the amount the overfill is reduced each cycle is at most one stack size I believe.

PS: in the attached save game start everything by turning on the T combinator.

[Khagan]

[*] For my particular version, I find that the first three centrifuges have minimal overfills (occasionally a few more for the third), but the fourth gradually accumulates to the usual maximum.

I think this is because you use blue inserters which can transfer at most 3 pieces in one swing. But overfill is reduced only by one swing each cycle. So only up to three pieces of overfill can be reduced each cycle. Try stack inserters and the overfill of the fourth one should go down, too.

A beautiful theory destroyed by an ugly fact: changing from fast to stack inserters makes no difference to the observed behaviour. (None at all. I expected the downtime to decrease slightly, but I can't detect any change in the production rate.)

I do agree that 3 is the most that one can expect to work in a row with fast inserters, but clearly something else is also limiting here.

[mrvn]

Here is a variation of the magic inserter design:

covarex.png (665.88 KiB) Viewed 5121 times

0eNrVmt1uqzgQx9+F63CEwXxF2r05j3AuVxUiwWmtQwwykD3dKu++Y0gOaeqQGavbVW5axY5//pr5e+zJm7epB9FqqXpv/ebJbaM6b/3Xm9fJZ1XWpqx/bYW39mQv9t7KU+XefNoK1Wu5G56Fd1x5UlXil7cOj08rDypkL8VEGT+8FmrYb4T21ux3+16Xqmsb3fsbUffAbZsOmjXK9Agon2Xf4pX3Cm2C9FsMfVRSi+30DX5cfUCHBHR+Gx1a0BEBnd5GJxY0J6ATGjomoGMaOiGgOQ2dEtARDZ0R0CENnRPQjIZmAYEdENkEf8yJaII/ZkQ0wR+J7sgI/kh0R0bwR6I7MoI/Et2REfyR6I6M4I9Ed2QUf6ShQ4I7Er0xxHsjlYx3Rupy4H2RuIchd4oVMlSsEDuxcxR7dsa6KSsoskUJt4jQ+BRuNUPfDr1n62H2Sal2UkGdv30R3Z2Tferr3KLoRN9L9dyZb2qxbw6iGKCu7oUWVWGCPajalXUnVt5UPEV0p54HWDc57P0wyqDbbTOY+JEF4B37pjJfKHu/FuU4qFN0yI5PR9t0MltQuXjcT1OBRZPjUv1sDqUWv3yhtNy+7AHit7rZiq4znU8zefOgqBpgmQ9mvWCQQy38yAR8tjHluDHlXzekKMANKf7CITHkzn3hkEIHPTKaYWO5aFt+g+WkZiaeu684kZOamTgUwZ7VrOvL7U9fqk7o3q5q4QLbaASYSFMXG/FSHmSjTbOt1NtB9oXRjKLZFU0rdDm1gMU/14JUFWPvRSf/gaH0egBRmkrOVKlALYsPl9aD1P0AJfMsxm/4P7yjdZtSwnSjq+k+xARnse32ZV37ooYtAu/z26YWi9eV0yyVkM8vm2YYjwPOnmyd5PhVzB9wEXmAn1/28D7BGdFk0iWLAQPk3GY0PMQvavyIRhPh58cf32g40WiiZZlZ8dRqNDFBrx/RaAjHb/D4RpPSjCZYtBm7yszn398NTFvdujlZDnc1LecYkzLz51kLoS6fuWUFN7jsoltTkKbm3mMbS06PL8eI0PbYGziw2A2W0yu9if7uP6XHocuDN5Lt9E6PZHOXJ28k2+mlHslOXB69kWynt3okO7sSvukJYlHfZzmI7go81FW/W++k7izq9T7hNT94xN4Eh4GZR4/AfNi3JUin6cP7E8SNohfR+Czy7o3l/GBi79yma7FTBgK3F4lTBgLJZg5pAiQ6dEhuINER2TqThzTO+Powg9PtE6w14Q4ZHOTWxA4ZHCTaJc2CRKcOySEkmq6k4aMK6Xtb5Z9jq7lDBgy3NWngkAFDoplDmuq03ffQoQsaN+rIIW+HRHN6Cgy5Hhd30LaWvdWnLtb4ini2zw85lSkBVLQaPA76M/kksbMmhNLEYW64VbtMNd3SiwWr5/+bePwxVv+3V1i7OGlRXUtTxswPo6yqdRap5iC0lnAPvxwns21J5nDTwxkyXukiGjlzuZ2G9ttpdpF0Ou2+Dzu/kWrc+Q/AhZM4sVvn5XlBsYc5Dfou5Ym2kpsPBRlecfnCxnyZL7KPB/nsi0KVm1oUlezM/7Mvnmu1KKvipVTV6JewDnMS+mKgY8X03SnbHFiXLbqbiU8WFus8Z3UjDZ9xdBo+vdqVz0/Cx3MSnqd5fpmF3zeIJHwWO93xOMr7E5eLGA6dulwfcejM5Y6CQ+cudxQUOg9cLhI4NHO5/uDQoUuMjUNHLjE2Ds1dolUcOnaJsQ3aBBqjTK8vfti98uoSWkPZ9+kXF1AC8UY39Z8xkIww5TwKeMKPx38BLIFP0Q==

Copy blueprint

The filter inserter activate with something in the wooden chest and the yellow inserter deactivates. So for startup all light uranium passes to every centrifuge but once output happens each centrifuge only recycles it's own output.

[Khagan]

Here is a variation of the magic inserter design:
... for startup all light uranium passes to every centrifuge but once output happens each centrifuge only recycles it's own output.

And here's exactly the opposite approach: once the output U235 is backed up, the excess is directed back to overfill the centrifuges deliberately. (Yes, the belt braiding could probably be simplified.)

uraniumProcessing3.png (1.34 MiB) Viewed 5100 times

[mrvn]

Here is a variation of the magic inserter design:
... for startup all light uranium passes to every centrifuge but once output happens each centrifuge only recycles it's own output.

And here's exactly the opposite approach: once the output U235 is backed up, the excess is directed back to overfill the centrifuges deliberately. (Yes, the belt braiding could probably be simplified.)

uraniumProcessing3.png

I think you messed up a belt. One of the undergorund belts isn't connected because the belt goes past it instead of in.

Simplify it. Just split with a priority to the top and feed that back. Then split with the uranium filter to separate the light and dark for output.

It the other extreme then with complete overfilling. The ideal is in the middle. Fill just enough for the next cycle to start without delay but no more. Takes exact counting to do that.

[Khagan]

And here's exactly the opposite approach: once the output U235 is backed up, the excess is directed back to overfill the centrifuges deliberately. (Yes, the belt braiding could probably be simplified.)

uraniumProcessing3.png

I think you messed up a belt. One of the undergorund belts isn't connected because the belt goes past it instead of in.

The undergrounds are connected exactly as intended. They are both side-loaded directly from splitters.

Simplify it. Just split with a priority to the top and feed that back. Then split with the uranium filter to separate the light and dark for output.

Output should take priority over loop-back for both flavours. The main (left-lane) flow of U238 should never need to be looped back, only the expelled catalysts. For both output and loop-back each flavour should be able to flow freely even if the other flavour is backed up.

I'm sure the arrangement can be simplified a little, but I doubt it can be quite as simple as you suggest. In particular, if I start by splitting off the output instead of filtering, then if U238 is backed up, the catalytic U238 will clog the output channel for U235.

The ideal is in the middle. Fill just enough for the next cycle to start without delay but no more. Takes exact counting to do that.

Yes, that is the ideal.

[mrvn]

And here's exactly the opposite approach: once the output U235 is backed up, the excess is directed back to overfill the centrifuges deliberately. (Yes, the belt braiding could probably be simplified.)

uraniumProcessing3.png

I think you messed up a belt. One of the undergorund belts isn't connected because the belt goes past it instead of in.

The undergrounds are connected exactly as intended. They are both side-loaded directly from splitters.

Then I feel the priorities are wrong. You prioritize the output belt which allows the dark uranium to be drained from the belt loop. Sure more is coming in but the bootstrap not-overfilling only works when the dark uranium is backed up.

Same for light uranium actually. Shouldn't overfilling take priority because that increases production and then in the end you have more output? If consumption is higher than production you drain it all and production slows down making the problem worse. As is you need to produce enough light/dark uranium for the buffers in all consumers to fill before it ramps up to full speed. And if you didn't need the speed to fill all the consumers then what's the point increasing it now?

[asheiduk]

[*] For my particular version, I find that the first three centrifuges have minimal overfills (occasionally a few more for the third), but the fourth gradually accumulates to the usual maximum.

I think this is because you use blue inserters which can transfer at most 3 pieces in one swing. But overfill is reduced only by one swing each cycle. So only up to three pieces of overfill can be reduced each cycle. Try stack inserters and the overfill of the fourth one should go down, too.

A beautiful theory destroyed by an ugly fact: changing from fast to stack inserters makes no difference to the observed behaviour. (None at all. I expected the downtime to decrease slightly, but I can't detect any change in the production rate.)

I do agree that 3 is the most that one can expect to work in a row with fast inserters, but clearly something else is also limiting here.

Next theory : I see, that my blueprint uses stack inserters AND blue belts to decrease the time for transferring the U235 out and back into the centrifuge. That combination might explain the difference.

[mrvn]

[*] For my particular version, I find that the first three centrifuges have minimal overfills (occasionally a few more for the third), but the fourth gradually accumulates to the usual maximum.

I think this is because you use blue inserters which can transfer at most 3 pieces in one swing. But overfill is reduced only by one swing each cycle. So only up to three pieces of overfill can be reduced each cycle. Try stack inserters and the overfill of the fourth one should go down, too.

A beautiful theory destroyed by an ugly fact: changing from fast to stack inserters makes no difference to the observed behaviour. (None at all. I expected the downtime to decrease slightly, but I can't detect any change in the production rate.)

I do agree that 3 is the most that one can expect to work in a row with fast inserters, but clearly something else is also limiting here.

Next theory : I see, that my blueprint uses stack inserters AND blue belts to decrease the time for transferring the U235 out and back into the centrifuge. That combination might explain the difference.

Use the editor to slow down the parts of the game where the inserters swing and look at different cases. As in different amount of overfill already present and productivity module triggers an output. Compare each with the two inserter (and belt) types and check how the result differs.

[asheiduk]

[...] The first centrifuge gets basically no outside light uranium. The second centrifuge gets the surplus from the first. The third centrifuge gets the surplus from the first 2 and the fourth centrifuge gets the surplus from the first three. All that surplus adds up and the amount the overfill is reduced each cycle is at most one stack size I believe.

That's the reason why blue belts an stack inserters (with stack size 12) can "wash out" a little more U235.

[asheiduk]

The filter inserter activate with something in the wooden chest and the yellow inserter deactivates. So for startup all light uranium passes to every centrifuge but once output happens each centrifuge only recycles it's own output.

Good idea!

But right now I have no clue how to fit that into the constrains of beacons.

[asheiduk]

Use the editor to slow down the parts of the game where the inserters swing and look at different cases. As in different amount of overfill already present and productivity module triggers an output. Compare each with the two inserter (and belt) types and check how the result differs.

Well I did that (also) but I did not test yellow belts and blue inserters so far.

The interactions of the various parts are mesmerising but hard to describe. Your measurement setup seems to easier for getting overall results. Would you mind publishing numbers for blue belts + stack inserters?

[Khagan]

Then I feel the priorities are wrong. You prioritize the output belt which allows the dark uranium to be drained from the belt loop. Sure more is coming in but the bootstrap not-overfilling only works when the dark uranium is backed up.

Same for light uranium actually. Shouldn't overfilling take priority because that increases production and then in the end you have more output?

I think you are probably right about the U235, and I don't think it really matters about the U238. The braided design, or the improved version shown below, actually works fine with any priority settings (or none) on the loop-back splitters.

I generally expect my initial demand for U235 to be small, ramping up later, so getting some out the door ASAP and only then worrying about the last 10% of production speed was a natural approach for me. But it is probably stabler to ensure that at least some U235 is going back around.

With the deliberate overfilling approach, avoiding overfilling only matters during the startup phase. Pre-Kovarex a large stockpile of surplus U238 will have accumulated, and that stockpile is unlikely to be used up during the startup. So it's a pretty safe bet that the U238 output will be fully backed up while it needs to be. And afterwards, who cares?

The one thing that is critical is that there is always a free path out for the catalytic 238 (unless the output 235 is backed up). That's why the loop-back exists in the first place, and why the loop-back must never be fully backed-up. A split-first, filter later approach is, sooner or later, going to produce the following disaster:

uraniumProcessing4.png (528.1 KiB) Viewed 5012 times

The 235 can't get out, because the way is blocked by the catalytic 238; but the catalytic 238 can't get out because the output 238 is backed up and the loop-back is blocked by 235.

Here's a cleaned-up version that does work:

uraniumProcessing5.png (1.26 MiB) Viewed 5012 times

Again, it should work OK with any choice of priorities for the loop-back splitters. I've gone with none for the 235 and output preferred for the catalytic 238.

[mrvn]

Use the editor to slow down the parts of the game where the inserters swing and look at different cases. As in different amount of overfill already present and productivity module triggers an output. Compare each with the two inserter (and belt) types and check how the result differs.

Well I did that (also) but I did not test yellow belts and blue inserters so far.

The interactions of the various parts are mesmerising but hard to describe. Your measurement setup seems to easier for getting overall results. Would you mind publishing numbers for blue belts + stack inserters?

Load the savegame, take the upgrade planer and change everything. With the editor all ghosts are build directly so this should just take seconds. Then turn on the constant combinator with T and watch.


Concerning your disaster examples:

Yeah, that doesn't work. The dark uranium has to loop around too. Every time dark uranium is put on the bottom part of the belt a new cycle starts and some is taken from the top part. That then makes the dark uranium on the loop move. You then have to make sure that dark uranium from the bottom part of the belt is used first before the top part. It's complicated.


It gets much easier if you split the dark uranium before the covarex and only remove light uranium later. But with beacons it's always a problems getting belts to fit, not to mention splitters.