Pipe throughput measurements

[Bilka]

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)

It was sorted with the pump fix I did to increase capacity, mentioned above somewhere. I remeasured the fluid wagon filling times after the 0.18.3 fix, the numbers that are on the fluid wagon wiki page. The pumps were just as fast as before 0.17, maybe even a few ticks faster: https://wiki.factorio.com/index.php?tit ... did=164837. The few tick difference between these values may be related to testing methodology, before 0.17 tick perfect testing of the train arrival/departure was hard because the map editor pause game/tick once function didn't exist yet.

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

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.

To be clear here, your paper went a bit over my head. From my perspective, it may be possible that there are more than 2 formulas needed due to the 2 min() calls in the code, only one of which is considered in the older forum post which allows explanation of the wiki formula. But the min calls are not related to max pipe capacity, but rather low flow.

However, the two formulas that are on the wiki work for the 1 and 2 pipe long cases too, they give the same values as what is measured.

If it helps, as far as I can tell with my limited understanding of the notation, the Lisp code given here is exactly what happens in the game code. It should be identical to what I explained in my second post in this thread.

About measurements. Can we change methodology here? Working errors out with rounded numbers is painful.

There is no need for extra in-game methodology unless you must do the measurements yourself. The code that I have can give me the unfloored numbers. If you need anything beyond the "north" setup in complete glorious float (converted to double for Lua) precision, let me know. I can't measure things today and I am taking the next week off, but after that I can easily provide more values. Or maybe someone with source access can take my mod and run it with the modified lua api.

I didn't work with unfloored number (beyond testing the errors) because the goal was info collection for the wiki, which only needs to be accurate with what the player sees. Easiest way to see pipe throughput is the pump tooltip, which floors.

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.

From what I can tell, it is evaluated once per connection ("joint"), IsUpdateDirection is only modified on connect/disconnect:

Code: Select all

