Nuclear Power Plant from the future

[Theikkru]

Now it makes even less sense to me; I don't know why you're trying so hard to use the individual capacities of pipes or tanks to calculate things when it causes so many strange problems, and the steps I showed already handle the "special case" you're talking about just fine.
In the equations I wrote, 3 pumps tried to pull a combined 600×50%=300 fluid that tick, but since there was only 100 in the segment, it got split up as 33, 33, and 34. If I try to follow your instructions:

[...]
(1) read segment volume = amount of fluid in it

[volume]=100

(2) get segment capacity ( number of pipe * pipe capacity ) +( number of tank * tank capacity ) ....

[seg-cap]=200

(3) get segment fill % ( (2) / (1) )*100

[seg-fill]=[volume]÷[seg-cap]×100%=50% (I'm going to assume you wrote it backwards)

(4) get entity from which pumps are attempting to pull volume (3) * capacity of that particular entity

[entity]=[seg-fill]×100=50

(5) get pump max optimistic pulling rate from that entity ( number of pump attached to that single pipe * (4))

[optimistic]=3×[entity]=150

(6) check if all pump can pull at max rate : => compare (5) and (1)

[optimistic]=150>100=[volume]

if (5) < (1) , all pumps gets to pull (4) quantity of fluid,
if (5)> (1), all pumps gets to pull [(1)/number of pumps]*(3) quantity of fluid
[...]

[pull]=[volume]÷3×[seg-fill]=100÷3×50%=16.6667
???
Not only does the answer not make sense, (since the pumps should exactly drain the segment if they're trying to pull more than available,) you've introduced 3 steps (4, 5, and 6) that require querying and calculating for multiple individual entities (the pipe pieces and tanks that output machines are attached to) every tick, massively slowing down calculations if the segment has a lot of output machines, and worse, there doesn't seem to be any reference at all to the nominal flow rate of the machines involved, (12000/s or 200/tick for the pumps in this case,) so all machines would be drawing based on the same individual pipe/tank limits. (Why would a chem plant or turbine get as much as 100 or 25000 fluid per tick!?)

[mmmPI]

Now it makes even less sense to me; I don't know why you're trying so hard to use the individual capacities of pipes or tanks to calculate things when it causes so many strange problems, and the steps I showed already handle the "special case" you're talking about just fine.
In the equations I wrote, 3 pumps tried to pull a combined 600×50%=300 fluid that tick, but since there was only 100 in the segment, it got split up as 33, 33, and 34.

Well i can understand why it wouldn't make sense, it's kind of far from the topic of the power plant, more abstract, and i'm not qualified to explain those things, which i made up and may contain mistakes. But i think i can try again to explain with another different initial setting and compare the 2 to try and illustrate better how i can see the pump working.

Supposedly If i use the same value as those you started with,my things would yield the exact same thing. Your equation describe for me one case where there couldn't be any other answer given starting condition.

It would only use the "????" answer only if the initial conditions are different enough to allow for all the pumps to potentially pull at their "max pulling rate" from the whole segment.

If I try to follow your instructions:

[...]

(1) read segment volume = amount of fluid in it

[volume]=100
[volume]=1000

(2) get segment capacity ( number of pipe * pipe capacity ) +( number of tank * tank capacity ) ....

[seg-cap]=200
[seg-cap]=1000

(3) get segment fill % ( (1) / (2) )*100 ( yes i had this backward )

[seg-fill]=(100/200)x100= 50%
[seg-fill]=(1000/1000)×100=100%

(4) get entity from which pumps are attempting to pull volume (3) * capacity of that particular entity

[entity]=[seg-fill]×100=50
[entity]=[seg-fill]×100=100

(5) get pump max optimistic pulling rate from that entity ( number of pump attached to that single pipe * (4))

[optimistic]=3×[entity]=150
[optimistic]=3×[entity]=300

(6) check if all pump can pull at max rate : => compare (5) and (1)

[optimistic]=150>100=[volume]
[optimistic]=300<1000=[volume]

if (5)> (1), all pumps gets to pull [(1)/number of pumps]*(3) quantity of fluid

if (5) < (1) , all pumps gets to pull (4) quantity of fluid,

(150>100) thus each pump is allowed to pull (100/3) * (50%) = 100/6 = 16.66667 fluid that tick (1000/second if sustain, which doesn't happen, because the tick after the fluid in the segment will be different, which means the fill level will be different, which means the pump will be allowed to pull less liquid and so on)
same as => [pull]=[volume]÷3×[seg-fill]=100÷3×50%=16.6667

(300<1000) thus each pump is allowed to pull : 100 fluid that tick. ( 6000/second if sustain which doesn't happen but goes to show the "max rate" as being inherited from the pipe capacity )

I don't see how it would be much slower or too different than your equations, in that i have attempted to use the same values, it shouldn't apply for all machines only for pumps. The capacity of the segment doesn't need to be queried every tick, it only need to be updated when a pipe or a tank or any entity is built on the map, it then gets assigned to a "fluid segment" and "increased its capacity" for (2).

(1) has to be updated every tick anyway as that's the amount of fluid in the segment.

(3) is just a simple division at the "beginning of the tick", after the amount of fluid is pushed onto a segment or removed, it means the (1) has changed since previous tick, since there is a different quantity of fluid, the % of fill need to be updated to, and it takes into account wether or not player build pipes during that tick in previous step because fillness depend on both fluid quantity and capacity of segment.

(4) is occuring each tick, but only for every entity that is "pipe-or-tank-attached-to-pumps". I thought only for "pump" not all machine and not all "pipes or tanks". One only need to math how much fluid in 1 pipe, 1 tank , 1 modded-tank, PER [fluid-segment] since inside a fluid segment, all "pipes" or "tanks" or "modded-tank" would contain the same "absolute value" ( the green bar of fluid shown in the FFF making me think this math is already present).

(5) is occuring each tick, but only for every group of pump attached to the same point, so that if 1 or 2 or 3 pump are attached to the same "pipe" or "tank" their optimistic pulling off rate would be accounted for as 1 value to be compared against the quantity of fluid in the whole segment. If a pipe is attached to no pump, it is not inducing any additionnal calculation.

(6) each group of pump attached to the same point pull the same amount of fluid, most of the time only 1 pump will be in the group, unless one squeeze 2 pump pulling from the same pipe/tank, or even 3 pumps, in this case, given previous steps, pumps would be able to empty the segment at a very high rate that could be tweaked without risking creating additionnal fluid.

(Why would a chem plant or turbine get as much as 100 or 25000 fluid per tick!?)

I only considered the case of pumps, not all machines, to establish the "maximum", attempting to find an explanation that would make it 6000 fluid/second, considering pipe has 100 capacity.
25000 fluid per tick is way too much x) but this would correspond to the "special case" when a pump is pulling from a tank. The number can be "capped" with a hardcoded-to-tweak-value, so that it would correspond to 12000 fluid per second to maintain the same values as in the old system for pump-max-rate-when-pulling-from-tank, or 25000 per second , doubling the max rate of vanilla game, making the "special case of pulling from tank" even better compared to the 6000/s that would be "inherited limit" when pumps pull from pipes or whatever value that devs seem fit when they playtest the expansion.

I also considered that the % of fill, is somewhat of a player indicator of the real value which would be "quantity of fluid", and that in game the "quantity of fluid" is updated first, and then the % of fill is calculated. which maybe was not well explained and caused unecessary confusion.

I also didn't consider the part where one make sure there is no attempt to push more fluid in the next segment than it can contain, which would be necessary for describing the whole pump functionning. ( but not machines like chem plant of turbines ).

Again at this point i'm not saying it's "simpler" or "better" or "more obvious" than your explanation, or any other explanation, it's just what popped in my head after i realized the problems in the previous explanations. It may still contain mistakes or me not realizing the extra computationnal cost.

This would make sense for me in the context of "is 1 pump or 3 pump or 0 pump" the best for the nuclear power plant ? => it depend on how wildly you speculate on the pumps rate calculation

Then even if my math are not making sense or incorrect , i can't rule out devs come up with a much clever solultion so that my speculation about flow rate are validated , despite me not possibly finding any nice algo to justify it , so i feel like i couldn't rule out cases where either 0 or 1 or 2 or 3 pumps would be optimal for the power plant.

[Theikkru]

[...]
It would only use the "????" answer only if the initial conditions are different enough to allow for all the pumps to potentially pull at their "max pulling rate" from the whole segment.
[...]

That "???" was my confusion at the 16.6667 answer, not me wondering about the other side of the if statement; I don't see how your equations make any sense.

[...]
I don't see how it would be much slower or too different than your equations, in that i have attempted to use the same values, it shouldn't apply for all machines only for pumps.
[...]

The steps I wrote are a generalized solution that can apply to all machines (including the tank-pump special case) in any configuration in a single segment. I can't figure out how your math is supposed to work.

[...]
(5) is occuring each tick, but only for every group of pump attached to the same point, so that if 1 or 2 or 3 pump are attached to the same "pipe" or "tank" their optimistic pulling off rate would be accounted for as 1 value to be compared against the quantity of fluid in the whole segment.
[...]

This is not the case: you would need calculations to account for all junction-machine combinations in the segment (e.g. 1 pump 1 turbine, 2 pumps 1 chem plant, etc.) Also, your math doesn't seem to handle multiple junctions at all. I must remind you that the FFF said that junctions shouldn't matter.

[...]
I only considered the case of pumps, not all machines, to establish the "maximum", attempting to find an explanation that would make it 6000 fluid/second, considering pipe has 100 capacity.
[...]

That is a problem; the steps I wrote are easily extensible to handle any combination of machines without appreciably increasing calculation complexity.
I also don't understand why you insist on trying to implement this 6000/s figure based on pipe capacity, especially since it would cause so much special case handling for other machines.

[...]
25000 fluid per tick is way too much x) but this would correspond to the "special case" when a pump is pulling from a tank.
[...]

Since that seems to be a sticking point, let's demonstrate a more complex hypothetical that addresses the tank-pump case too:

hyp.png (512.32 KiB) Viewed 1044 times

Assume 1% segment fill, and that the turbine uses 60/s or 1/tick. For this particular hypothetical, let's also assume that tank capacity is 1500 instead of 25000 (so I don't need a picture with over 100 pumps in it to overdraw the tank). I'll also implement the tank-pump special case as I interpreted earlier (max until 50% fill).
Using the method I wrote before:

Code: Select all

[seg-cap]=100×7+1500×1=2200
[seg-fill]=1%
[tank-pump-fill]=MIN(2×[seg-fill], 100%)=2%
[seg-vol]=[seg-cap]×[seg-fill]=22
[general-out-rate]=200×12+1×1=2401
[tank-pump-out-rate]=200×1=200
[intended-out]=[general-out-rate]×[seg-fill]+[tank-pump-out-rate]×[tank-pump-fill]=28.01
[corrected-out]=MIN([intended-out], [seg-vol])=22
[out-factor]=[corrected-out]÷[intended-out]=78.543%
regular pumps: 200×[seg-fill]×[out-factor]=1.57086→7 pumps get 2 and 5 get 1 for a total of 19
turbine: 1×[seg-fill]×[out-factor]=effectively 0
tank-pump: 200×[tank-pump-fill]×[out-factor]=3.14172→3
total out: 19+0+3=22=[seg-vol]

So, even with multiple machine types and all the special cases, the same calculation path can allocate output consistently; it just needs a few extra lines for the different machine types. I don't see why it needs to be any more complicated than this, and I don't see how your method would handle the same. (It seems broken somehow after step 5.)

[mmmPI]

That "???" was my confusion at the 16.6667 answer, not me wondering about the other side of the if statement; I don't see how your equations make any sense.

You are absolutly correct, i had missed that, then proceeded to explain more precisely again the exact same reasonning, not realizing/questionning if/it was flawed in the first place. It's when attempting to do so (yet again) with your picture and practical case that i realized.

The steps I wrote are a generalized solution that can apply to all machines (including the tank-pump special case) in any configuration in a single segment. I can't figure out how your math is supposed to work.

I spent a bit of time backtracking, and trying to figure out another way to fix my original mistake in attempting to find some check to prevent pump from generating fluid while still allowing them to output some quantity that they would take from the same pipe (symbolic quantity) and that would also be limited by the quantity of fluid inside that pipe. But it barely make sense to try and apply in "every cases", and even it would, proposing a working system is another set of skill than trying to understand one. I'm glad i could have a look at your working proposal x) it helps understanding in a less complicated way than working code, but more practial than just speculations without numbers.

Since that seems to be a sticking point, let's demonstrate a more complex hypothetical that addresses the tank-pump case too:
hyp.png
Assume 1% segment fill, and that the turbine uses 60/s or 1/tick. For this particular hypothetical, let's also assume that tank capacity is 1500 instead of 25000 (so I don't need a picture with over 100 pumps in it to overdraw the tank). I'll also implement the tank-pump special case as I interpreted earlier (max until 50% fill).
Using the method I wrote before:

Code: Select all

[seg-cap]=100×7+1500×1=2200
[seg-fill]=1%
[tank-pump-fill]=MIN(2×[seg-fill], 100%)=2%
[seg-vol]=[seg-cap]×[seg-fill]=22
[general-out-rate]=200×12+1×1=2401
[tank-pump-out-rate]=200×1=200
[intended-out]=[general-out-rate]×[seg-fill]+[tank-pump-out-rate]×[tank-pump-fill]=28.01
[corrected-out]=MIN([intended-out], [seg-vol])=22
[out-factor]=[corrected-out]÷[intended-out]=78.543%
regular pumps: 200×[seg-fill]×[out-factor]=1.57086→7 pumps get 2 and 5 get 1 for a total of 19
turbine: 1×[seg-fill]×[out-factor]=effectively 0
tank-pump: 200×[tank-pump-fill]×[out-factor]=3.14172→3
total out: 19+0+3=22=[seg-vol]

So, even with multiple machine types and all the special cases, the same calculation path can allocate output consistently; it just needs a few extra lines for the different machine types. I don't see why it needs to be any more complicated than this

I could see thousands of reason why it could be made complicated, mostly about realism, but it's already complicated for me I will have to apply it to the power plant, to test my understanding.

I'm a bit confused by the choice of only integers for quantity of fluid distributed, i assume you mean for simplicity, but i expect 12 pumps to get around 1.57 fluid for a total of 19 and not 7 to get 2 and 5 to get 1, or it would not be so "predictible around junctions" in case of a circuit controlled system ticking precisely the quantity, with risk of accumulation.

