Factorio Forums

On the fluid system page on the wiki, there is a table of selected pipe throughput numbers for specific pipe lengths between pumps. I've previously verified those numbers by hand. Today, I automated the measurements. The motivation behind this was verifying whether a formula for pipe throughput that was added to the page is correct. (Spoilers: It's not.) I am providing the numbers and methodology here so that others can verify it or modify the mod for their own testing.

How it works: The mod adds a scenario that spawns tank -> pump -> pipes -> pump -> tank setups of pipe lengths 1 to 1001. The tanks automatically fill with water/empty of water. Then it increases the game speed until 9 minutes pass. At 9 minutes, a message is printed in chat, notifying the player that the pumping speed numbers in the pump tooltips can now be taken as reliable measurements. Before 9 minutes, input and output pumps of the pipelines may not report the same values, the throughput is not stable yet.

I've made use of the ability to modify the Factorio source code and locally, temporarily, added a way for the mod to read the pumping speed of the pumps. This is not possible in the normal game because the speeds are not save/loaded and doing anything with the read values can lead to desyncs.

Results of the measurements for pipeline lengths 1 to 1001 are attached in the txt file. They reveal that the value for pipe length 261 on the wiki is 1 off (will be corrected). Furthermore, the formula that was added to the wiki is not correct for all values. There is no explanation for the formula that would explain the discrepancies, so I will remove it from the wiki page. If someone can explain the discrepancies or provide a formula that is correct, please add it to the wiki or reply to this post!

I also attached a save file of the scenario (taken about 2 minutes of in-game time before measurements are reliable), so that the measurements can easily be verified manually. Note that saving the game in the paused state after the 9 minutes have passed and then loading again will have the pumping speeds displayed as 0/s due to the mentioned lack of save/loading. A zipped version of the mod (without the ability to read the pumping speeds in code) is also attached. Measurements were done in 1.1.65.

Pretty based, thank you for verifying.

Bilka wrote: ↑Mon Aug 15, 2022 4:51 pm I've made use of the ability to modify the Factorio source code

So there is no way to find some kind of formula or function in the source code directly? Seems easier to search for this than for creating a source code mod. Sounds like cheating, but if there is one person who is allowed to cheat, it is you as WUBE employee.

Or is the throughput indirectly determined by the properties of the involved pieces, such as the game fluid behavior regarding flow in and flow out from tick to tick for every individual pipe piece? Doesn't the game "know" that there is a pipe of n length, so it has a throughput t with t(n)=formula(n)?
Reminds me of all the secondary laws of nature that in essence are consequences of the 4 fundamental forces of physics. The game defines and implements fundamental forces, and the fluid throughput only results from this, but is defined nowhere itself.

Tertius wrote: ↑Mon Aug 15, 2022 7:58 pmOr is the throughput indirectly determined by the properties of the involved pieces, such as the game fluid behavior regarding flow in and flow out from tick to tick for every individual pipe piece? Doesn't the game "know" that there is a pipe of n length, so it has a throughput t with t(n)=formula(n)?

From my understanding, the game has no idea how long a series of fluidboxes is, it only evaluates a single fluidbox and it's neighbors at a time to perform calculations (hence why build order can matter a lot for throughput). Merging fluid boxes was one of the planned improvements that got scrapped.

Bilka wrote: ↑Mon Aug 15, 2022 4:51 pm Results of the measurements for pipeline lengths 1 to 1001 are attached in the txt file. They reveal that the value for pipe length 261 on the wiki is 1 off (will be corrected). Furthermore, the formula that was added to the wiki is not correct for all values. There is no explanation for the formula that would explain the discrepancies, so I will remove it from the wiki page. If someone can explain the discrepancies or provide a formula that is correct, please add it to the wiki or reply to this post!

The formula when incorrect is always predicting 1 unit higher than the measured throughput. Maybe he formula could be rebranded as a guideline to calculate the theorical maximum instead of the precise amount / if the formula says it's not enough, it's not enough for sure despite the little inacurracies the other way around.

Thinking about this got me 2 ideas :

1) fluids are not integer number for the game, for example you can have an odd number of fluid in a train with 2 wagon loaded exactly at the same speed, or i think i remember that when quantities are very low like with some mods that complexify nuclear adding very rare byproduct in fuel recycling the game would show 1 decimal, like 0.7 fluid, or 2.3