double FluidBox::PipeConnection::calculateFlowSpeed(...) 
{
  assert(this->isUpdateDirection());
  PipeConnection* opposite = this->getOpposite();
  assert(!opposite->isUpdateDirection());
  ...

[haibane_tenshi]

the Lisp code given here is exactly what happens in the game code.

This is amazing, I will take a look, thanks!

From what I can tell, it is evaluated once per connection ("joint")

Also great news, thank you! (At least my formula derivations are correct)

There is no need for extra in-game methodology unless you must do the measurements yourself.

Yeah, I kinda already looking into this. In modding APIs there are get_fluid_count which reports double just as I need, clear_fluid_inside and write_file. So I think it should be possible to collect all necessary data. As long as there are proper numbers doing math is easy. Never modded Factorio though, so not sure if there are some unexpected restrictions.

[malventano]

Never modded Factorio though, so not sure if there are some unexpected restrictions.

No need to write your own mod if you do this. I've gotten 6+ sigfigs with that method, which should be more than enough for your purpose. It's sensitive enough to pick up differences due to pipe build order / bends (in the 3rd-4th place after the decimal).

[mmmPI]

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

Thank you for coming and hopefully casting some lights on your formulas

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've been reading your paper again, and i think i wrongly attributed the situation you described as "overflow" ( or its absence) as the cause/factor explaining the "breakpoint" at 197.

Also i have noticed than the more i try to read the paper, the less iunderstand what is "μ" and "v". The graph 5.3.2 and 5.3.3 are highlighting the impact of their individual variation on the breaking point and with the help of the following graph, it seem that the higher "v" is relative to "μ" the worse is the flow but it's not clear (to me) what they mean/represent when they are introduced in 2.3.5 into a formula that look already too abstract for me to make sense of in the physical simulation. And just after their introduction you make a generalization that makes it even more abstract to me

I know it says (defconstant +pressure-to-speed-ratio+ 0.4)(defconstant +flow-to-energy-ratio+ 0.59) in the the Lisp code linked by Bilka here This is easier to understand ( and re-explain) as it's made of plain langage words, but it's not really indicative of their behavior as in the physical world liquids are not defined by those constant. ( unless i reallllly misunderstand them and my physic lesson from my school years). on the linked post it is explained as " it is a result of the `min` used in the momentum part of the equation" it's partially explaining things if you already partially understand them. It's easy to advice people that have trouble with liquid flow to use train or pumps when the distance is too long, or to input number in the formula to check. But that still leaves a gap of understanding when it comes to explain, why this is too long and why too long is very bad very quickly. ( distance 100->150 => small reduction in flow , 200->220 bigger reduction in flow).

It would be nice to have the wordings for the other part of the equation that is not the momentum part along with the formula. The notation with dozen letters makes it difficult to wrap around or identify some parts without having to go search for the meaning of one or the other and get lost in the way.

The formula on the wiki are very useful/practical but they 'hide' the ingame constant, a more visible relation between the 2 as Bilka established for the wiki may not be enough for someone intending to create modded pipes or any other entity that uses the fluid mechanic to predict and avoid problems. I'm saying this because i've seen waves, backward flowing liquids, and deadlock of fluids on circular loop while playing with different mods. If you don't mind doing some vulgarization on the junction science that would be read carefully i guess

[haibane_tenshi]

I've been reading your paper again, and i think i wrongly attributed the situation you described as "overflow" ( or its absence) as the cause/factor explaining the "breakpoint" at 197.

Breakpoint at 197 appears because of min(nu*F, C/10) switching to nu*F in formulas. I guess the reason it was introduced it to prevent an positive feedback loop for high flow (or maybe just to shut its growth?).

Overflow and underflow are completely different effects (although also appear from a value clamping).

Overflow appears when an entity can produce so much pressure that it can completely fill the next entity. This implies that the head part can deliver fluid faster than the tail part. The latter is the bottleneck, it is maxed out on the flow, but because overflow happened it cannot spread out the load more evenly on other entities. As a result you can observe that all entities in the head part have their capacity maxed out.

Underflow is the inverse of overflow. An entity creates so much "negative" pressure, that it can completely empties the preceding one. The head part delivers fluid slower than the tail part can consume. As a result you can observe that all entities past underflowed joint are empty (or jittering on low amount of fluid? it's been a while).

Also my last remark about pipeline formulas was kinda confused. I was looking at old flow data and saw the discrepancy at n=1. In short, if overflow happens at high flow it will still happen at low flow too. So for the modern pump there is always overflow happening on pump -> pipe joint. So, there are actually only two formulas (for n<= 197 and n>197), I managed to derive both and they agree with wiki formulas. By the way predicted breakpoint comes out at exactly n=197. And the reason why I didn't get it at the start is... I forgot to account for overflow, duh.

However, this wasn't the case in the past. Old pump produced overflow at n>=2 (so the flow values agree with modern ones), but it wasn't powerful enough to do that at n=1. So, actually, you had to use a different formula for that case and predicted value comes out at 90 units/tick. I believe I tested it in the past and it was correct. I wonder if it had something to do with increase of pump height.

Also i have noticed than the more i try to read the paper, the less iunderstand what is "μ" and "v".

I don't understand them either Quick googling of presumed units doesn't reveal anything interesting. Maybe someone with deeper understanding of fluid physics can give us some proper analogy. I just named them so to not drag around random constants.

It would be nice to have the wordings for the other part of the equation that is not the momentum part along with the formula.

The formula on the wiki are very useful/practical but they 'hide' the ingame constant, a more visible relation between the 2 as Bilka established for the wiki may not be enough for someone intending to create modded pipes or any other entity that uses the fluid mechanic to predict and avoid problems. I'm saying this because i've seen waves, backward flowing liquids, and deadlock of fluids on circular loop while playing with different mods.

Not gonna promise anything, but I might look into reworking the paper into something more readable. I kinda struggled to understand it myself I guess it will be in demand with modders.
A lot of practically related concerns are already nibbled at, I just never finished them.

If you don't mind doing some vulgarization on the junction science that would be read carefully i guess

Junctions are both easy and hard. Easy, because there is nothing new to them. Every junction entity simply gives a system of linear equations. This is also the reason why it is hard - it is just not calculatable by hand for anything but toy cases. And there is no sensible way to reduce the problem size down. To get accurate predictions you have to solve the whole fluid network at once. Specifying the whole network is kinda difficult. I guess you can try to extract it from a blueprint (if both build order + direction information is preserved) or maybe do it from a mod to give in-game projections... But that sounds like an awful lot of work and I have no interest in that.

Basically, as long as fluids + entities are configured in a good way, junctions alone shouldn't produce any unwanted effects. And if there are bad entities they will behave bad (although maybe a different kind of bad) even in line configurations.

[mmmPI]

I've been reading your paper again, and i think i wrongly attributed the situation you described as "overflow" ( or its absence) as the cause/factor explaining the "breakpoint" at 197.

Breakpoint at 197 appears because of min(nu*F, C/10) switching to nu*F in formulas. I guess the reason it was introduced it to prevent an positive feedback loop for high flow (or maybe just to shut its growth?).

The meaning of it is still not clear for me i'm afraid

However with your explanation on overflow/underflow i can confirm that i was mistaken earlier about their influence on the breaking point. Those are some sort of very large boundaries that are needed to include in a formula to illustrate the relation between distance and flow but are not the phenomenon responsible for the faster diminishing flow past a certain distance.

I think i made an example where those matters , when it comes to deciding between 2 different possible location for a pump the left setup is clearly better.

ovf.png (494.1 KiB) Viewed 4780 times

On the right side depending on which of the pump or the vertical pipe entering the refinery is updated first, the refinery has some input or is completly starved due to the pump absorbing all liquid in previous pipe. ( underflow situation ? ).

On the left side there is fewer pipes after the pump leading to the refinery pump=>pipe=>pipe=>refinery, while the path going to the next pump is composed of 3 pieces for 4 transfer, pump=>pipe=>undergroundpipe1=>undergoundpipe2=>pump. It seem to ensure that crude oil reaches the first refinery with more "priority" compared to being sucked away by the pump.

This modded pump from Krastorio is stronger than the regular factorio pump, and those steel pipes have higher capacity (125 vs 100) . The situation of overflow occurs very visibly when 1 pipes in a lane has not been upgraded by robots. In this case the one iron pipe and all the steel pipe before it in the lane are filled with liquid and after the iron pipe the quantity of liquid is getting lower and lower starting from 100/125 for a few pipes assuming there is enough consumer drain at the end of the lane.

Also i have noticed than the more i try to read the paper, the less iunderstand what is "μ" and "v".

I don't understand them either Quick googling of presumed units doesn't reveal anything interesting. Maybe someone with deeper understanding of fluid physics can give us some proper analogy. I just named them so to not drag around random constants.

Well that doesn't prevent you from generalizing on which value they could take for the simulation not to be broken

I have thought a little more on that and to me "pressure to speed ratio" is somewhat related to viscosity, https://en.wikipedia.org/wiki/Viscosity which is a defining constant for a fluid written as µ which is confusing
The wording seem to imply a relation between the height of a liquid in a container and the conversion toward horizontal speed over time (based on something like gravity ). The amount of time a liquid will require to flatten out/ reach a stable static state. ( that is 0.4 in game )

The other one " flow to energy" seem to be the proportion of the flow that is deriving from the previous flow, the momentum part as written in the Lisp code. that is 0.59.

It seem to me that the μ + v =< 1 is what makes the flow diminish overtime 0.99 for a 0.1 loss built-in on each iteration as it seem from the graph 5.3.2 and 5.3.3 that when they equal to 1 the fluid flow infinitly. That seem to be another parameter of what makes the flow diminish faster past 197 pipes than in the early phase, only after the breaking point is this relation visibly impactful.

But i can't still quite make sense of that with your simplfied formula because the 2 constant are not visible, they are inside the "F". Maybe it's too simplified, but it may be my fault if the extended the formula is too complex (for me) and the simplfied one too simple, there's not much more one can do to explain to me i'm sorry

A lot of practically related concerns [...] Junctions are both easy and hard.

I realize the junction part may be driving off the topic as it's " pipe throughput measurement"s , not exactly " in depth fluid mechanic lesson " although those are related when one measure precisely and in practice, junctions are everywhere

I have played with pipes with smaller capacity in bob's mod there are copper pipes that at the time i played with them i think had a capacity of 50 fluid vs 100 for iron pipe.
There was this "myth" that they were better than iron pipe, and in game in some situation it seem like replacing iron pipes with copper pipes help the fluid flow. That seemed really counter intuitive to me.

The formula to math distance/flow without explanation is not enough (for me) to hint as to why it would be the case and you can't use it easily under its wiki form to input other pipe capacity to help you either plan your factory as player or set the capacity as modder to a level that will provide the desired behavior. I assume given the value included in the formula that having a smaller pipe capacity for the end of the lane could somewhat be pushing at a further distance the breakpoint. ( not sure if because pressure seem higher with same quantity of fluid in a smaller capacity pipe, or if something different like a later switch in the limit do to 10/C relation to F evolving , or if those are meaning the same thing the myth has many version )

On a practical/experimental note, i have observed several weird behavior regarding circular lane of fluid which left me clueless and wanted to learn, same for the order in which the entity are updated, it seem to me that the latest placed pump gets all the fluids when conflicting with another pump in an underflow situation. This gets even weirder with modded entity having 2 output for the same fluid, when attempting to know which of the 2 entity will receive the fluid. I'm not yet able to predict or have an idea of what rules are applied but i guess it would be a pre-requisite to understand the circular lane behavior.

[Bilka]

I realize the junction part may be driving off the topic as it's " pipe throughput measurement"s , not exactly " in depth fluid mechanic lesson " although those are related when one measure precisely and in practice, junctions are everywhere :)

In practice you also don't have pumps everywhere :) I think the table on the wiki is mostly useful for laying long pipelines and as an upper limit for eyeballing "real game" throughput. E.g. if you've got 100 pipes with n junctions between consumer and producer, you know you can't get throughput higher than the 1033/s of 100 straight pipes between pumps.

Anyway, attached are non-floored numbers for the pump speeds, in north direction, measured after 15 minutes. By waiting longer than 9 minutes with measuring the speeds, the deviation from the formula for 167 pipes disappears. 961 is still different than the other directions. It's possible that after even longer the numbers get even closer.

[mmmPI]

In practice you also don't have pumps everywhere

When you first build your refineries i agree, but then you add modules and beacons, and one or two refineries at the end of the lane start lacking input so you add pumps here and there and here and there again hoping for something

Anyway, attached are non-floored numbers for the pump speeds, in north direction, measured after 15 minutes. By waiting longer than 9 minutes with measuring the speeds, the deviation from the formula for 167 pipes disappears. 961 is still different than the other directions. It's possible that after even longer the numbers get even closer.

The naming for the two value is "measured in pump " and "measured out pump" while it was "measured" vs "calculated" for the previous set of data. Does that means there are 2 different measurement of fluid flow somehow meaning that the quantity inside the pump fluctuate a little ?

I notice that at 163 and 164 there are already differences between the 2 entry of this set but it's very very small. Those little differences are then removed for 165 166 and 167, but they appear again later. at 801 or 804 for example. Differences seem more frequent for higher value but for 925 as example they match perfectly. I'm not sure what those value mean so i cannot really make sense of the observation.

It's possible that after even longer the numbers are converging toward the formula value due to successive feedback on each pipes like what you said. Maybe due to how floating point rounding is handle it will not show exactly the same as mathematical formulas computed to 16 significant digit using a different floating point rounding method. Maybe both. The scale means it doesn't matter in situation like previously described

Now for the sake of nit-picking if one entertainment from just playing the game is not enough very precise measurement , one could have a pumping speed/sec shown each tick for a whole second, for 60 different values per each lengh of pipes ( or more) ; to measure how stable is the system itself when the pumping/speed is measured. There may be little "waves" phenomenon occuring at very low scale with value alternating between above and under a certain other point that would be the one calculated from the formula. If those "waves" are reducing in intensity over time , that could explain why there is a higher frequency of differences between the two entry of the set for higher distance of pipes, as those would require more time to "stabilize" from successive feedback-induced waves.

[Bilka]

The naming for the two value is "measured in pump " and "measured out pump" while it was "measured" vs "calculated" for the previous set of data. Does that means there are 2 different measurement of fluid flow somehow meaning that the quantity inside the pump fluctuate a little ?

There are two pumps, the one at the start of the pipeline "in" and the one at the end of the pipeline "out". As stated in the very first post of this thread, as long as these two pumps have different flow speeds (e.g. at the start when the fluid has not even reached the out pump), the flow hasn't stabilized yet. I only measured once these pumps were within an acceptable value of each other (max delta 0.05 for everything but my last post which used 0.001).

[mmmPI]

Ah that is obvious now

Still thank you for precisions, that leaves working with "perfect numbers" something pretty much impossible or incredibly slow if one has to report all value per tick for 15 minutes.

Fluid dynamic in the game is approaching real life fuid dynamic's complexity haha nice job !

[haibane_tenshi]

Alright, I'm back! Sorry for the delay, had to put this project on hold for a while. But, I'm back with processed data, so we can enjoy some pointless numbers and graphs.

Measurements

I collected a few datasets in total concerning flow speed through pipes. For every pipe length setup includes

pump -> n x pipe -> pump

Fluid (water) is teleported right into the first pump (source) and removed from the last pump (sink). Removed values are recorded and reported as factual amount of flow that happened on specific tick. A single dataset includes all lengths from 1 to 1000. Each test runs for 60000 ticks.

There are 6 datasets in total: 4 with forward build order (i.e. joint evaluation happens along the flow), but each facing a different direction (east, north, west and south respectively) and 2 more datasets facing east, one with backward build order (i.e. joint evaluation happens against the flow) and one more with random build order.

Tests

All tests are variations of Student's t-tests.

First, I wanted to test influence of direction to take it out of picture, but then halfway through I remembered that both direction and build order only influence joint evaluation order. We can already test effects of joint evaluation order by tweaking build order, so there is no need to test direction... But I still did it. This verifies absence of any difference inherent to joint orientation.

The test was performed pairwise on first 4 datasets. Because they have identical joint evaluation order the expectation that behaviour should be same.

The result? Datasets are not simply close but about as identical as we can make it. Yeah, I know it is paranoid to test this, but now we can 100% confirm that orientation doesn't affect anything.

Second, I took all datasets facing east. There three of them differing by build order: forward, backward and random. Those were compared against the theoretically calculated max flow value.

The result - all OK. Actually, the resulting values are clustered around expected mean very tightly, so we can be quite confident in this result.

Third, I ran pairwise tests on those same datasets. This is were things get interesting, because we get discrepancies! To be honest I expected something like this to happen, the surprise was that it happened so early, forward and backward sets disagree already on lengths 8 and above.

To clarify, this test verifies that two sets of data are kinda equivalent in statistical sense, and this is what really is disproven. All three define mean in a way compatible with the theory (as seen in the second test), so there is a different cause behind it. Indeed, we subtly break a whole bunch of assumptions required for validity of such test. One of those is on the surface: it assumed that individual flow measurements are independent from each other (and equally characterize the value that we want to find - max flow throughput). However this is not the case! We can make this assumption for values which are measured after flow converged, but for the values at the start this is clearly not true.

From practical perspective this is rarely an issue. If your dataset is large enough having a few bad measurements doesn't change anything. And in case it does we can either take more measurements, or filter out bad ones.
To prove the point we can discard first few measurements - we know those are at fault. And indeed, this makes more line length to agree. For example, throwing away first 59000 values now causes only length of 127 or above to disagree.

There isn't much we can take out of this case. Probably the only useful result - convergence speed is very sensitive to length.

Graphs

Since we have all flow values from the very start, we can try to estimate how much time it takes for a given line to converge to its target value. In order to do that we calculate theoretical max_flow value and set an offset and say that any values that fall into [max_flow - offset; max_flow+offset] interval have converged. Time to converge is basically the last tick with value outside of this range.

With this we can graph convergence time for different build orders, let's say with 0.01 offset - it is about where human will stop noticing differences.

pipeline_convergence_time_0.01.png (57.89 KiB) Viewed 4770 times

Now this is damn wild. Notch around 200 should be recognizable - this is our old friend 197. At 197 there is a switch to a different formula which apparently strongly affects convergence speed. It also looks as if convergence slows down significantly before this point:

pipeline_convergence_time_different_offsets.png (62.92 KiB) Viewed 4770 times

I'm not sure what causes that notch around 150-ish for 0.1 offset. I also couldn't add precision lower that 10^-4, theoretical mean calculations are not coded accurately enough for this.

Last, I though it would be interesting to see the difference in convergence times between fastest and slowest (to converge) build order:

pipeline_convergence_time_difference_0.0001.png (43.05 KiB) Viewed 4770 times

No, this graph is not a joke. Despite the craziness above, this one is just a line.
Even before I started to make those graphs I made a prediction that the difference between the two will scale linearly with length, and actually if length is n then the difference will be approximately n.
Lo and behold! It feels nice to be correct from time to time.

The explanation behind this phenomenon is kinda weird. Establishing flow in a pipeline is a balance act between two elements: source and sink. They have to move in tandem and in the end the flow measured at each must coincide.
However, if they are out of balance (like at the very start) they need to "communicate" somehow in order to tune respective input and output flow. The only way it can happen is by adjusting fluid levels (or, equivalently, pressure) and let that propagate through the line to the other end. More than that, we are also waiting for the feedback from the other side in order to know whether flow increase/decrease is justified and whether it can continue. In a way there is a feedback loop where source (or sink) constantly adjusts flow through it and then waits for the information from the other side.

The interesting question is how long such feedback loops are? For a forward build order change in source propagated to sink in one tick, however it takes n - 1 (that is number of joints) to travel back for a total of n ticks. For a backward build order change in source reaches sink in n - 1 tick, but travels back in only 1 tick for a total of n ticks too! It is also sensible to say that convergence time scales with n and rate of change is likely roughly equivalent in both cases.

Then, if two cases are so similar, why do we observe the difference? The answer is starting conditions. This is correct that sources in both cases start their respective feedback loops immediately, at tick 0. However, situation with sink is different. For a forward build order, sink learns about existence of source on tick 1, but for a backward order, fluid reaches sink only on tick n!

So, forward build order simply gets a head start of exactly n - 1 ticks - and this is what we observed on the last graph.

By the way it also explains why forward build is the fastest (it takes shortest amount of time for fluid to reach sink) and backward build is the slowest (it takes the longest amount of time to reach sink). Also, from practical perspective, difference is negligible. For a line of length n difference in convergence time between fastest and slowest will always be about n ticks and it is dwarfed by total time required for convergence even to 0.01 precision.

I'm getting a bit off track here, but I hope you noticed something interesting. I described that in the process of convergence source can create a pressure differential which propagates to sink and back. Does it remind you of something? Waves! Indeed Factorio fluidboxes satisfy one of the key conditions for their existence: locality. Fluidboxes only affect "nearby" fluidboxes (for whatever definition of "nearby" we use here).

Following this thought, for fluidboxes as medium we can also define a "speed of information". This usually refers to speed of light from relativity, but it also known in other fields too, for example in fluid dynamics it is known as speed of sound. Or in other words it is speed of wave propagation.
Our case is rather interesting because in Factorio fluids "speed of sound" is variable! Actually it heavily depends on build order and changes depending on direction. For example, for backward build, "speed of sound" is 1 fluidbox/tick along the flow, but against the flow it is effectively infinite!
By the way this isn't non-physical or anything. For example, when we talk about speed of light we talk about "back-and-forth" speed of light, e.g. measured from A -> B -> A, and then we assume that it is equal in all directions. It is impossible to measure unidirectional speed of light (at least within the confines of the theory). This opens door for fringe possibilities. Theoretically it is possible that speed of light depends on direction, and yes this includes the case where it is c/2 in one direction and infinite in the opposite one (although such result will require us to rethink a bunch other theories like big bang). I thought this is just a really interesting parallel.

[Amarula]

Alright, I'm back! Sorry for the delay, had to put this project on hold for a while. But, I'm back with processed data, so we can enjoy some pointless numbers and graphs.

Cool! thank you for taking the time to write up all the details and provide the graphs.

[mmmPI]

Alright, I'm back! Sorry for the delay, had to put this project on hold for a while. But, I'm back with processed data, so we can enjoy some pointless numbers and graphs.

thank you !

All tests are variations of Student's t-tests.

If you never heard of it, the wiki page is not easy to understand, please correct me if this is wrong : The test measure if the difference between the measured results and the predicted result from formulas are variating over time and depending on pipe distance, pipe orientation / build order .

Given previous assumptions / hypothesis , the expected result is that value will converge meaning that the formula to calculate maximum fluid flow is accurate but it takes a little time for a system to reach this value and be stable, in case it does indeed converge, it is then possible to see how fast it converge. This would mean how fast a pipelane will reach a stable flow.

And it's where it gets (even) more interesting :

Third, I ran pairwise tests on those same datasets. This is were things get interesting, because we get discrepancies! To be honest I expected something like this to happen, the surprise was that it happened so early, forward and backward sets disagree already on lengths 8 and above.

To clarify, this test verifies that two sets of data are kinda equivalent in statistical sense, and this is what really is disproven. All three define mean in a way compatible with the theory (as seen in the second test), so there is a different cause behind it. Indeed, we subtly break a whole bunch of assumptions required for validity of such test. One of those is on the surface: it assumed that individual flow measurements are independent from each other (and equally characterize the value that we want to find - max flow throughput). However this is not the case! We can make this assumption for values which are measured after flow converged, but for the values at the start this is clearly not true.

From practical perspective this is rarely an issue. If your dataset is large enough having a few bad measurements doesn't change anything. And in case it does we can either take more measurements, or filter out bad ones.
To prove the point we can discard first few measurements - we know those are at fault. And indeed, this makes more line length to agree. For example, throwing away first 59000 values now causes only length of 127 or above to disagree.

There isn't much we can take out of this case. Probably the only useful result - convergence speed is very sensitive to length.

This is what i expected too, since i saw waves in game. It also validate one of Bilka's hypothesis that given more time than the 15 minutes the measured flow value would be even closer to those predicted from the formula.

Those value are answering the question : how much time before measurement = prediction ?

I'm not sure what causes that notch around 150-ish for 0.1 offset. I also couldn't add precision lower that 10^-4, theoretical mean calculations are not coded accurately enough for this.

From this graph i read that a pipelane of 160 pipes will reach a state close the stablilized state at 0.1 average variation faster than a pipelane of 120 pipes. However, when looking for an even more stable system (with less variation between measure and prediction) using a detection threshold of 0.01 or 0.001, we can see that the system having 120 pipes reaches those faster than the one with 160 pipes.

Or that waves magnitude is getting small, faster but stay wavy for longer time.

The same notch is present with an offset for 0.01 average variation. And i suspect it would be there too with the 10^-4 precision made visible but even closer to the 197 value.

I think this is because before 197 and the switch of formula part of the value that compose the equation are asymptotic. this is shown in your original paper https://www.reddit.com/r/factorio/comme ... cts_myths/ ( graph 5.1 or 5.2 the flat part before 197)

The "maximum flow" variation between lengh 180 and 185 is small, and between 185 and 190 is even smaller, and between 190 and 195 it's even smaller. It is from pipe lengh 150 that the variation is small enough to appear with 0.1, if you want to have even less variation you need to look at the graph of maximum flow even closer to 197 lengh, which is the second notch at 0.01 the 3rd and 4th one i suspect exist but are just invisible at this scale, or maybe so small that they do not fit into the amount of bit allocated for that.

From your previous explanation and the lisp code viewtopic.php?p=476422#p476422 , i understand this as the way the momentum part of the flow equation is calculated before 197 pipes is getting closer and closer to a certain value but slower and slower. And when the formula for this part is not providing anything because the change are nothing, then the formula switch to something different.

Last, I though it would be interesting to see the difference in convergence times between fastest and slowest (to converge) build order:


No, this graph is not a joke. Despite the craziness above, this one is just a line.
Even before I started to make those graphs I made a prediction that the difference between the two will scale linearly with length, and actually if length is n then the difference will be approximately n.
Lo and behold! It feels nice to be correct from time to time.

The explanation behind this phenomenon is kinda weird. Establishing flow in a pipeline is a balance act between two elements: source and sink. They have to move in tandem and in the end the flow measured at each must coincide.
However, if they are out of balance (like at the very start) they need to "communicate" somehow in order to tune respective input and output flow. The only way it can happen is by adjusting fluid levels (or, equivalently, pressure) and let that propagate through the line to the other end. More than that, we are also waiting for the feedback from the other side in order to know whether flow increase/decrease is justified and whether it can continue. In a way there is a feedback loop where source (or sink) constantly adjusts flow through it and then waits for the information from the other side.

The interesting question is how long such feedback loops are? For a forward build order change in source propagated to sink in one tick, however it takes n - 1 (that is number of joints) to travel back for a total of n ticks. For a backward build order change in source reaches sink in n - 1 tick, but travels back in only 1 tick for a total of n ticks too! It is also sensible to say that convergence time scales with n and rate of change is likely roughly equivalent in both cases.

Then, if two cases are so similar, why do we observe the difference? The answer is starting conditions. This is correct that sources in both cases start their respective feedback loops immediately, at tick 0. However, situation with sink is different. For a forward build order, sink learns about existence of source on tick 1, but for a backward order, fluid reaches sink only on tick n!

So, forward build order simply gets a head start of exactly n - 1 ticks - and this is what we observed on the last graph.

By the way it also explains why forward build is the fastest (it takes shortest amount of time for fluid to reach sink) and backward build is the slowest (it takes the longest amount of time to reach sink). Also, from practical perspective, difference is negligible. For a line of length n difference in convergence time between fastest and slowest will always be about n ticks and it is dwarfed by total time required for convergence even to 0.01 precision.

I'm getting a bit off track here, but I hope you noticed something interesting. I described that in the process of convergence source can create a pressure differential which propagates to sink and back. Does it remind you of something? Waves! Indeed Factorio fluidboxes satisfy one of the key conditions for their existence: locality. Fluidboxes only affect "nearby" fluidboxes (for whatever definition of "nearby" we use here).

Following this thought, for fluidboxes as medium we can also define a "speed of information". This usually refers to speed of light from relativity, but it also known in other fields too, for example in fluid dynamics it is known as speed of sound. Or in other words it is speed of wave propagation.
Our case is rather interesting because in Factorio fluids "speed of sound" is variable! Actually it heavily depends on build order and changes depending on direction. For example, for backward build, "speed of sound" is 1 fluidbox/tick along the flow, but against the flow it is effectively infinite!
By the way this isn't non-physical or anything. For example, when we talk about speed of light we talk about "back-and-forth" speed of light, e.g. measured from A -> B -> A, and then we assume that it is equal in all directions. It is impossible to measure unidirectional speed of light (at least within the confines of the theory). This opens door for fringe possibilities. Theoretically it is possible that speed of light depends on direction, and yes this includes the case where it is c/2 in one direction and infinite in the opposite one (although such result will require us to rethink a bunch other theories like big bang). I thought this is just a really interesting parallel.

This video happens to explain in decently simple term the very latter part on the speed of light : https://www.youtube.com/watch?v=pTn6Ewhb27k

It makes it quite clear to me how to see the parallel.

Or to explain the straight line

If i'm not doing mistake in my understanding, ( please correct me if i do ) if pipes are built in reverse direction, or if fluid flow backward, the amount of time required for a system to stabilize is the same past n tick, where n is the lengh of the pipelane. So if the lane is 100 pipes long, the backward fluid flow system will require 100 more tick to reach the same stability level.

This can be understood as : what makes the system stable is a time passing when the fluid is present in all pipes from the source to the sink. When the fluid flow in the same direction as the game update the fluidbox level then it takes only 1 tick for the whole system to enter a state where each tick the system is stabilizing. When the fluid flow in the reverse direction, it takes 1 tick for the fluid to move to 1 pipe, so the previously described state will begin for the system as a whole only after as many ticks as there is pipes.

Therefore convergence time difference between reverse build order pipelane, even if actual convergence time were unknown ( = for any lengh ) could and was predicted to scale linearly with distance !

( the difference in time at which the initial fluid reaches the sink between 2 pipelane built in reverse order from each other is visible in game )

The part i've balden in your quote i find very interesting ! For me it is related to the field of Claude Shannon https://en.wikipedia.org/wiki/Information_theory , particularly the reasonning that consist into generalizing the "time it need to communicate" with the "speed of information". It allows to start learning about concept like locality and information, and if you associate gravity then one can make sense of gravitationnal waves ! The same reasonning that make one search for a "time it need to communicate" applied to gravity would be when a wandering spatial item enters the area of gravitationnal influence of another spatial item. How does the wandering item "knows" its trajectory should change ? gravitation is also a balance act between 2 object, when does it start ? There were observation of gravitationnal waves that were moving at the speed of gravity : https://en.wikipedia.org/wiki/Speed_of_gravity

[mrvn]

By the way this isn't non-physical or anything. For example, when we talk about speed of light we talk about "back-and-forth" speed of light, e.g. measured from A -> B -> A, and then we assume that it is equal in all directions. It is impossible to measure unidirectional speed of light (at least within the confines of the theory). This opens door for fringe possibilities. Theoretically it is possible that speed of light depends on direction, and yes this includes the case where it is c/2 in one direction and infinite in the opposite one (although such result will require us to rethink a bunch other theories like big bang). I thought this is just a really interesting parallel.

Which makes me wonder if the directionality needs to be uniform, like going west is fast and east is slow. Or could the speed of light be infinite towards the origin of the big bang and c/2 away from it? Could there be multiple sinks?

[haibane_tenshi]

If i'm not doing mistake in my understanding, ( please correct me if i do ) if pipes are built in reverse direction, or if fluid flow backward, the amount of time required for a system to stabilize is the same past n tick, where n is the lengh of the pipelane. So if the lane is 100 pipes long, the backward fluid flow system will require 100 more tick to reach the same stability level.

Yes, this is correct. A more practically useful result, a line of length n with random joint evaluation order on average will converge only n/2 ticks later compared to the same line but with joint evaluation along the flow.

This can be understood as : what makes the system stable is a time passing when the fluid is present in all pipes from the source to the sink. When the fluid flow in the same direction as the game update the fluidbox level then it takes only 1 tick for the whole system to enter a state where each tick the system is stabilizing. When the fluid flow in the reverse direction, it takes 1 tick for the fluid to move to 1 pipe, so the previously described state will begin for the system as a whole only after as many ticks as there is pipes.

Actually, I don't think this part is correct.

You see, the system can be fully described by fluid levels in every entity at a given tick. We can do a trick: let's add all this fluid. This gives us amount of "stationary" fluid in system at given time. Now, if we compare amount of stationary fluid in forward and backward build when they just start converging (0 and n-1 tick respectively) it is clearly different! For forward build there can only be as much fluid as can flow out from pump in one tick (100), but for backward build this number can be way higher as new fluid can enter for n-1 ticks.

This reasoning gives us that even though two cases seem to be just offset in time, each clearly takes a different evolution path before converging.

This is what makes the result so much more surprising. I was expecting it to be close to n but rather be a relatively small factor of it (maybe 1.5n to 5n?). The fact that relation persists so well might indicate some deeper cause or fault in my reasoning.

By the way, here's graph for flow rate in 1000 pipe pipeline. All three builds look as if just offset on time axis and have only tiny differences at the very start:

pipeline_length_1000_flow.png (53.67 KiB) Viewed 4713 times

For me it is related to the field of Claude Shannon https://en.wikipedia.org/wiki/Information_theory , particularly the reasonning that consist into generalizing the "time it need to communicate" with the "speed of information"

It surely is inspirational. We all stand on the shoulders of giants.

[Tertius]

I'm sorry if I kind of interrupt the mathematical discussion, but there is something very basic I don't understand. I read about direction and build order. For a long time, I assumed "direction" means the current direction and momentum of a fluid; from left to right or from right to left (or top/bottom), just according to where the pressure directs the fluid. And I didn't quite get what build order means.

Now just the other day I was designing a large nuclear power plant and I observed a very strange fluid behavior.

This is the the first moment steam starts to flow after heating up. The whole plant was put down in the editor from a single blueprint with "build blueprints immediately". The right side was totally unexpected. How can steam start to vaporize from right to left? The tanks were empty (just 1 or 2 units).

Screenshot 2022-09-16 234536 direct blueprint in editor.jpg (1.31 MiB) Viewed 4360 times

Then I removed the steam turbines on the right side and built them manually - from left to right. Exactly the same picture.


Then I again removed the steam turbines on the right and build them manually in reverse order - from right to left.
Now the image is as I would expect it in the first place:

Screenshot 2022-09-16 235629 right half manually reverse.jpg (1.33 MiB) Viewed 4360 times

I wanted to explore how manually building, building with blueprints and copy+paste change fluid behavior. This happened after I cut the steam turbines on the right and immediately pasted them at the same place. A different, but still unexpected picture. The first turbine seems to get steam first, then the last turbine, then the steam seems to flow from the right back to the left:

Screenshot 2022-09-17 000816 right half copy then paste.jpg (1.61 MiB) Viewed 4360 times

Finally, I put down a blueprint as ghost and let robots build the thing. This randomization isn't still what I expected (I expected everything as clean as the left side of the first image), but also not that weird as in the other pictures:

Screenshot 2022-09-17 010224 blueprint ghost build with robots.jpg (1.59 MiB) Viewed 4360 times

I assume I understand now what you mean with build order. It seems, the in-engine representation of a longer pipe consisting of many single bidirectional fluid containers could be a linked list, and if something is added to the list, it's added to one end only, never the other end. And if 2 long pipes are connected to each other, it could be that the tail of one pipe is connected to the head of the other pipe - on the other side of the map - and the tail of that other pipe is connected to where the actual head of that pipe is located, may be like this:

pipe connections.jpg (93.08 KiB) Viewed 4360 times

However, I still don't understand if there is a different meaning to "direction". Do you mean that if I rotate the whole plant by 90°, I change the direction from left-right to up-down or down-up? And not some fluid direction is actually meant?

[mrvn]

Iirc it used to be that people build pipelines to transport liquid from west to east and got a flow rate of x. The next person build the same setup but transporting liquid from east to west and they got a flow rate of y < x. The conclusion then was that you should build your pipes so liquid flows to the east because that way is faster.

Now I don't know if that was ever a real thing. Or just an artefact of how the two people build their pipes, i.e. build order. The above tests at least seem to show that it no longer is a factor. Fluids in a pipe flow the same no mater in what direction you build it (provided you build it in the same order).

So it is important to separate direction and build order:

1) Direction is the, well, direction you let the fluid flow: North, South, East, West. You can take a blueprint and rotate it and that changes the direction.

2) Build order on the other hand is the simply the order in time that you place down the entities. E.g. build your turbines left to right. Except the left to right is not the right way to describe this. Because that is a direction. You should describe this in the direction fluid flows: backward, forward, random


