[0.15.x] Fluid mechanics

[Aru]

But, rseding has no intention of fixing it from what I can tell.

In one of ColonelWill's streams Rseding said that he wanted to tackle the fluid mechanics because it is currently linear time, and he believed that there was no reason for it to be that way. The comment that you have linked would be about that particular implementation, as it requires two sweeps of memory so it would be extremely slow. If anyone can get a good single-threaded implementation for fluid mechanics, he can. So it does not appear to be off the table yet.

I already got a good single-theaded implementation, back in March, read further into the thread. It's four posts after the link, same page, same thread. And it's hardly "extremely slow", someone toward the current end of the thread said that two passes instead of one (same exact total arithmetic, mind you) is a reasonable cost for fixing the physics, and I agree.

Besides, I detailed how to optimize long pipelines in one pass, cutting out the second, without the second pass. There was also the other two separate ideas I gave, one about optimizing off-screen pipes, which would technically alter the physics, but potentially in a way no one would notice, and would potentially cut the fluid physics cost down to a small fraction of what it is, the other about freezing isolated pipes after they settle.

And depending on how smart the compiler and the CPU are, simply fixing the physics opens up the possibility of parallelization, for which there is a slight chance that there could be some parallel action even without having to explicitly code it. I hope rseding really reads and considers all of this stuff, I know it will work.

I did as much of the work as I could without being able to see the code, because I really want to see this fixed.

[Fatmice]

I would gladly help to come up with a better, yet still efficient system, in fact I spent a lot of time thinking about it, but I reached the limits of how much I can come up with without actually seeing the structure of the relevant game code, and thus knowing what limitations I have to work with, especially interaction with graphics. I would gladly come up with a better system that is very easy on the CPU cost, because computer physics models are kind of my thing. I'm kind of sick of having to place things manually and very carefully whenever I need the fluid physics to work right, and not starve random places of fluids while right next door there's too much fluid, not have to deal with strange imbalances whenever I don't do it manually, and still have to deal with lesser issues even when it is placed manually. Not to mention that the fluid physics are just kind of ugly the moment you look a little closer than the smooth flow animations in the pipe windows. But, rseding has no intention of fixing it from what I can tell.

I was privy to the C++ code snipet for the fluid flow, which is certainly not some small code, which I can not disclose, which haven't changed since a long long time. Sorry. But suffice to say, it doesn't illuminate any more than what's already gleaned from in-game experiments.
Regarding Rseding91, I spoke to him very recently, just a few days ago, maybe 2 days ago, and he is still committed to seeing the fluid code overhauled. It is not a "priority" at the moment as bug fixing is more pressing. I have faith that it will likely be visited as they polish the game for 1.0, another word, probably in 0.16. What it will end up is anyone's guess but I can say with some confidence that Rseding91 is partial to the way fluid flow works in Thermal Expansion mod in Minecraft. The optimization pass that they did for belts will be applied to pipes. Essentially, all pipes are like underground pipe. They have an input and an output. Straight stretches will be indexed within the pipe array but do not get updated per index for pressure, only animation. The pressure fall over a stretch will be calculated by the distance (# of indexes) between input and output and the amount fluid that models that gradient will be written to the pipe index within the pipe array. Junctions will be handled specially such that order do not matter. How? I don't know.

[Rseding91]

The system I want to implement requires first that pipes be buildable without automatically connecting to every adjacent pipe. Once we think of some nice way to make that work it's quite simple to do the rest:

• All connected pipes act as one large "fluidbox". Pumps would be excluded from this merged set.
• All outputs for the merged set are recorded - outputs being things that consume fluid (assembling machines, pumps, mining drills).
• The merged set can only ever have 1 fluid in it at a time
• All things that input fluid simply do standard flow logic into the merged set as if it was a large fluidbox.
• Each tick the merged set takes the total set volume and the amount of fluid in the set and does flow logic to the outputs using the volume and amount in the set to determine flow speed.

In that way the number of pipes in a given set doesn't effect the flow calculation costs, all outputs get an even amount of fluid no matter how they're connected, and you don't have weird flow problems based off build order.

Now, I don't know if that's going to happen - it has some drawbacks like not having a defined fluid flow direction but (to me) the benefits far outweigh the loses.

[BenSeidel]

the benefits far outweigh the loses

If I can build more steam engines then I 100% support this change

[Mehve]