2) there is some very slight loss or creation of liquid occuring in the game, the situation where you have very rare byproduct can lead to it being noticeable contrary to vanilla when fluids are infinite. ( except sulfuric acid ) viewtopic.php?p=538288#p538288

Although " loss of fluid" is reported to occur for low quantity of fluid and the occurence of the discrepancies is not visibly increasing in frenquency with the pipe lengh/reduction there may be a link ? Some floating point inacurracies occuring at some point over time being measurable ?

Silari wrote: ↑Mon Aug 15, 2022 11:15 pm

Tertius wrote: ↑Mon Aug 15, 2022 7:58 pmOr is the throughput indirectly determined by the properties of the involved pieces, such as the game fluid behavior regarding flow in and flow out from tick to tick for every individual pipe piece? Doesn't the game "know" that there is a pipe of n length, so it has a throughput t with t(n)=formula(n)?

From my understanding, the game has no idea how long a series of fluidboxes is, it only evaluates a single fluidbox and it's neighbors at a time to perform calculations (hence why build order can matter a lot for throughput). Merging fluid boxes was one of the planned improvements that got scrapped.

I am under the same impression. With modded pipes or fluids or game speed, there are combos that form visible "waves" pattern that go back and forth in semi-filled pipes (visible with alt view on straight pipes or with debug menu to show fluid boxes), this seem to be a (costly for machines) side effect arising from the "physical simulation" of the fluid where the calculation are performed piece by piece. It's quite realistic that liquid form waves if you have a semi-physical description of their behavior.

Merging fluid boxes could change but also open the ability to "teleport" fluid, for example having 50 consumer of fluid close to each other in a group and after a long thin strech of pipe 50 producer of fluid. The obvious bottleneck in current condition, for which all those calculations are important , wouldn't exist anymore.

Also i'm not sure i'm up to date on all point with the changes that where made since fluid mixing is forbidden and often refers to the wiki, so thank you !

There is some artificial component in the measurement. If you graph the measured values, it looks like this:
There is clearly a kink in the derivative at 197->198. (Sorry for my kludgy English math terminology, this is something I never did with English)
How can this be explained, if the game doesn't know the actual length of the pipe?

May be it has to do with fluid levels. That is what drives the fluid flow, or fluid exchange between pieces. The difference of the fluid level from the previous to the next pipe piece. The influence of that difference to the flow rate doesn't seem steady.

If the level difference between the 2 outlets of a piece is higher than some given value, it seems it is computed by the game as a higher flow rate (with some high difference formula). And if it is lower than some given value, it seems a different, lower fluid exchange rate (some low difference formula). This could probably lead to the strange throughput changes we measure.

Other than that, the original formula seems very good. If you assume against better judgement the game does have knowledge about the pipe length, and if you change 240000 to 239999 in the formula, only 1 entry remains as wrong. For me, this is a hint the differences are based on rounding errors the formula doesn't account for.

I attach the Excel sheet where I experimented with small changes of the formula to reproduce the rounding errors, but this was not successful.

Tertius wrote: ↑Tue Aug 16, 2022 11:48 am There is clearly a kink in the derivative at 197->198. (Sorry for my kludgy English math terminology, this is something I never did with English)

Actually, there are two different formulas for <=197 and >197, that happened to create a continuous - albeit not derivable function.
(I totally did the same thing as you with the rounding tests in Excel XD).

The easy thing first:

mmmPI: 1) The speed number in the pipe tooltip and the calculated number from the formula are both floored "for display". E.g. 1200 flow could be 1200.9 flow in reality. The post you link to in 2) is edited to note that tiny amounts are no longer purged as of March 2021.

Tertius wrote: ↑Mon Aug 15, 2022 7:58 pm So there is no way to find some kind of formula or function in the source code directly? Seems easier to search for this than for creating a source code mod. Sounds like cheating, but if there is one person who is allowed to cheat, it is you as WUBE employee.

Or is the throughput indirectly determined by the properties of the involved pieces, such as the game fluid behavior regarding flow in and flow out from tick to tick for every individual pipe piece? Doesn't the game "know" that there is a pipe of n length, so it has a throughput t with t(n)=formula(n)?