Now concerning your screenshots: That is actually a nice way that shows the effect of build order because of how turbines interact with fluid boxes.

As you figured out all turbines are linked together. Each turbine connects to the fluid box of the previous and next turbine. But actually that isn't the bit that is quite relevant. I'm simplifying since the game now has a multithreaded fluid system but essentially the game also has a big list of all turbines (and pipes and tanks and ...) in the order that you build them. Each tick it goes through that list in the order in which you build the turbines and processes each turbine. For each turbines it checks if steam should flow to out connector 1 and pushes it out. Then it checks if steam should flow out connector 2 and pushes it out. That means a turbine build later will already have gotten steam from a turbine build earlier. While the other way it only sees the extra steam the next tick.

And turbines then have this nice effect that they show steam when they end up with fluid left in the turbine after all the flow. So you actually see the fluid level / pressure by the amount of steam coming out of the turbine. So you actually see the waves of fluid moving through the system tick by tick. Unfortunately (or fortunately) that also uses up fluid so. Think of it as a leaky pipe.

Build in forward order the steam can travel all the way through the turbines before it leaks while build backward it leaks directly because it pauses 1 tick at every turbine. Build in random order it's stop-and-go so it sometimes leaks and other times skips a few turbines.


Note: pipes still have a directionality when it comes to forks. In T junctions or 4 way junctions fluid flows differently depending on the direction. I'm not up to the latest rules so someone needs to test this or dig out info about this if it was already retested. But fluid doesn't, or at least didn't, split and merge perfectly at junctions due to the order in which the connections are processed.