That would be awesome. Would totally eliminate a lot of frustation with fluid distribution at high flow rates. Sounds like it would also have the potential to eliminate the inability to lay discreet pipes next to each other.

[MeduSalem]

Wow that sounds nice, Rseding91...

... almost thought about suggesting something similar when I saw XKnight's update to the Original Post... by using a directed graph or so which determines what/where are all the inputs and what/where are all the outputs and the pipes in between would be just acting as one large pool (the merged set as you call it) that gets fluid added to by all the inputs and fluid substracted from by all the outputs... and the directed graph would help to determine the coarse flow direction only for graphical aesthetics.

And that directed graph would only get updated if something is changed on the configuration (more pipes/inputs/outputs).

[vanatteveldt]

Excellent post, thanks for all the info!

I am trying to figure out .15.11 nuclear power design, due to the heat pipe fix/nerf we now seem to need to use steam pipes rather than heat pipes to transport energy over longer distances.

I am working in 8 exchanger blocks that consume/produce 8*103.1=825 water/steam per second. The number 8 is nice since reactor logic goes in units of 8/16/32 and 825 water/steam fits in a single pipe over longish distances.

Am I correct from your post that I need a flow of 825/60=13.7, so I should be able to have 245 pipes between pump and exchanger and between exchanger and turbine?

If needed, can I increase this by sticking in a pump halfway?

Suppose that I want to transfer double or quadruple that, so I would need two/four pipes. Can I just put them right next to each other (i.e. with interconnections), or should I try to keep them separate?

[XKnight]

Am I correct from your post that I need a flow of 825/60=13.7, so I should be able to have 245 pipes between pump and exchanger and between exchanger and turbine?

251.9 pipe segments is the max distance for steady 13.7 units/tick flow.

This number is correct if your build meets all these conditions:
- input pressure should be 100%. So you have to push 13.7 units/tick in the first pipe segment in string. The simplest way to do this is to use offshore pump or regular pump.
- output pressure should be 0%. Just attach another pump to the last pipe segment.
- you have steady flow. This means the entire string shouldn't have any additional liquid production/consumption.

Putting it all together, you have to use a pump every 251 pipe segment.

If needed, can I increase this by sticking in a pump halfway?

Yep, using a pump every 125 segments will achieve 17.1 units/tick flow.

Suppose that I want to transfer double or quadruple that, so I would need two/four pipes. Can I just put them right next to each other (i.e. with interconnections), or should I try to keep them separate?