I 'm not sure i understand the "200"x12 in [general-out-rate]=200×12+1×1=2401. I think it is the size of the pump's fluid capacity, 200 fluid is the buffer in a pump, which means in the old system it was what limited the throughput to 12000 fluid per second and multiplied by 12 because 12 pumps ? And it's used with 1x1 which is the turbines fluid consumption of 1 fluid per tick.

I may be wrong but it makes me question if it would still work if a legendary assembly machine all beaconned was attempting to make water barrel instead of a turbine. As it would create a very large number instead of the 1x1 from the turbine and could create situations where pumps do not have "priority" due to attempting to pull "200" per tick versus mentionned assembly that could be attempting to make more than 4 barrel per tick ( conceptually, not yet with numbers sorry).

There is also this part => [tank-pump-fill]=MIN(2×[seg-fill], 100%)=2%
I am not sure, i think the underlined 2 is obtained doing (1/50)*100 where "50" is what you said was the threshold of 50% because i can"t think of anything else, and it would make sense with the rest of the demonstration but again i'm not sure i understood properly enough to try and apply it to a nuclear power plant.

and I don't see how your method would handle the same. (It seems broken somehow after step 5.)

Your understanding is not to blame ! It couldn't handle the same thing it was not thought for it, as a full system, was just a small things on pumps that i didn't realized wouldn't work with other things , particularly after step 5 x) and even when trying to do fix it i couldn't find something that would make sense when applied to the case of the picture with the reasonning i was following.