As Silari (and mmmPI) explain, there is no formula based on pipe length in the source code, it evaluates fluidboxes 1 by 1. There is a bit of formula for the fluidboxes that can be used for further maths, but I personally can't make the jump to a pipe length based formula from that. And even if I could, I'd check it in-game anyway - same is done for example for the trivial inserter speeds (chest -> chest): Calculate and then double check in-game.

I'm not sure why I didn't think of it when investigating the formula that was added to the wiki, but there is already a formula that was figured out by someone: 19851. Archived version with working images. That post does make the jump from fluidbox formula to lengths of pipe.

What I can do with that post is confirm that (Pressure_A - Pressure_B)*0.4 is indeed correct as per the code. The 0.4 used to be defined in the prototype prototype (presumably that's where the post got it from), as of 0.17 it's hardcoded. The intertial transfer with Previous_Flow * 0.59 is also reflected in the source code (same shenanigans with prototype value to hardcoded with 0.17).

However, the preliminary conclusion of (Pressure_A - Pressure_B) * 0.4 + Limited[Previous_Flow * 0.59, Target_Capacity * 0.1] isn't quite correct. In the source code, it's (Pressure_A - Pressure_B) * 0.4 + Limited[Previous_Flow * 0.59, Own_Capacity * 0.1] - Limited[Target_Previous_Flow * 0.59, Target_Capacity * 0.1] instead. There was some change around this area with 0.17. From what I can tell, in 0.15 it used the Limits from the previous tick, in 0.17+ it uses the Limits of the current tick. I am not quite sure how the old behaviour worked, it looks complicated. Also, nothing was supposed to have changed in 0.17, but pumps were slower until I increased their capacity to 400 in 0.18.3 (that's something to note when looking at older posts like the above).

So, the flow formula is pretty close but not quite there. The resulting flow to distance formula for the pipe has the "kink" at 196 pipes instead of 197, when the calculated flow per tick is 10/0.59 (for pipes with 100 capacity).

Now, here is something interesting. There is another paper on fluids. It has the "kink" at 197, see Graph 5.4. From what I understand of the paper, in 2.5.5 the formula switches at 100/(10*0.59) flow per tick. That's the same flow number again, but since their formula is different it's a different number of pipes.

In the measured numbers that's 1016.9491 flow per second, which is 197 pipes. So formula switching at 197 pipes seems correct. I'd guess the behaviour change happens because of the Limit (min()) in the fluidbox transfer. So that explains that for the formula from the wiki.

But I can't figure out where the formulas themselves come from. Solving the formula from the forum post for flow results in different formulas, and the numbers in the table at the bottom of the post are also different than those calculated by the formula that was on the wiki. Simply tossing the first two formulas (using pipe capacity/pressure values) from 2.5.5 in the paper into wolframalpha doesn't get me anywhere either.

I'd like to readd the formula with a disclaimer, but I think that requires an explanation of where the numbers in the formulas come from. At the very least just to link it and point future discussion to, like I am doing with this thread.

Tertius wrote: ↑Tue Aug 16, 2022 11:48 am Other than that, the original formula seems very good. If you assume against better judgement the game does have knowledge about the pipe length, and if you change 240000 to 239999 in the formula, only 1 entry remains as wrong. For me, this is a hint the differences are based on rounding errors the formula doesn't account for.

I attach the Excel sheet where I experimented with small changes of the formula to reproduce the rounding errors, but this was not successful.

I am under the same impression, my reasonning looking at the values again is that the predicted value is always above the measured one, but this does not create a divergence, as it would if the little difference sum up over larger distances. Also this seem to occur only with predicted flow value value ending in 0 or 5 , except 1 occurence for distance = 586.

Bilka wrote: ↑Tue Aug 16, 2022 3:41 pm The easy thing first:

mmmPI: 1) The speed number in the pipe tooltip and the calculated number from the formula are both floored "for display". E.g. 1200 flow could be 1200.9 flow in reality. The post you link to in 2) is edited to note that tiny amounts are no longer purged as of March 2021.

