Pipe throughput measurements

[Tertius]

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?

I'm quite sure I cut+pasted exactly the complete turbine field on the right but kept the pipes that lead to the turbines. As far as I remember, I didn't keep the first row of turbines and I didn't set the first row extra. I just cut all and pasted all back the next moment. Because of that, it's so odd.
For the game it was all in the same tick, because all was paused in that moment. I wanted to see if cutting+pasting will keep the previous build order or do its own sorted order as with a blueprint. (It's as a blueprint. Proof for me that cut+paste is just a wrapper around temporary blueprints+deconstruction planner)

[mrvn]

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.)

It's not really cardinal directions. It's just that the connections of an entity are probably numbered so the links to the connected fluid boxes match up with the e.g. the locations of pipe end caps in the graphics that depend on whether a connection is connected or not. And the code that calculates flow then iterates over that array. The flow for the first connection is then calculated with the full pressure. The second connection only uses the remaining pressure and gets less flow.

Which now makes me wonder why straight pipes don't have directionality. If a fluidbox with 3, 4 or 12 connection points has this behavior then 2 connection points should too. Makes no sense that a straight pipe uses different code than the 3, 4 or 12 connection points case does. Is it just that the test setup doesn't have any waves and back flow so the order the connections are calculated in doesn't matter?

So here is what should be tested: Build a T junction and measure the flow with 1 source + 2 sinks and 2 sources + 1 sink in all configurations and orientations. The same can be done for a 4 way junction. The graphs should show the fluid flow for each source and sink for each tick.

Another thing that should be tested: Does the flow change when there are pipes before/after the junction? This could matter if fluid takes on momentum as it flows through a pipe and then resists changing directions.

[Nidan]

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?