[Theikkru]

[...]
I'm a bit confused by the choice of only integers for quantity of fluid distributed, i assume you mean for simplicity, but i expect 12 pumps to get around 1.57 fluid for a total of 19 and not 7 to get 2 and 5 to get 1, or it would not be so "predictible around junctions"[...]

I glossed over integerizing the fluid portions because I'm under the impression that that's how Factorio works currently; like with solid items, I don't think Factorio deals in fractions or decimals of fluids. The FFF indicates that it's probably going to stay that way too, with language like this:

This results in much more even splitting, which while still not perfect, is pretty damn close.

---

I 'm not sure i understand the "200"x12[...]1x1 which is the turbines fluid consumption of 1 fluid per tick.

That is all correct.

I may be wrong but it makes me question if it would still work if a legendary assembly machine all beaconned was attempting to make water barrel instead of a turbine. As it would create a very large number instead of the 1x1 from the turbine and could create situations where pumps do not have "priority" due to attempting to pull "200" per tick versus mentionned assembly that could be attempting to make more than 4 barrel per tick ( conceptually, not yet with numbers sorry).

The equations would still work, but as you can see with the turbine in that example, it's certainly possible that some machines might get starved if put in the same segment as other machines with much higher draws when the segment doesn't have much fluid available. I wouldn't call that "priority", though, and it's a pretty natural consequence of the pipes running dry.