1) Does that means when the measured value is at 799 instead of 800 maybe it is 799.99999999999 or something ? so maybe the discrepancies are very very tiny and due to the floating point rounding ? That would be invisible when the measured value is above, say 800.000001 , only when under ? i'm not sure i understand the meaning of the test value i'm reading :s

2) I must have missed this last sentence from boskid in the post i linked myself, there is no more purging logic, belief updated !

Tertius wrote: ↑Tue Aug 16, 2022 11:48 am There is clearly a kink in the derivative at 197->198. (Sorry for my kludgy English math terminology, this is something I never did with English)
How can this be explained, if the game doesn't know the actual length of the pipe?

Clearly on your graph, yes, if not , for me that had gone unnoticed. I think the following link from Bilka has some clues for explaining it, but it's difficult to understand those esoteric-looking mathematic equations.

Bilka wrote: ↑Tue Aug 16, 2022 3:41 pm Now, here is something interesting. There is another paper on fluids. It has the "kink" at 197, see Graph 5.4. From what I understand of the paper, in 2.5.5 the formula switches at 100/(10*0.59) flow per tick. That's the same flow number again, but since their formula is different it's a different number of pipes.

In the measured numbers that's 1016.9491 flow per second, which is 197 pipes. So formula switching at 197 pipes seems correct. I'd guess the behaviour change happens because of the Limit (min()) in the fluidbox transfer. So that explains that for the formula from the wiki.

The 100/(10*0.59) has a value 100 for the pipe capacity and 0.59 as a hardcoded value in the game for liquid, ( written as v in the paper). This is the flow rate that is definig when the "break point" as its called in the paper occur. The flow itself being the result of the interaction of the different individual fluid boxes calculations. Which in the paper are defined more in detail as considering each fluidbox has a input and ouput part.

(i'm no mathematician, following is just what i think i understandood from the paper)

The aim of the paper is to try and calculate "maximum theorical flow given a distance", while the post on the forum aim at calculating " maximum transport distance for given flow fluid". The two approaches are slightly different which may explain why the results differ in presentation ? The paper start with a very generic approach on fluid dynamic considering the smallest part in the game, is the input and output part of a fluidbox. While the post on the forum consider a the smallest part in the game as a pipe (which according to the other paper is composed of 1 input and 1 output).

On the paper are theorical situation that are put into equation describing what could occur to the input and output part of 1 "entity". This approach leads to classifying the behavior into categories described as "normal flow" "overflow" and "underflow" which could occur given theorical value, and then there are verification made by inputing the game value to check if it is possible for those situation to occur given a specific combinaison of boiler/steamengine/pumps/pipes.

"overflow" in the paper i think describe a behavior where the difference of pressure between 2 entity alone would generate a flow higher than what the entity can accomodate, in my mind it seem like when a full pipe should transfer to its neighbour 5 fluid, but the neighbour is also full and can only transfer 4 fluid to its own neighbour. Since the flow is the same in all the pipes in the line, it will be 4 fluid. This is a reduction in flow that is not directly the result of the interaction between entity that are attached to each other due to their pressure difference but the result of the propagation of the effect, which could explain why time is required before results are stabilized which is a condition to simplify the math and consider the flow is the same in every entity in the lane.

Bilka wrote: ↑Tue Aug 16, 2022 3:41 pm But I can't figure out where the formulas themselves come from. Solving the formula from the forum post for flow results in different formulas, and the numbers in the table at the bottom of the post are also different than those calculated by the formula that was on the wiki. Simply tossing the first two formulas (using pipe capacity/pressure values) from 2.5.5 in the paper into wolframalpha doesn't get me anywhere either.

(the balden part has the same link than previously linked under "196 pipes" is this normal ? )

To me i read this as 196 pipes being the last integer during which one behavior occur, and 197 being the first one for which another formula is required.

the formula on the wiki contain ( 3*pipes-1) which with 197 as input is equal to 590, or 1000 the constant v that seem to be deriving from the source code values, not an approximation measured from ingame value.

Also important to note when pipes = 197, the 2 formulas are giving the exact same result, which means the second formula is not true only when pipes > 197 but really when pipes >= 197 or > 196

On the same vein the result of the forum post on wolfram (the one linked twice ) gives the 2 formulas x = 4000/(40 + d) d > 196 is the same than 240000/(pipes +39) with pipes >= 197 ( or pipes >196 that makes it the same formula) This is just the unit that diifers as on the wiki result the formula with the 240 000 is in fluid/second while one the forumpost the formula passed through wolfram with 4000 is the result in fluid/tick.

Which is really weird because the formulas seem to agree for the result above 196, yet when checking again with Bilka's measured values, there is no error under 196, only above.

Fluid physics in Factorio look a little like dark magic. Nobody fully understands how they work, but they do . It might be the last thing in the core mechanics I dislike for its bizarre and unintuitive unpredictability.

Bilka wrote: ↑Tue Aug 16, 2022 3:41 pm I'd like to readd the formula with a disclaimer, but I think that requires an explanation of where the numbers in the formulas come from. At the very least just to link it and point future discussion to, like I am doing with this thread.

Maybe you could add a warning that the formula has been empirically inferred from the actual measurements, and is an approximation of what happens in reality.
Also explicitly warning that fluid throughput in the pipes are not calculated directly by the game, but are a result of the underlying fluid mechanics could be a welcome addition.

Doesn't build order and orientation affect the throughput? Does the measured values change if you build reverse to the flow, same direction as the flow, or in a random order? Does the measured values change if you change the orientation of the build?

Hornwitser wrote: ↑Wed Aug 17, 2022 11:27 am Doesn't build order and orientation affect the throughput? Does the measured values change if you build reverse to the flow, same direction as the flow, or in a random order? Does the measured values change if you change the orientation of the build?

According to the paper, https://www.reddit.com/r/factorio/comme ... cts_myths/, no , no, no, no, and no.

That would be different if there was junctions involved. This seem to be according to the paper because in a junction 1 fluidbox has for example 1 input and 2 ouput, and the flow for the 2 different output is computed one after the other. Such computation changes the level of fluid in an entity, which is then different when the second output is calculated. Therefore junctions do not by default split fluid evenly, which output is evalutated first could depend in the build order but i'm not sure i got that part correctly understood.

However none of the formula, be it the one on the wiki, the one from the forum post, or the one from the paper takes into account the build order, orientation , and flow direction, the author of the paper precise " Line's are not dependent on build order. Junctions are dependent and are problem spots."

Bilka wrote: ↑Tue Aug 16, 2022 3:41 pm The post you link to in 2) is edited to note that tiny amounts are no longer purged as of March 2021.