[mmmPI]

This can be understood as : what makes the system stable is a time passing when the fluid is present in all pipes from the source to the sink. When the fluid flow in the same direction as the game update the fluidbox level then it takes only 1 tick for the whole system to enter a state where each tick the system is stabilizing. When the fluid flow in the reverse direction, it takes 1 tick for the fluid to move to 1 pipe, so the previously described state will begin for the system as a whole only after as many ticks as there is pipes.

Actually, I don't think this part is correct.

You see, the system can be fully described by fluid levels in every entity at a given tick. We can do a trick: let's add all this fluid. This gives us amount of "stationary" fluid in system at given time. Now, if we compare amount of stationary fluid in forward and backward build when they just start converging (0 and n-1 tick respectively) it is clearly different! For forward build there can only be as much fluid as can flow out from pump in one tick (100), but for backward build this number can be way higher as new fluid can enter for n-1 ticks.

This reasoning gives us that even though two cases seem to be just offset in time, each clearly takes a different evolution path before converging.

This is what makes the result so much more surprising. I was expecting it to be close to n but rather be a relatively small factor of it (maybe 1.5n to 5n?). The fact that relation persists so well might indicate some deeper cause or fault in my reasoning.

By the way, here's graph for flow rate in 1000 pipe pipeline. All three builds look as if just offset on time axis and have only tiny differences at the very start:

Although you may be right in saying its not correct, i don't understand why your explanation contradict the previous assertion, to me it is not related ( maybe i poorly worded ,my english is not great when discussing those topics ) , what i meant was that some undefined quantity of fluid need to be present in each and every pipe from source to sink for the backward flowing system to start stabilizing. It requires 1 tick per pipes for this to occur when liquid is flowing backward due to how the game update fluid level 1 pipe at a time based on neighbouring entity fluid level, and that in backward flowing system only 1 unit of distance is travelled by the fluid each tick initially.

Whereas for the system where build order = flow of liquid, only 1 tick is necessary for the sink to receive some fluid.(in theory, in practice it's how fast the first 100 fluid can move to the sink) This is what i understand as the source of the offset in time that create different initial condition when convergence starts to occur. because in this case the game update pipe 1 then pipe 2 which include the value from pipe 1 and then pipe 3 which include the value from pipz 2 calculated the same tick, just earlier in the tick. In this direction the information seem to travel "instantaneously".

In the frontward flowing system, i would think it takes 1 tick for the water to reach all the pipes up to the "sink"( in theory ! not counting pipe capacity limit ) and then 1 tick per pipe is required for the "sink" to be detected by the "source" ( the feedback going reverse to the flow is slower). so n +1 tick total.

In the backward flowing system, it takes 1 tick per pipe for the fluid to reach all the pipes up to the "sink", and then 1 tick for the "sink" to be detected by the source. ( the feedback is in the same direction as the build order so it''s almost instant ) so n+1 tick total.


Once the source and the sink are "connected" the feedback loop start occuring = if no water in pipes = "no connexion", no information can transit, and no feedback can occur.

Therefore i would mark the start of the feedback occuring at T= 2 tick for a regular flowing system ( the first tick water reaches the sink ; and the second tick the last pipe receive information from the sink , then the 3rd tick, it's pipe located at n-1 that receive information from the last pipe; the 4rth it's pipe located at n-2 that receive information from pipe located at n-1 and so on) .

The feedback value are different in the two cases ( forward flowing and backward flowing) because the initial value is different. starting from different initial value and at different time the convergence to the same expected result over long time is approached differently i agree with you.

However i suspect the number of feedback cycle required for the measured flow value to reach the predicted with formula value is the same. This is what i understand the linear graph means. ( maybe i have mistalenly concluded on a an hypothesis that is not the one you tested ? ) i would tend to think it's just an offset in time due to one system requiring n tick to reach a state where the flow in a fluidbox is impacted by the fluid level in the next fluid box and feedback correction start to occur, convergence starts earlier in one system. if you wait past this amount of n tick, then both system takes the same amout of time to converge.

I read your latest graph as +/- 990 tick is this "n" amount of tick for a 1000 pipe lengh pipelane. Given the 1000 lengh, it is no longer the theorical 1 tick i mentionned earlier. I would tend to understand your latest graph as confirming the previous assertion, if you remove the first 990 ticks of the graph so that the red line is superior to 0 at t= 1, then the blue line will be superior to 0 at t = 1 + n, so 1001. Then it can be read from the previous "convergence time to stable flow graph" that the value converged at around 18800 tick for the backward build, and exactly 1000 tick less for the frontward build ( this from the linear graph) or 17800 from the "convergence time to stable flow graph".

However when reading again my previous statement

When the fluid flow in the same direction as the game update the fluidbox level then it takes only 1 tick for the whole system to enter a state where each tick the system is stabilizing.

I can only agree that it is not a correct statement. The latest graph shows clearly that it is not 1 tick, but instead 990 or so before red line is superior to 0.

Maybe there are other mistakes you saw ? i don't think you were pointing this but also i don't understand the reasonning to sum up all liquid in the system at a particular time. I'm not sure what error you wanted to point out in my reasonning.

For forward build there can only be as much fluid as can flow out from pump in one tick (100), but for backward build this number can be way higher as new fluid can enter for n-1 ticks.

From this sentence i think you are doing the same shortcut as i do, counting 1 tick. and then n-1 tick. Whereas your latest graph with pipelengh 1000 would be actually requiring 990 ticks for the first fluid bits to reach the sink even in the forward build, and 990+n-1 for the backward build. So i think i'm still missing something.

This reasoning gives us that even though two cases seem to be just offset in time, each clearly takes a different evolution path before converging.

This is what makes the result so much more surprising. I was expecting it to be close to n but rather be a relatively small factor of it (maybe 1.5n to 5n?). The fact that relation persists so well might indicate some deeper cause or fault in my reasoning.

I agree with you that knowing all quantity in all pipes at 1 moment in time is enough to describe perfectly the system, as it contain all the informations necessary, from any pictures you take at any moment of a system you can predict its stable state given enough time; ( its maximum entropy ) ( otherwise the game of factorio wouldn't function, it wouldn't be deterministic that's how i understand it). [assuming constant flow from the source and total drain from the sink].

I do'nt see how this could indicate a fault in reasonning. to me it seem to persist as "n" exactly, because it takes "n" more tick for one of the two build to have water inside every single pipe. As soon as there is water in every single pipes, then the quantity can flutuacte each tick, and doing so information is carried and stablization between source and sink can start occuring/ convergence. So one build has a "n" time headstart.

Sure the actual water quantity being exchanged each tick between 2 pipes starting from that moment are different and so is the total quantity in the system. but also the amount of information is not the amount of water itself. The mathematical representation of the amount of information is complex math that i'm not mastering. It is related to the variation to the norm. For example knowing it rained a whole week in England is not containing the same amount of information than knowing it rained a whole week in the Sahara, it's obvious that one is a rare event and one is fairly common, but to quantify the amount of information require extensive/perfect knowledge of the usual precipitation rate in both region, and complicated formulas. ( how eventful it is, how comon it is ? how the new set of data containing the new entry point was influenced by that single entry point ). If you had never heard of those places called England and Sahara, the previous sentence contain a different amount of information, both sentence have the same weight. Intuitively it's easier to understand. Both sentence will have the same weight for one (fairly ignorant) individual but one sentence's weight will be corrected much faster with more data. Even if all the subsequent data are identical : today it rain in england and it was hot and sunny in the sahara.

It seem to me that each steps of feedback is carrying the same amount of information on average when comparing the 2 setups in later stages : 1 tick updates the value in ALL the pipes once there is water in every pipes for both system. But in the slower system the first few ticks update the value only in "1 pipe and those before it" when t<n.
given enough time the lack of information at first will no longer be visible = with enough data/time the correct assumption on english weather and sahara weather can be made, the proper liquid flow can be calculated because it has become stable.

If we compare not between 2 setups but 1 setup overtime. They are similar in that less and less information is transmitted each tick for high value of time. The reverse flowing setup would transmit at first an increasing amout of information each tick, until it reaches a peak, and then it would slowly reduce to provide less and less information each tick until reaching a stable state. While the straighforward setup would transmit peak information at start and only transmit less and less information overtime.

Which i understand like : at the end of the same number of ticks (past that n amount of tick), the total amount of information would be transmitted. ( the system would be stable no information is carried, maximum entropy). the offset "n" would then be explained as caused by the lower quantity of information transmitted in the backward flowing system during the early time when water is not present in each pipes. This creates a delay/discrepancy that is already existing at t=n , and is never removed and stays as a value of "n".

What made you anticipate a 1.5 to 5 coefficient for n ?

[Nidan]

I'm sorry if I kind of interrupt the mathematical discussion, but there is something very basic I don't understand. I read about direction and build order. For a long time, I assumed "direction" means the current direction and momentum of a fluid; from left to right or from right to left (or top/bottom), just according to where the pressure directs the fluid. And I didn't quite get what build order means.

Let me try to define/explain both terms then…

"Build order" is just that, the global order in which the entities were built. For fluid boxes, this is also the order in which they are updated each tick.
"Direction" can mean two things, either the cardinal direction, i.e. north/east/south/west // up/right/down/left, as in

First, I wanted to test influence of direction to take it out of picture, but then halfway through I remembered that both direction and build order only influence joint evaluation order. We can already test effects of joint evaluation order by tweaking build order, so there is no need to test direction... But I still did it. This verifies absence of any difference inherent to joint orientation.

or the direction of the fluid's flow, source to sink, regardless of which cardinal direction that is. In the majority of haibane_tenshi's posts this is meant by "direction", and the mentions of build order being "forward", "backward" and "random" (e.g. in the graphs) are relative to the direction of the fluids flow.

I assume I understand now what you mean with build order. It seems, the in-engine representation of a longer pipe consisting of many single bidirectional fluid containers could be a linked list, and if something is added to the list, it's added to one end only, never the other end. And if 2 long pipes are connected to each other, it could be that the tail of one pipe is connected to the head of the other pipe - on the other side of the map - and the tail of that other pipe is connected to where the actual head of that pipe is located, may be like this:

The container used doesn't matter, all we can observe is that it's an unordered sequence (e.g. list, array, vector, ...). Since we know fluid systems update in parallel, there probably is one such sequence per fluid system, in which case, as you say, when joining two fluid systems, the end of the first sequence is probably joined with the beginning of the second.

Regarding your pictures, to me they seem to be in line to the findings in this thread. In the first one (blueprint placed in editor), assuming the engine places the blueprinted entities left-to-right (and probably also top-to-bottom, but that doesn't matter here), on the left side fluid flow is against the build order so steam take a while to reach the far left and the turbines near the reactor start working first. On the right side fluid flow is with build order, so some steam gets moved to the far right instantly and those turbines start first. Your manual rebuild followed the same order as the blueprint placement, so no observable difference is to be expected.
In the second picture, you built the turbines right-to-left, i.e. against the direction of the steams flow. Now it's the same situations as the (still blueprint built) left side.
In the third picture it's again an instantly placed blueprint, so the expected situation is same as in the first picture. But oddly, the first turbines are working at full power. My guess is the first row of turbines wasn't destructed or at least placed earlier than the other turbines. Maybe you used them to line up the blueprint?
In the fourth picture robots build it, so the resulting build order is basically random. Considering the findings from this thread, it follows that the first bits of steam end up in a random turbine, which is what the picture shows.

Edit: As mrvn says, only in fluid boxes with three or more connections (e.g. a junction), the cardinal direction or some other internal order might matter. (Heat pipes have a similar system, and considering a reactor has 12 connection points, the four cardinal directions are clearly not enough to order them, so there has to be something else.)

[mmmPI]

I'm sorry if I kind of interrupt the mathematical discussion, but there is something very basic I don't understand. I read about direction and build order. For a long time, I assumed "direction" means the current direction and momentum of a fluid; from left to right or from right to left (or top/bottom), just according to where the pressure directs the fluid. And I didn't quite get what build order means.

if your fluid goes from left to right, you can build the pipelane in the same direction, from left to right, or you can build the pipelane from right to left. one is direction, the other "build order".

the context is sometimes different and direction would not be used relative to the build order, but instead to describe north south east west.

Does liquid flowing north goes faster than liquid going south ? = does direction matters ?

does it changes if you delete the pipelane and rebuild it in random order ? = does build order matter ?

If you consider the maximum flow that the system will reach when becoming stable, then north south east west, or build order don't matter. Build order has a very small impact on how fast the syste will reach a stable state.

However, in your example of using turbines the previous formulas are not quite applicable because turbines consume themselves steam . The formulas to calculate maximum flow would apply if you don't draw power and have turbine act as pipes because the formulas are made for lanes. If turbines start consuming steam, they act like a junction where steam inside of them can go to 3 direction and not only 2.

Build order has a very strong impact on junction flow. Which is much more difficult to represent with math than lane flow, which is already very complex