There is also this part => [tank-pump-fill]=MIN(2×[seg-fill], 100%)=2%
I am not sure, i think the underlined 2 is obtained doing (1/50)*100 where "50" is what you said was the threshold of 50%[...]

That is correct. I was a bit lazy with the notation there.

[mmmPI]

I glossed over integerizing the fluid portions because I'm under the impression that that's how Factorio works currently; like with solid items, I don't think Factorio deals in fractions or decimals of fluids. The FFF indicates that it's probably going to stay that way too, with language like this:

This results in much more even splitting, which while still not perfect, is pretty damn close.

I have to disagree, currently the game does uses non-integer for fluid quantity, it is visible when the fluid is less than 10 or 100 i'm not so sure, but otherwise the decimals gets truncated for display despite being there. There is even a special case, when the fluid quantity is not truncated, but instead rounded up, when the fluid is between 0 and 1 ,so that it stays "readable by circuit" when the quantity is non-null, even if it's not a full 1 fluid.

"pretty damn close" may refers to the impossibility to guarantee absolute perfect splitting due to floating point math, or something else with a imprecision of a different order of magnitude. But i'd be surprise that it would mean making all fluid quantity only integers, although, it could be the case, i think it would have been stated more explicitly.

It doesn't change the validity of your others points and the math though.

The equations would still work, but as you can see with the turbine in that example, it's certainly possible that some machines might get starved if put in the same segment as other machines with much higher draws when the segment doesn't have much fluid available. I wouldn't call that "priority", though, and it's a pretty natural consequence of the pipes running dry.
[...]
That is correct. I was a bit lazy with the notation there.

Thank you for confirming that i understood properly your explanation this time, i was thinking about the other way around, instead of a turbine getting starved, it would have been an assembly receiving fluid, and the pumps being starved due to the higher [general output rate] than the 1x1 that would have been attached to that hungry assembly. ( supposing a "200 fluid x1tick" assembly/ refinery requiring 12K fluid/second, would make it on the same level as pumps) . It seemed "weird", but on the other hand i don't know how to try and apply changes to the math without them looking like what i attempted to do earlier without success x). It may be that the devs are capable of doing it though, and that the system implemented for 2.0 is slightly more complex than the one you propose albeit working on the general idea. It really demystified the whole thing to play with the equations.