Hi Bilka,

I wanted to point out that on page 2 of that thread, Atomizer had linked to another thread they created (viewtopic.php?f=48&t=102921) that showed there was still loss at low fluid values.

I did some testing using their saved map and found the following:
With the barreling (output) assembler attached to the (~600) pipe network and using <5 barrels worth of fluid (I also changed the target of the output inserter for the barreling assembler to be the unbarreling assembler, creating a closed circuit), I did note fluid loss over time. However, if you disconnect the barreling assembler, thus allowing the fluid to just settle in the pipes, there is no loss. It seems like during the transfer of fluids from pipes to an assembler (tested with a pump as well and found the same issue with a pump) there is a small loss of fluids?

That said, testing with 5 barrels worth of fluids or more does not appear to experience this issue.

FuryoftheStars wrote: ↑Wed Aug 17, 2022 3:42 pm 102921

With the barreling (output) assembler attached to the (~600) pipe network and using <5 barrels worth of fluid [...], I did note fluid loss over time.

That said, testing with 5 barrels worth of fluids or more does not appear to experience this issue.

In that test, there are 200 fluid in 600 pipe. In the 1001 pipe setup of my test, there is 75k fluid in the pipe (25k of those in the starter storage tank). Generally, fluid amount in the pipe scales up with longer pipe, so I doubt these tests would ever reach a situation where is the a ratio of fluid/pipe below (or even near) 250/600. So, I highly doubt that the concern is relevant here.

mmmPI wrote: ↑Wed Aug 17, 2022 12:49 pm

Hornwitser wrote: ↑Wed Aug 17, 2022 11:27 am Doesn't build order and orientation affect the throughput? Does the measured values change if you build reverse to the flow, same direction as the flow, or in a random order? Does the measured values change if you change the orientation of the build?