If you want to transfer liquid efficiently you have to use underground pipes, because they are counted as a regular pipe segments but have 5.5 times bigger max distance (also you wouldn't have any space for interconnections ). From my experience, you can freely use interconnections if and only if strings have approximately same pressure, otherwise two strings will interfere and cause pressure drop.

[vanatteveldt]

Am I correct from your post that I need a flow of 825/60=13.7, so I should be able to have 245 pipes between pump and exchanger and between exchanger and turbine?

251.9 pipe segments is the max distance for steady 13.7 units/tick flow.

This number is correct if your build meets all these conditions:
- input pressure should be 100%. So you have to push 13.7 units/tick in the first pipe segment in string. The simplest way to do this is to use offshore pump or regular pump.
- output pressure should be 0%. Just attach another pump to the last pipe segment.
- you have steady flow. This means the entire string shouldn't have any additional liquid production/consumption.

Putting it all together, you have to use a pump every 251 pipe segment.

If needed, can I increase this by sticking in a pump halfway?

Yep, using a pump every 125 segments will achieve 17.1 units/tick flow.

Thanks for these answers!

As said, I am aiming to have heat exchangers and turbines potentially (relatively) far from each other and from a water source.
When you say "place a pump just after the last pipe segment" to make sure output pressure is 0, do you mean a pump just before the turbines to pump the steam towards the turbines, or a "pump to nowhere" after the turbines? I'm assuming the answer is the former, because the latter makes no sense, but with factorio fluid mechanics I don't generally make assumptions

So I guess the ideal setup would be:

|-Offshore pump--> [long water pipe] --pump--> 8 Exchangers --pump-> [long steam pipe] --pump--> 14 turbines

I.e., an offshore pump leading to the exchangers via a long water pipe, with a pump just before the row of exchangers, followed by a (long) steam pipe with pumps just after the exchangers and just before the turbines; where each pipe can be 251 pipe segments, but if more are needed, another pump should be inserted every 125 segments.

right?

Suppose that I want to transfer double or quadruple that, so I would need two/four pipes. Can I just put them right next to each other (i.e. with interconnections), or should I try to keep them separate?

If you want to transfer liquid efficiently you have to use underground pipes, because they are counted as a regular pipe segments but have 5.5 times bigger max distance (also you wouldn't have any space for interconnections ). From my experience, you can freely use interconnections if and only if strings have approximately same pressure, otherwise two strings will interfere and cause pressure drop.[/quote]

OK, so if for reasons of placement two pipes touch at the same position along their path it should be fine, but doesn't give any benefits. And of course use UG pipes wherever possible

[azure_sky]

Great post, learn a lot from it.

Some questions:

Also, there are several other entities that can interact with liquids:
- mining drills with sulfuric acid (200 capacity, -100..100 pressure)
- assemblies, chemical plants, oil refineries (input/output - same mechanic as with pump (speed? - untested yet))

According to entities.lua, chemical plants and oil refineries have fluid boxes for each input(1000 capacity, -100..0 pressure) and output(100 capacity, 100..200 pressure). Assemblies have same input and larger outputs(1000 capacity, 100..200 pressure)
They follows the same rules.

example

Fill a pump with 200 water, and put a pipe between 2 assemblies.

Tick1:
Pump pressure = 200. Pipe = 0.
(200 - 0)*0.4 + 0 = 80.
Transferred 80 water units, new values 120 and 80.

Pipe pressure = 80, assembly A input = -100
(80 - (-100)*0.4 +0 = 72
Transferred 72 water units, new values 8 and 72.

Pipe pressure = 8, assembly B input = -100
(8 - (-100)*0.4 +0 = 43.2 < 8
Transferred 8 water units, new values 0 and 8.

Tick2:
Pump pressure = 120. Pipe = 0.
(120 - 0)*0.4 + 10 = 58.
Transferred 58 water units, new values 62 and 58.

Pipe pressure = 58, assembly A input = -92.8
(58 - (-92.8)*0.4 + 10 = 70.32 < 58
Transferred 58 water units, new values 0 and 58.

So all remaining water goes into assembly A.
the water in assembly A : assembly B = 192 : 8

Also it seems that fluid boxes update order has changed in 0.15


They two build have different water level, but the difference between pipes is same.
(the reverse build order doesn't show flow in debug mode, strange)
It appears that newer connections will get update first.

[super_aardvark]

Common mistakes
[...]
- pumping into entity with high zero-pressure
[...]
- pressure-ignoring pumping into low zero-pressure entity
Pressure-ignoring pumping should be targeted on higher zero-pressure entity, because later natural pressure difference may be used for free.

So.... which is it? Pumping is always a mistake?

[4xel]

Common mistakes
[...]
- pumping into entity with high zero-pressure
[...]
- pressure-ignoring pumping into low zero-pressure entity
Pressure-ignoring pumping should be targeted on higher zero-pressure entity, because later natural pressure difference may be used for free.

So.... which is it? Pumping is always a mistake?

I think it can be logically justified : if you have to pump, you rather should do it into low zero pressure, and using low zero pressure, you sometimes don't even have to pump. But yeah, the formulation is disturbing. Since entity with low zero pressure are consumers, unless you plan to replace pipes by boilers to increase flow, which, needless to say, is higly impractical (requires a pumping station for each turn, and each crossing!), you have, with very few eception, to pump into high zero pressure.

More generrally, I think his "common mistake" are mostly irrelevant in practice, because if you produce less liquid than you need, that is the problem, and assuming you produce more than you need, it is really easy to achieve > 0 pressure on large distace even without pumping. The only practical case where it could matter is if you have to transport liquids over long distances (typically hundreds of pipe sections, so tens to hundreds of chunks, using underground pipes), you could potentially save one pumping station (usually one pump I guess, with the new pump stats) by directely inserting into the liquid consumer and avoiding pipe between consumer (AFAIK, only boiler chaining allows this). It is worth noting that in such case, you could also have spaved one pumping station by moving the liquid consuming complex closer by one of its length, so it's not a full pumping station spaved, more like a few tens of tiles. All of that requires settings with really scarce water, maybe spawn area only, and that, for some reason, you decided to put a steam plant far away from water, at a distance where you typically already have train systems and where an extra pump is inexpensive. All what I've said also applies to pipes between boilers, which, under normal circumstances, are not a mistake.

Now the useful tidbits may be that pumping from pipe to liquid consumer is useless (although a pump can be used as a valve), and the advice about not pumping from low capacity entity (or into actually) meaning in particular than for throughput greater than a single pipe can hold, a single pump can handle several pipes but can only do so if the pump is connected to a tank rather than directly to a merged pipe (max input flow of pump is 200 / tick, twice the capacity of a pipe, max output flow is 0.1 * output_entity_capacity + max_pressure differential * 0.4, so even with boiler and assuming an irrealistic steady 400 pressure diff, the max is 180, so tanks really are needed). But several pumps are not too bad either.

If anything, I would say that the most practical advice would be : do not bother pumping until you have to transport more than hundreds of liquids per seconds over more than hundreds of tiles (and then use this page to figure things out).

[4xel]

Here is a simple article that I found in about 10 seconds of googling that sums it up reasonably well. The key point here is that pressure is always a vector, hence it can never be negative, but instead it refers to the relative direction to which pressure (force) vector is acting, ie is it an inward force or an outward force. It's a complex subject, but it is possible to build systems that really do pull and in no way can be interpreted as pushing fluids from one region to another (as classical pressure modeling dictates). These systems are generally referred to as having negative pressure, to distinguish it from systems where liquids move due to a pressure differential.
http://discovermagazine.com/2003/mar/featscienceof

Also, Just because a term may be used to describe something else, like a negative pressure room, does not mean that it has another meaning in another context.
Anyone know the blackest object in our solar system? Answer: it's the sun.

Sorry for the out of topic, but by no means pressure is a vector. Pressure is a scalar, as confirmed by the wikipedia article, and by no mean the article linked explicitely questions this definition, although at some point it makes an infortunate mistake about pressure being a force. Also, the article does not say pressure can't be negative, pretty much the opposite, and gives the signification of negative pressure.

Now, what matters is the effect of pressure, namely the pressure force, which is a vector, but is obtained by taking the gradient of the pressure and summing it over the surface the pressure applies (or pressure differential, differential being easier to understand as a vulgarisation term, but the mathematical object behind is broader and more abstract than its particular case, the gradient).

In my understanding, pressure is not a physical thing, only a mathematical tool to describe forces, pretty much like acceleration field can describe the movement of an object without any physical consideration of what caused the forces accelerating the object. Pressure is obtained by choosing a zero (eg atmosphere) and integrating the forces you want to describe with it (reverse operation of the gradient). And pulling force may require negative pressure. As a matter of fact, you could replace all readings of pressure by themself minus a gazillion and still describe the same effect, as the gradient it generates stays the same (and all the pressure would be negative). If you pull a charriot, by no way you are limited by the atmospheric pressure and the surface of the rear of the charriot to pull it (and, as convoluted as it may be, it can be described by pressure).

Now, if you start specifically talk about gas pressure, or pressure caused by X, you can start essentialize pressure and say it is a physicall thing, but I don't expect pressure caused by liquid has anything to do with, say, magnetic pressures, except for their effect. And some essentialized pressures can be negative, some can't. For some essentialized pressures, the sign of the pressure has an actual meaning (eg taking vaccum gas pressure as 0), sometimes, pressure can only be defined up to an arbitrary constant, and negative pressure are not an issue, and not even meaningfull.

The article goes in great length with a lot of essentialized pressures that are bound to have different meanings, save for their effect, which is all the word pressure entails : "each man's negative pressure was a stranger to the other" (contradicting your last paragraph). I think Turner final words pretty much tells that the pressure refers to the force it generates, reguardless of the cause. Now, I really don't like this article for spending so little time on this final point and doing it in a much confusing way, stating that "it[negative pressure]'s direction—an inward, imploding, or contracting force, rather than the outward-pushing force typically defined as pressure", which is technically outright incorrect. The technically correct and non confusing statement should have been "negative pressure implies the direction of the related force—an inward, imploding, or contracting force, rather than the outward-pushing force typically described by pressure", because mathematically, pressure is not a force, it's (implied) gradient is (or kind of, it's a force/area).

As for the blackest visible object of the solar system, I know of no scientific definition of black, which is even less definite that regular colors. Black is precisely a term used to describe different things and that has widely different depending on context. If we define black as emitting or reflecting non visible light, the sun is the blackest object of the solar system, but also, black holes are anything but black. If we define black as non emitting nor reflecting visible light, which is the closest definition to the usual meaning of black, and is the one used in "black holes", then the sun becomes the less black object of the solar system.

[XKnight]

Common mistakes
[...]
- pumping into entity with high zero-pressure
[...]
- pressure-ignoring pumping into low zero-pressure entity
Pressure-ignoring pumping should be targeted on higher zero-pressure entity, because later natural pressure difference may be used for free.

So.... which is it? Pumping is always a mistake?

We have two different kind of pumping:
- regular pumping (using pump and electricity)
- various objects with "silent" pumping ability (boiler/exchanger output, offshore output, assembler output)

The core idea of the second tip was to encourage usage of the internal storage buffer in those entities. Why? Because it is free for us.

Simple example: Heat exchanger's output fluidbox has 200 capacity and 100..300 pressure.
Because upper pressure is very high, exchanger efficiently "pumps" into pipe (0..100, pressure diff 200..300) and turbine (-100..100, pressure diff 300..400). Flow will be bigger (because pressure diff is bigger) in case of pumping into turbine, but this flow will be limited by the next segment (because pressure diff turbine-pipe is -100 and turbine-turbine is 0). As a result your theoretically possible flow will be big in the first segment and small in the second segment, and resulting flow is the lowest among them.

Opposite happens when exchanger is connected to pipe (0..100): first segment has lower flow (comparing to the turbine first segment) and second segment has bigger flow (due to natural pressure difference: pipe-turbine = 100). Resulting flow will be bigger than in the first case.

Internal storage buffer will be more filled in the second case because it has to overcome bigger resistance in the first segment, and in the first case buffer is less filled because natural diff is used there.

Note, that this is an imaginary build and important properties were neglected on purpose to simplify explanation (like flow decay in turbine, or different turbine and pipe capacity).

So the original tip can be rephrased as "if you have an internal storage buffer try to keep it always full, because this means you are using it efficiently".

Regarding the regular pump...
Recommended build depends on what do you want to achieve.
If you want to have big flow on the short distance = apply natural pressure diff.
If you want to have lower flow but with bigger distance = use natural pressure diff somewhere in the middle.
But keep in mind, if you won't be able to keep your big flow you will lose natural pressure diff without any benefit.

[MBas]

I am always gratefully suprised of "quasi--physics" in factorio when i study any of its properties more closely. I wonder if its just coincidence or geniallity of the develompment team (maybe combination of both). My meaning of "quasi" is fact that a fundamental laws in here are little bit far from the real physics, however, its implications are pretty close!

Lets see how factorio fluid model correspond to the one in the real world.

Factorio model

Regarding to model flow = (preassureA-preassureB) 0.4 + 0.59 previous flow vs. flow = (preassureA-preassureB) 0.4 + 0.1 *
capacity of the instance where we always choose lesser value, we obtain following diagram

factorio.png (7.3 KiB) Viewed 12219 times

X-values: relative preassure difference (or 1/(pipe length) so the last value 0.5 correspond to pipes of lenght 2)
Y-values: flow
black: first formula (used for low preassure diference and long pipes)
blue: second formula (used for high preassure difference and short pipes)
red: final model

Real physics

There is no relation to instance capacity or something like selection between effect of filling instance against flow momentum in real phyics. We differentiate two types of flows in pipes: laminar and turbulent. There is also a moment of "switch" between of this types of flows regards to Reynolds number. The repulse force is linear in velocity in case of laminar and quadratic in case of turbulent flow where turbulent flow is applied for higher flow. Ragarding to this facts we obtain (dont take scales of the diagram much seriously, its just question of unit choises)

reality.png (7.62 KiB) Viewed 12219 times

black: laminar flow (applied to low velocity cases)
blue: turbulent flow (applied to high velocity cases)

There is a little difference, however the red lines (in which are we interested) are almost the same. The scaling of the flow against pipe-length is just little bit modified in case of very short pipes but still pretty close to the real behaviour.

[Laogeodritt]

I am always gratefully suprised of "quasi--physics" in factorio when i study any of its properties more closely. I wonder if its just coincidence or geniallity of the develompment team (maybe combination of both). My meaning of "quasi" is fact that a fundamental laws in here are little bit far from the real physics, however, its implications are pretty close!

That's a beautiful little approximation! It's always nice seeing games implement efficient but perceptually realistic models like this—especially when you're usually limiting yourself to small, linear difference equation models.

I'd usually expect discrete flow-rate steps, hard length limits/constant flow rate, a purely linear time-independent model, or something similarly simplistic for this kind of mechanism...

[Pin-Lui]

i came here to read about fluids, now im confused.
i think you need phd in factorio to completly understand what is going on.
all i need to know is how do i need to build for best throughput.

source----->tank------->production

so do i need to build the sheme above in a order to get best throughput?
when i delet pipes somewhere between, do i need to replace everything afterwards?

[Laogeodritt]

i came here to read about fluids, now im confused.

Sounds like you're trying to understand the basics of how to do fluid stuff in Factorio?

If so, you're in the wrong thread, since here we're discussing the details of the models that Factorio uses to simulate its fluids, and how that affects throughput. This is advanced and affects people trying to get very high throughput for major production situations; with 0.15 you don't have to worry about hitting limits when just starting out.

I suggest you read the official guide on fluids handling to start with, for the very basics, along with Setting up oil processing on the wiki. From there you could seek out other oil processing designs on the forums or YouTube videos.

Questions not related to fluid mechanics/models should probably be in their own thread, rather than here.

i think you need phd in factorio to completly understand what is going on.

This is some pretty squarely undergraduate-level physics/engineering, at this level; even 1st-2nd year. That's if you want to understand in detail. Hobbyists can pretty easily grasp these ideas given time and some maths/science background, similarly to hobby electronics.

[4xel]

i came here to read about fluids, now im confused.
i think you need phd in factorio to completly understand what is going on.
all i need to know is how do i need to build for best throughput.

source----->tank------->production

so do i need to build the sheme above in a order to get best throughput?
when i delet pipes somewhere between, do i need to replace everything afterwards?

In addition to Lao great answer : if you're nowhere cose to fill belts of plastic, pipe throughputs should not be the issue. A single pipe has a massive throughput, in the same order of magnitude than belts over long distance, and much greater over very short ones, and oil products, for example, are needed in much smaller quantities than ore products. Even when pipe throughput might be an issue, it can be detected without doing maths : if your producers are backed up (producing less than they could) AND your consumer starved (consuming less than they could), then you have a throughput issue (applies equally for belts and pipes).

If you have throughput issues, the first fix is to use underground pipes instead of normal pipes for long distances, and I believe adding a tank buffer midway might also help. Then, it becomes necessary to add a pipe in paralell, add a pump once in a while, or use tank-wagon or barrels to transport large quantities of liquid over long distance.

As of 0.15, one pump can deal with one pipe (previously pumping stations were necessary). The only mathy thing to know is that, if you choose to use pumps, you should space them evenly, as the longest segment of pipe without pump will impose its throughput to the rest of the pipe. This thread gives you tool to predict the throughput of a given configuration of pipes/pumps, but it does not says which configuation is the best, and actually, there's none, the distance between two pumps, if any, is up to personal preference.

Unlike belt, you seldom need to upgrade your pipes, so there is little incentive to know the exact through put of a pipe. If you really need insane throughput, transporting liquids with trains should be an affordable and easy to set up overkill for all your needs.

As for the order of placement of pipes, it only impairs the delay, not the throughput : if you place 100 pipes (about 20 fully zoomed out screens, assuming underground pipes) in the worse possible (backward) order, the pressure will take 1 second and a half longer to establish than if placed optimally, and will also take 1.5s longer to go down if the production is stopped. But the steady state throughput should be the same, if I'm not mistaken.

[Aru]

...

• All connected pipes act as one large "fluidbox". Pumps would be excluded from this merged set.

...

Aw well that would be a shame. Watching the fluids flow and bounce through the pipes is one of those moments where you realize how awesome this game really is. That plus the beautiful sprite animations all over give a sense of attention to detail that is quite impressive. And as I detailed, you could preserve the existing fluid mechanic concept, fix it, and still add a couple long-pipeline optimizations at the same time... if the posts were too confusing, I could elaborate.

The optimization you mention here, is one of the ones I suggested in the linked thread, except I suggested it only for off-screen pipelines instead of all of them. (Which is still most of them.) The other suggestions were to freeze isolated / inactive pipe networks once they settled, and the far more detailed one was about changing the implementation of the mechanic so that placement order didn't matter, still only one sequential pass was needed per pipeline, and the underlying mechanic wasn't changed at all, and with the same total amount of arithmetic and assignments in the fluid loop.