I'm quite sure I cut+pasted exactly the complete turbine field on the right but kept the pipes that lead to the turbines. As far as I remember, I didn't keep the first row of turbines and I didn't set the first row extra. I just cut all and pasted all back the next moment. Because of that, it's so odd.
For the game it was all in the same tick, because all was paused in that moment. I wanted to see if cutting+pasting will keep the previous build order or do its own sorted order as with a blueprint. (It's as a blueprint. Proof for me that cut+paste is just a wrapper around temporary blueprints+deconstruction planner)

Actually, what I wrote here was wrong... for the steam to end up in the first turbines they must have been built last, not first. So the turbines were built left to right (because instantly placed blueprint) and then something happened to put the first turbines at the end of the build order list. Since you say you did nothing but place the blueprint I'm out of ideas.
(I agree, copy, cut and paste tools are blueprint, decon planner and blueprint book in disguise.)

[mrvn]

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?

I'm quite sure I cut+pasted exactly the complete turbine field on the right but kept the pipes that lead to the turbines. As far as I remember, I didn't keep the first row of turbines and I didn't set the first row extra. I just cut all and pasted all back the next moment. Because of that, it's so odd.
For the game it was all in the same tick, because all was paused in that moment. I wanted to see if cutting+pasting will keep the previous build order or do its own sorted order as with a blueprint. (It's as a blueprint. Proof for me that cut+paste is just a wrapper around temporary blueprints+deconstruction planner)

Actually, what I wrote here was wrong... for the steam to end up in the first turbines they must have been built last, not first. So the turbines were built left to right (because instantly placed blueprint) and then something happened to put the first turbines at the end of the build order list. Since you say you did nothing but place the blueprint I'm out of ideas.
(I agree, copy, cut and paste tools are blueprint, decon planner and blueprint book in disguise.)

Are they maybe build in a spiral from the player outwards?

I don't think the first turbine needs to build last, it just need to be after the second.

[Nidan]

I don't think the first turbine needs to build last, it just need to be after the second.

If we only look at the first turbine, yes. Once we start considering remainder of each row, where the turbines running full power are at the end, each row (of course excluding the first turbine) must have been built in a left-to-right order.

[haibane_tenshi]

From this sentence i think you are doing the same shortcut as i do

I do'nt see how this could indicate a fault in reasonning.

So, the way the argument goes, there are two phases for a pipeline to stabilize.

First, "startup" phase, where fluid entered pipeline, but didn't reach the sink.
Second, "convergence" phase, where fluid reached the sink, but flow didn't stabilize yet.

If we compare two setups, then difference in total convergence time is sum of difference between two phases respectively.

Theoretically, the difference between "startup" phases is n - 1. The difference between "convergence" phases is unknown, but from the argument it should be proportional to length of feedback cycle, i.e. n. This is where my prediction comes from. I expected that the cost of "startup" is going to dominate (or at least constitute a significant chunk of) the total time.

However, when comparing it to empirical results we run into a problem. The time difference between "convergence" phases is near 0. This is weird for a number of reasons:

• Difference isn't just 0 it is perfectly 0
• This is true for all n
• This is true for all deltas, where we consider that pipeline converged when all flow values fall into [max_flow - delta; max_flow + delta]. I tested this for many deltas from 0.0001 to 0.1.

The above is a strong indication that the two cases produce not just similar pipeline states, but identical ones. However, I showed that this is not true! "Convergence" phases have different starting state.

While I still believe that the time of "startup" phase is likely the culprit, I don't think this specific argument works.
There are few ideas that I have that can help resolve this conflict.

• It could be that there are some hidden invariants in how fluid system evolution happens (at least for those specific states). It just so happens that convergence time is dependent on those invariants and therefore the same.
  This is what I meant by deeper cause. To find them we will need more theory/math... I'm not sure I'm up to the task.
• It could be that there is a pivot point in pipeline evolution. Given different starts it takes different time to reach it, but after that pipelines states are identical or close to it.
  I think this is most realistic explanation.

In a way current theory is an incarnation of second hypothesis, just slightly incomplete/incorrect.

We can actually do further digging. There are two characteristics that can be used: total (stationary) volume of fluid in pipeline and inflow. I'll do tests when I get time.

[haibane_tenshi]

Which now makes me wonder why straight pipes don't have directionality.

They do have directionality. There are no exceptions. This is how fluid system works: first, all entities are evaluated in their build order, then all active joints are evaluated in order of cardinal directions. Note that every joint between two entities is evaluated exactly once (we got dev confirm this somewhere in this thread), so it makes sense to talk about joint evaluation order directly and ignore build order and directions.

What we are really talking about is that the maximum possible flow is not affected by joint evaluation order, however everything else is, including time that it takes for a given pipeline to converge to this max flow.

Another thing that should be tested: Does the flow change when there are pipes before/after the junction?

At least theoretically, the answer is "yes". For a line of entities, the flow is function of entity stats and difference in fluid levels between first (after joint) and last entity (a simplified model, but mostly correct). So, if you start adding entities to a line it will reduce its flow capacity even for the same pressure difference which in turn affects how flow is distributed through the junction. The effect is complex because it is dictated by a system of equations.

[mrvn]

Which now makes me wonder why straight pipes don't have directionality.

They do have directionality. There are no exceptions. This is how fluid system works: first, all entities are evaluated in their build order, then all active joints are evaluated in order of cardinal directions. Note that every joint between two entities is evaluated exactly once (we got dev confirm this somewhere in this thread), so it makes sense to talk about joint evaluation order directly and ignore build order and directions.

What we are really talking about is that the maximum possible flow is not affected by joint evaluation order, however everything else is, including time that it takes for a given pipeline to converge to this max flow.

Another thing that should be tested: Does the flow change when there are pipes before/after the junction?

At least theoretically, the answer is "yes". For a line of entities, the flow is function of entity stats and difference in fluid levels between first (after joint) and last entity (a simplified model, but mostly correct). So, if you start adding entities to a line it will reduce its flow capacity even for the same pressure difference which in turn affects how flow is distributed through the junction. The effect is complex because it is dictated by a system of equations.

"is evaluated exactly once" means that for a pipe build in order (as in not random) you will only ever evaluate one joint in build order as the other has always already been evaluated. So the directionality goes away.

With random pipes though a lot of pipes could evaluate both joints and other none at all. That could have an effect on how waves propagate.

[mmmPI]

So, the way the argument goes, there are two phases for a pipeline to stabilize.

First, "startup" phase, where fluid entered pipeline, but didn't reach the sink.
Second, "convergence" phase, where fluid reached the sink, but flow didn't stabilize yet.

If we compare two setups, then difference in total convergence time is sum of difference between two phases respectively.

Theoretically, the difference between "startup" phases is n - 1. The difference between "convergence" phases is unknown, but from the argument it should be proportional to length of feedback cycle, i.e. n. This is where my prediction comes from. I expected that the cost of "startup" is going to dominate (or at least constitute a significant chunk of) the total time.

I understand now the prediction. I agree with making the problem into 2 phase. I think it is already possible to know when the second phase starts from the existing data, at least for 1000 pipe lengh. since we have flow over time of 3 different build order setup.

However, when comparing it to empirical results we run into a problem. The time difference between "convergence" phases is near 0. This is weird for a number of reasons:

I understand you didn't like the reasonning based on quantity of information transmitted considering water as the medium. To me it makes it less weird your following findings :

• Difference isn't just 0 it is perfectly 0
• This is true for all n
• This is true for all deltas, where we consider that pipeline converged when all flow values fall into [max_flow - delta; max_flow + delta]. I tested this for many deltas from 0.0001 to 0.1.

The above is a strong indication that the two cases produce not just similar pipeline states, but identical ones. However, I showed that this is not true! "Convergence" phases have different starting state.

Your result showing the different starting state is what i mentionned earlier with the graph flow over time of the 1000 lengh pipe with 3 different build order ( i think).

I agree it shows that the result are not identical despite the list of strong similarities that could suggest otherwise.

Another imaged example would be considering you have to pick a number with 16 decimal between 0 and 100. I try to find this number proposing another number, and you only tell me + or - In this type of situation, you also have a converge speed that is similar despite different initial phase. This is to me the same phenomemon that we are witnessing.

The number of question required to find at least 5 decimal digits ,or 7 or 10 is similar to how much time is required to achieve a certain degree of convergence in the pipe measured throughput and the pipe max theorical throughput from the formulas. (Or between 2 setup of pipes with opposite build order, or 2x as much time as for truly random build order. which is shown thanks to your test AND math.)

While I still believe that the time of "startup" phase is likely the culprit, I don't think this specific argument works.

I agree with you it's not a "working" argument in the sense that it doesn't explain why it is this way or help predict, i'm not able to formalize in proper math the previous explanation and i cannot apply it to the pipe flow for prediction. It is however (i think) one of the concept that could help make sense of the result for the intuition. In the previous case, the number between 0 and 100 that is choosen do no impact much the amount of time required to find the 10th decimal digit of the hidden number. Altough there is a direct relation if one was to choose a number between 0 and 10 000. It would require the same time to find the 7th digit and so no matter the actual number between 0 and 10 000 that is actually choosen as base before the decimal part. ( on average with random number)

There are few ideas that I have that can help resolve this conflict.

• It could be that there are some hidden invariants in how fluid system evolution happens (at least for those specific states). It just so happens that convergence time is dependent on those invariants and therefore the same.
  This is what I meant by deeper cause. To find them we will need more theory/math... I'm not sure I'm up to the task.
• It could be that there is a pivot point in pipeline evolution. Given different starts it takes different time to reach it, but after that pipelines states are identical or close to it.
  I think this is most realistic explanation.

In a way current theory is an incarnation of second hypothesis, just slightly incomplete/incorrect.

We can actually do further digging. There are two characteristics that can be used: total (stationary) volume of fluid in pipeline and inflow. I'll do tests when I get time.

I'm not up to the task for the "hidden invariants" but i think is related with the hidden number that one has to find game. that's how i understood the straight line graph. convergence speed do not consider starting phase like in the game the number choosen is not what makes it easier to find ( on average with random number) but instead it is the lengh of the number/precision in decimal that is related directly to the number of questions required to find the number. This is why i thought it was not related to the total quantity of fluid in the system as i saw the direct apparent corelation with pipe lengh.

I think that measuring the quantity of fluid as you describe for "further digging" would nonetheless gives more information . It could possibly show some sort of sin() looking function with opposite starting phase but converging toward the same median value at the same speed.

It could also be interesting to know the different fluid quantity in an individual pipe overtime compared to the end value when things are stable in both direction of flow relative to the pipe buid order in order to investigate the behavior of convergence over different phase. This is visible in game with the debug menu showing liquid in fluidboxes. It is were the "waves" phenomenon are easiest to see. Having some results for 2 or 3 different pipes positions given 1 particular lengh could help illustrate the general behavior to infer for other lengh. I know those test takes time and if you are willing to share your testing setups/ method, i think i could do a few myself, as i seem to have a lot of time for those math that i find very interesting

I wouldn't be surprised to see both hypothesis be somewhat true, with a pivot possibly occuring due to "hidden invariant" or those explaining why past the pivot point result are close to identical. maybe i don't understand what makes them so disctinct for you.

[blazespinnaker]

+1 for longer pipes. They help with throughput issues, they're very cool looking, add new puzzles to the game, and easier to tear down / place with bots.