According to the paper, https://www.reddit.com/r/factorio/comme ... cts_myths/, no , no, no, no, and no.

The original test builds with the flow. Reversing build order indeed doesn't affect things: https://github.com/Bilka2/pipe-throughp ... tag/0.0.11

Bad news: Direction does matter. The original test was with pumps facing east. I tested pumps facing west (and switched sink/source tanks). Even for multiple runs for east and west, the results stay the same. Two values out of the 1000 differ, they go from having the same value as the formula to having one less:

• Throughput at length 167 is 1019 (west) instead of 1020 (east)
• Throughput at length 961 is 239 (west) instead of 240 (east)

This also calls for north/south tests. Testing takes a while, so I wanted to share the results I already found.

mmmPI wrote: ↑Wed Aug 17, 2022 1:15 am 1) Does that means when the measured value is at 799 instead of 800 maybe it is 799.99999999999 or something ? so maybe the discrepancies are very very tiny and due to the floating point rounding ? That would be invisible when the measured value is above, say 800.000001 , only when under ? i'm not sure i understand the meaning of the test value i'm reading :s

Yes, that is possible. TODO for myself: For when the formula and the measured speed differ, output non-floored difference. Some selected non-floored difference are already available here, they don't seem to be tiny: https://wiki.factorio.com/File:Formula_ ... 19.27).png

mmmPI wrote: ↑Wed Aug 17, 2022 1:15 am To me i read this as 196 pipes being the last integer during which one behavior occur, and 197 being the first one for which another formula is required.

the formula on the wiki contain ( 3*pipes-1) which with 197 as input is equal to 590, or 1000 the constant v that seem to be deriving from the source code values, not an approximation measured from ingame value.

Also important to note when pipes = 197, the 2 formulas are giving the exact same result, which means the second formula is not true only when pipes > 197 but really when pipes >= 197 or > 196 :)

On the same vein the result of the forum post on wolfram (the one linked twice ) gives the 2 formulas x = 4000/(40 + d) d > 196 is the same than 240000/(pipes +39) with pipes >= 197 ( or pipes >196 that makes it the same formula) This is just the unit that diifers as on the wiki result the formula with the 240 000 is in fluid/second while one the forumpost the formula passed through wolfram with 4000 is the result in fluid/tick.

You see the connection, thank you! So the summary is that the formula that was added to the wiki is the forum post formula solved for flow and then adjusted for 197 pipes and flow/s instead of flow/tick. Great, now it's clear where it comes from :)

Linking the solved formula twice was intentional, to make clear what I am talking about. For me, tossing the first solved formula * 60 for the unit change into wolframalpha made the connection more clear, so link: https://www.wolframalpha.com/input?i=%2 ... +3+d%29*60 The alternate form 1000 + 10000/(2 + 3 d) is basically the wiki formula, it just needs the adjustment for (2 + 3 d) to result in 590 for d=197 instead of d=196 per mmmPI and voila.

mmmPI wrote: ↑Wed Aug 17, 2022 1:15 am Which is really weird because the formulas seem to agree for the result above 196, yet when checking again with Bilka's measured values, there is no error under 196, only above.

Yes, that is a bit weird. The formula from forum post has errors under 196, just to be clear (41 length pipe said to have flow 18 aka 1080/s, but measured and other formula say 1081).

With the extra errors with the direction change also above 197, the errors might be related to that. Maybe they aren't even errors? So, time for me to test north and south...

Bilka wrote: ↑Thu Aug 18, 2022 12:08 pm

FuryoftheStars wrote: ↑Wed Aug 17, 2022 3:42 pm 102921

With the barreling (output) assembler attached to the (~600) pipe network and using <5 barrels worth of fluid [...], I did note fluid loss over time.

That said, testing with 5 barrels worth of fluids or more does not appear to experience this issue.

In that test, there are 200 fluid in 600 pipe. In the 1001 pipe setup of my test, there is 75k fluid in the pipe (25k of those in the starter storage tank). Generally, fluid amount in the pipe scales up with longer pipe, so I doubt these tests would ever reach a situation where is the a ratio of fluid/pipe below (or even near) 250/600. So, I highly doubt that the concern is relevant here.

Correct. I was not meaning that in relevance to the tests in this thread, just commenting on this chain of discussion:

mmmPI wrote: ↑Tue Aug 16, 2022 6:18 am 2) there is some very slight loss or creation of liquid occuring in the game, the situation where you have very rare byproduct can lead to it being noticeable contrary to vanilla when fluids are infinite. ( except sulfuric acid ) viewtopic.php?p=538288#p538288

Bilka wrote: ↑Tue Aug 16, 2022 3:41 pm mmmPI: [...] The post you link to in 2) is edited to note that tiny amounts are no longer purged as of March 2021.

Specifically, I'm trying to say that there appears to be an edge case that may make that statement (or rather, the inference of that statement) not entirely true.

Bilka wrote: ↑Thu Aug 18, 2022 12:08 pm
Bad news: Direction does matter. The original test was with pumps facing east. I tested pumps facing west (and switched sink/source tanks). Even for multiple runs for east and west, the results stay the same. Two values out of the 1000 differ, they go from having the same value as the formula to having one less:

• Throughput at length 167 is 1019 (west) instead of 1020 (east)
• Throughput at length 961 is 239 (west) instead of 240 (east)

This also calls for north/south tests. Testing takes a while, so I wanted to share the results I already found.

Coming back to things after a few hours, I can't reproduce the difference with west, it now has the same values as east. I don't know how or why it changed. South is also the same as east. North has the deviation listed above (-1 for 167 and 961).

North results attached below, now with the exact difference between the non-floored measurement and the formula (code etc is on github). The differences are all very small (< 0.002).

I think that concludes this adventure for me. It's now clear where the formula from the wiki page comes from and the differences seem negligible now that more data is available. The formula is back on the wiki page.
To players it will still look like the formula is one-off because the game floors the numbers on tooltips, so I added a disclaimer along the lines of what Koub suggested. Thank you everyone for contributing your understanding and ideas, this is exactly what I hoped for when I posted here :D

That's not to say that this matter is closed, maybe someone can figure out why north is different (or what happened with west) :P Since it's just two values, measuring it by hand shouldn't be too bad.

Bilka wrote: ↑Thu Aug 18, 2022 12:08 pm For me, tossing the first solved formula * 60 for the unit change into wolframalpha made the connection more clear, so link: https://www.wolframalpha.com/input?i=%2 ... +3+d%29*60 The alternate form 1000 + 10000/(2 + 3 d) is basically the wiki formula, it just needs the adjustment for (2 + 3 d) to result in 590 for d=197 instead of d=196 per mmmPI and voila.

For me it didn't work most likely because i made typo and i couldn't get why only the bottom one looked familiar, i manually inputed the number in my phone's calculator and realized i had basically done the same math twice when i had to divide twice at the end 4000 or 240 000 by "236" which is 40+196 or 39+197.

Your link made it clear that the formula for pipe < 196 is also coming from the forum post.

Bilka wrote: ↑Thu Aug 18, 2022 12:08 pm The formula from forum post[/url] has errors under 196, just to be clear (41 length pipe said to have flow 18 aka 1080/s, but measured and other formula say 1081).

I meant that in the first set of value you linked, there was no discrepancies between measurement and calcul under 196 pipes all occurences were above. It puzzled me because at the time it wasn't clear for me that <196 pipes formulas were identical, only the > 196, so i thought this part is solved, but then looking at the value the discrepancies were in that part, and not in the other. The latest set of measured value makes it clear to me that measurement could differ from calcul both under and above 196 pipes,so whatever happens is not related (doesn't seem) to what requires players to use different formula for above or under 196 pipes.

I thought the flooring of the value on the forum post is different because it is not meant to indicate an exact flow but rather a maximum number of pipe. I think the table was made from the number 18 flow as input , which may hav given a number like 41,4 or 41,9 pipes and this means you can only transmit a flow of 18 fluid per tick over a distance of 41 pipes not 42.

But then I am puzzled by the value with 16 pipes => 20 flow(per tick) on the forum port, this means 1200 flow per second which is according to the wiki's formula and table still achievable with 17 pipes which i thought would have been written as the maximum distance over which pipes could carry the flow. But then 17 pipes is exactly 1200 fluid per second. So maybe 16 was written because of < or =< choice to write the table.

I'm not sure those are errors, given that all value are integer i would think it's just the presentation of the result that was meant to give general ideas of lengh based on increasing integer fluid count (1 2 3 4... 18 per tick ) rather than increasing number of pipe, and not be scutinized to this point

Bilka wrote: ↑Thu Aug 18, 2022 5:15 pm That's not to say that this matter is closed, maybe someone can figure out why north is different (or what happened with west) Since it's just two values, measuring it by hand shouldn't be too bad.

I would be interested to know

When looking at the last values from the test flowing north, i notice all the discrepancies significant numbers are between 14 or 16 digit behind the first 0 , not sure about the proper way to say that in english , but it doesn't look an infinite trail of numbers, and there is none that is way shorter like 0.0005 , and all of those numbers end by the digit 5.

From that i can't help thinking that all value must have 16 digits and some of them are actualy ending with 0 or 00. To me definitely a computer related rounding !

Bilka wrote: ↑Mon Aug 15, 2022 4:51 pm (crazy deep dive on fluid system wiki details)

Hey Bilka, since you're going 'deep' on fluids, figured I'd ask if fluid wagon loading was ever sorted? I bring that up because it was one of those edge cases where max flow was not actually 12,000/s. Understood the list on the wiki doesn't mention fluid wagons, but...
(touched on in this thread from way back where we fixed the pump flow rate for most other cases)

Hello there, author of this post here. People on reddit pinged me about this thread.

So, I intend to look into this with my formulas, but right now I'm redoing the math + reimplementing the formula, so I can do tests. Not sure what I'm doing wrong this time, but I didn't get breakpoint around 197 It will take a bit longer.

Just by looking at the numbers I can tell you that there is not two formulas, but at least three. The top entry in the table is 6000 units/sec = 100 units/tick -> pipe was overflowed, this is likely also true for the second entry and a few more. Those will have to use a different formula to correctly account for the effect. This didn't happen in the past. I looked into game files and believe this is due increase in maximum pressure on pump (200 -> 400). I'm kinda impressed that someone managed to fit the formula to this data.

About measurements. Can we change methodology here? Working errors out with rounded numbers is painful. We can get a much better measurements this way: run setup for n ticks and remember T total amount of fluid passed through. Then T/n will give us what we need. Just doing so for 2000 ticks theoretically gives us up to 3 digits after the dot. (To be fair this is the standard way such measurements are done in reality.)
Not sure how exactly this should be set up. If fluid removal is reported as float, we can just add them up. If it is reported as integer, then it's better to store all that fluid in storage tanks (perhaps modded to capacity of 100'000/1'000'000 or so?) to get a fixed measurement error.

Last, this is a bit awkward to to do after so many years, but can I ask something? Given two entities A and B connected to each other by fluid network, how many times the joint between them is evaluated every tick? Is it once or twice? It can be evaluated twice, first time when going through A, and second time when going through B, but it can also be evaluated only once (i.e. when going through B it is skipped). I'm asking because in the paper I made a subtle assumption that every joint is evaluated exactly once. If that doesn't hold then a whole bunch of math needs to be redone.

haibane_tenshi wrote: ↑Fri Aug 19, 2022 11:40 am About measurements. Can we change methodology here? Working errors out with rounded numbers is painful. We can get a much better measurements this way: run setup for n ticks and remember T total amount of fluid passed through. Then T/n will give us what we need. Just doing so for 2000 ticks theoretically gives us up to 3 digits after the dot. (To be fair this is the standard way such measurements are done in reality.)
Not sure how exactly this should be set up. If fluid removal is reported as float, we can just add them up. If it is reported as integer, then it's better to store all that fluid in storage tanks (perhaps modded to capacity of 100'000/1'000'000 or so?) to get a fixed measurement error.

You can get a finer-grained instantaneous measurement of flow if you derive it from power generation. Feed the flow to be measured to a bank of steam generators and use the Power Combinator mod to readout the production value from that network. I used that trick as a backup to the pump tooltip reading when trying to debug / get the pump's fluid height fixed. I also used that method to generate the Factorio Cheat Sheet chart (before the pump flow tooltip existed).