Friday Facts #260 - New fluid system

[Stlyau]

Interesting FFF! Great write up.

We are still considering using different pipes for different shapes, which would allow two parallel separate pipes etc.

Please do add this feature, flow control is a mod which adds these and it truly does improve fluid handling, especially in the later part of the game where the pipework turns in to the proverbial spaghetti. We've all been there - you need to sneak a pipe through a gap but can't because it'll connect to the pipe next to it and different fluids would mix..

This is sorta what I was getting at for the T-junctions. Pipes of different materials would be another way to go as well, similar to belt weaving with different tier undergrounds.

[Vxsote]

As a software developer with a degree in aerospace engineering, I do have some understanding of the nature of this problem from both the "make it real" and "make it perform" viewpoints. I tend toward wanting more realism in the simulation, but I also understand the need to have a playable and enjoyable game.

So some of the things you've mentioned I like. I am quite happy that you have rejected the "nuclear option" because I think that would be incredibly ugly and terrible (for the reasons you mention). You can increase performance continuously by removing parts of the game, until there is nothing left! Obviously you wouldn't do that

The approach of trying different simulation techniques to arrive at something that at least appears realistic, while reducing the complexity so that it still performs well, I think that's the right idea.

About the physics, and the system being too heavily discrete, I believe I understand what you are saying here. However, I disagree that the physics are "not really applicable". But absolutely, if you try to simulate a dynamic system in discrete steps that are too large, Bad Things will happen. Running the simulation in more iterations of shorter time is usually an answer, but is the opposite of what you would like to do for performance. Ignoring pressure entirely though, I think that might be too much of a simplification. Examples like the 5-way split can really only be answered "correctly" by considering pressure, although I accept that your solution, while somewhat arbitrary, may be "good enough".

There were also a few mentions of gravity and elevation. This is probably easier to approximate as well if you leave pressure in the mix, but for a first pass, treating the entire map as flat would probably not be awful. But then, I also don't think that's what you were talking about when you mentioned "elevation functions" in the FFF.

Something I noticed right away in the discussion was that the order of simulation of each entity matters, when clearly it should not. I think there could be some ways to address this - perhaps each entity's update should only depend on the pre-update state of its neighbors. If you decide that the "speed of sound" is less than an entity-per-tick, this might actually be reasonable. But the large discrete step problem might also be a major issue. You might also be able to apply some linear algebra techniques to solve the entire system at once, and try to make use of existing libraries that are optimized for that.

Another thing you mentioned was throughput loss over distance. You called it out as a problem, and to the extent that the throughput loss is unrealistic and unreasonably harsh, I agree. However, fluid flow through a pipe IS a function of the length of the pipe in the real world (see this article if you haven't already). This is due to friction. I would not expect you to model this in detail, but I think it would be very reasonable to decrease the max throughput of a given segment based on the length. Along these lines, I would like to see the viscosity of the fluid matter. Oil has high viscosity and should be harder to move around than water. Perhaps even differentiate between the grades of refined/crude oil, and give players more things to consider when deciding what and where to refine.

Lastly, something else that you may or may not have already considered: This sort of simulation lends itself to a high degree of parallelization. You also have a limited number of inputs and outputs. To me, this suggests that you could do all of the heavy simulation in the GPU. You would only need to transfer the inputs and outputs once per tick, and leave the intermediate info in the GPU memory. You also might be able to run many iterations per tick, solving part of the big discrete chunk problem. The biggest issue I would watch out for would be making sure the results are consistent for everyone in a multiplayer game. (Edit: Also, you could potentially do some visualization of flow data from GPU memory without bringing it back to the CPU first.)

[toxinate]

Signed up on the forums to post this. Already posted on reddit:

" Another proposal was modelling like an electric network. Fluid flow is a popular analogy to their workings, and they do have a lot in common. The great thing about them is that they precisely model the flow branching and it could work out of the box. What it does not allow though is to limit the flow - one wire can, theoretically, run any current, but not so for the pipes, and we don’t want one pipe to be enough to supply whole factory. The limitations could be added, but that would, again, kill it with complexity. "

Isn't that what resistance is for?

I would've thought an electrical network would be best for this type of thing. Each segment would contain a resistance value (based on number of pipes, still treated as one segment as u have resolved to do), and then use kirchoff's law at each intersection to evenly split the current (flow) based on total effective resistance of each branch (thevenin equivalent).

The source of fluid would be treated as a voltage source (pressure) and voltage (pressure) would drop as you extend through the pipe network.

The neat thing with this approach is you can calculate the parameters for the pipe network once (when it is created) store that for the entire network and instantly do your algebraic manipulations of V=IR every tick.

Fluid volume would be represented by voltage value at any given pipe segment.

Total capacity of any given pipe/tank would be treated as a parallel capacitor.

Good work otherwise!

Source: Am Electrical Engineer

[Pinga]

I'm afraid these improvements don't fix most of the current issues with fluids, while potentially making UPS worse in some situations.

Let's talk about the worst cases: massive nuclear setups, like this: https://i.imgur.com/LCZa1BB.png, or oil: http://i.imgur.com/9J91Ger.jpg.
These layouts consist practically of only intersections, from hundreds to thousands of machines connected to the pipe network. Rarely straight segments. These layouts are currently the cases where UPS matter, and the new implementation will potentially make UPS worse in these cases.

Besides, it doesn't touch some conceptual issues with fluids.
It's very hard to figure out how much throughput a pipe have. Sometimes you can move 1200 liquid per second, but add a few extra pipes, now it's only 1000. Which might be fine, if that information was shown anywhere. The game doesn't communicate much about what's going on inside those pipes.
When I build my starter 60 SPM base, I know I need 2 yellow belts of iron for the Military Science, because I know exactly how much each belt can move. When I build an endgame oil processing plant, I have no idea how many pipelines I will need. What I do is put pumps every 15 segments or so and hope for the best.

In short, if a system is complicated enough that even our most studied Discord users have a hard time explaining, it's probably not very good.

Lastly, the whole FFF focus on how intersections don't work as intended. Off the top of my head, that will only be an issue if you have if you have multiple machines consuming more that the pipeline is producing, so one machine can take everything while the other is starved. It's not different than a belt serving only the first inserters in the line, and as a player, you either have to increase production, or use a balancer to make sure all machines can be served.

My point is, bad intersections will mostly happen if the player is did something wrong, by not producing / balancing enough. It's nice to have fixed, but the new fluid system prioritizes this way too much, while neglecting far more pressing issues, mentioned above.

[smurphy1]

In the last example picture why can't some of the segments and junctions be merged further resulting in fewer entity updates? Consider a scenario where the segment on the left is attached to some fluid producer and the 5 segments on the right are each attached to a fluid consumer.

pipes.png (191.4 KiB) Viewed 8138 times

If A and B are each connected to a fluid consumer then junction 1 and segments A and B can be merged into 1 segment that has an input at junction 1 and where the output is split between A and B. The same can be done with segments D and E and junction 3 and from there you could possible merge the top and bottom segment with segment C and junction 2. You could even pre calculate the even distribution when merging these segments. When you merge A and B on junction 1 you know you need to split 1/2 to A and 1/2 to B. Then you do the same when you merge D and E on junction 3. Then when you merge segment C with the top and bottom segments you know that 1/3 would be distributed to each segment which means you can multiply the existing distributions by 1/3 giving you A) 1/6, B) 1/6, C) 1/3, D) 1/6, and E) 1/6.

[tk0421]

something we need in pipes is automatic backflow protection, pipes need to be one-way only naturally. at the very least, every X length of pipe should have a manually adjustable direction control, without adding a new inventory part.

just my 2c/wish

[Philip017]

handling mixed fluids, this will be a nightmare as all pipes to the next junction will have the fluid, but if you can solve the 0.01% remaining by use of a pump to remove the fluid this would be beneficial. or you could simplify the process by storing all the mixed fluid at one of the junctions removing the end and the junction pipes could clean your pipes of the mixed fluids. one way valves would also be a really nice addition, pumps kinda function like this, but it would help with the division of fluids as well imo, but i guess that is what mods are for.

although i see the straight pipe calculated only once being beneficial for long pipe runs, i see the splitting calculation at each junction also being more of a hog for in base setups where we have 500 refineries, 1200 chem plants, and more assemblers all having junctions to each input/output. the straight pipes not having to recalculate is great and all, but splitting the pipe volumes equally is not that big of a deal. just make sure you have enough fluid and you're good to go. so recalculating at every junction seems unnecessary, and will likely be an even more cpu hog.

make sure you test out your proposed changes on a proper mega base before you implement them, or you might be disappointed.

i am partial to it being similar to the electrical network, instant transfers, and unlimited through put, then you can split the producers and consumers evenly.
if not, a proper through put number needs to be visible on the pipes so we can see just how much we can push down it or pull from it before it breaks. the current system is vague as best, the line on the pipe is not enough, we need hard numbers.

i know people that have given up after red and green science because oh it so much work to do blue, why? because you have to set up oil, and that becomes a mess the first time you set it up, contaminated pipes, unknown through put, and the hog on power and pollution it generates makes the game suddenly harder. for me i am used to it, but it's a hard sell for some of my friends. yes you have made blue easier and i applaud that, i really appreciate those changes.

the other idea of spawning all fluid calculations on a separate thread is also a nice idea, perhaps this could also be used on any set of entities that hog cpu time.

[Elok]

About the pipe calculation.

Why don't you do the calculation per group instead of one calculation per piece of pipe?

Example,

To make thing simpler, let's say each pipe can hold a total number of 100 'unit' of water

Group A have 22 pipe total, 2200 unit total.

You fill the first pipe with 100 unit of water. The group A have 100/2200 unit with water. So each pipe need 1/2 unit each, in other words ~4.5/100 unit of water.

Of course, if you do that instantly, you will lose all the animation, but you can always update pipe value smoothly. In the end, it's 1 calculation per group and 1 value update per pipe.

And you'll lose the "wave" effect that we see on the FF. But, honestly, who noticed such wave feature existed? It's a gimmick that doesn't bring much to the game and is very harsh on the CPU.

[Rhamphoryncus]

For tainting I lean towards the other extreme: once oil touches a network of pipes it marks that entire network as "oil only". It would be impossible to add water to it or I suppose even to connect an existing water network. That leaves fluid tankers explicitly as the only multi-fluid entity.

For flow my current favourite is a belt-like model. Packets of fluid "randomly" picking a route to a hungry destination. Considerations:

• Flow can go infinitely far. A half-full pipe will always be a half-full pipe.
• Pipe throughput is limited exactly how belt throughput is
• Segments would actually have two modes. "Strong flow" is the normal mode when one end wants a lot of fluid, that's the belt-like behaviour. "Weak flow" is when neither end has much demand so the segment just wants to smooth out a bit for aesthetics.

[Homepage]

I may have a suggestion for a slightly different model, probably (I hope) more efficient, although arguably more complicated:

Each pipe system (entities connected by pipes or just a mangle of pipes) would be simulated separately, therefore their simulations could be run in paralel.

As in the solution you have suggested, a pipe system would be split up into segments; each segment would be either:
1. a sequence of pipes without junctions that connects to other segments
2. a junction
3. a group of directly-connected storage tanks (treated as low-priority drain, see below)
4. an entity that would be either a source or a drain for the pipe system at hand (during a single tick a source/drain can be either active xor inactive - e.g. a Rafinery only drains oil(+water) at the start of a production cycle and produces oils/gas at the end of the production cycle).
5. a dead-end pipe/storage tank sequence (treated as low-priority drain, see below)
Note: a pump is an entity connected to two pipe systems in this model: a drain for the system at the input, a source for the system at the output.

Each segment has its throughput (given by the type of the entity) and capacity (sum of capacities of all entities in the segment).

A single pipe system would need to maintain the following information:
1. an oriented graph of segments, with edges always leading from drains to sources (A* or Dijkstra should do the trick for initial computation when loading a game). each segment needs to track a list of neighbour segments that lead to sources.
2. for each source: a list of drains and the ratio for each drain using which the source's production would be split if the source would be the only source in the system and all drains would demand the same amount of liquid at the same time/rate.
3. fullness-status: either not-fully-filled (not all segments are filled), or filled (every segment is filled to the max).

The first and second would be updated incrementally whenever the player or a bot would connect additional entity or remove a connected entity. The third will be updated as a part of the simulation every tick.

Simulation would work as follows:

1. If all drains are inactive and the system is filled, skip this tick.
2. fill the requirements of all active high-priority drains using all active sources (spread the available production equally), mark all fully-satisfied high-priority drains as inactive. Mark all drained sources as inactive.
3. repeat 2. for low-priority drains.
4. for all active high-priority drains: for each neighbour leading to a source, make a reservation for how much you need to drain to satisfy the current need. Reserve the full current need with every neighbour leading to a source **without** any dividing. Note: while iterating over neighbours: reserve only up to the amount that is currently present in the segment, ignore reservations made by other drains (this is fine since no factory can currently request more than a 100 units in a single tick).
5. for all active high-priority drains: get a list of all neighbours that have only a single reservervation (therefore made by the drain at hand): drain them equally to satisfy the needs of the drain at hand. Mark the drain as inactive if the need has been fulfilled.
6. repeat 5. for neighbours that have multiple reservations, but first divide the reserved amount to drain by the number of reservations. Mark the drain as inactive if the need has been fultilled.
7. repeat steps 4-6 for the right-now affected segments, working your way towards the sources one "layer" at a time.
8. if all high-priority drains are inactive, repear 4-7. for low-priority drains.
9. if all drains are inactive: depending on whether we want "waves" (harder to compute) or a simple&fast solution:
9.a - waves: for each segment make a reservation with every neighbour up to the neighbour segment's capacity to equalize the liquid level with the neighbours, but make the reservation only if the neighbour has more liquid that the segment at hand. The target liquid level for each segment is the average liquid level of the segment and all its neighbours. In the second pass divide each segment's reservations towards neigbouring segments by the number of reservations in the neighbouring segment and take the liquid. (this might be possible to "smooth out" by iterating on the "desirable liquid level" computation more than once, using the averages for each segment calculated in the previous iteration).
9.b - simple&fast: sum all the liquid in the system including the unspent liquid in sources, distribute equally (of course, ceiling to 100 for pipes and dumping the extra into storage tanks).

This system should have the throughput of pipe systems constant for any distance or direction and does not require you to do any sorting for every tick; the complexity should be O(n) for n being the number of segments. A funny side-effect of this system is that not only are the sources pushing the liquids into the system, the drains are actively pulling the liquid towards themselves, sucking it out of the system.

[Xterminator]

It's been a while since I've posted here but I felt like I needed to add to this discussion.

I was thrilled when I saw the title of the Friday Facts, as I've been anxious to hear about a fluid rework for a long time now. I was happy at first, but the more I read, the more of a problem it seemed. With the current proposed model, it is good that it would fix junctions to make the fluid act more intuitively through them, but it seems bad in nearly all other aspects.

The optimization to straight sections of pipes is fantastic and would benefit instances where people want to run a massive line from their oil outpost to their base without using trains. It would slightly benefit some parts of builds where you may have a couple straight sections, say from water pumps for example. However, it seems like it would make UPS performance worse in every other case.

The areas where UPS from fluids is the biggest problem is in oil builds and nuclear builds, and based on my understanding of the new system, it would do nothing to improve this, and likely make it even worse. If you look at pictures of oil or nuclear builds (see other peoples posts in the thread), there are very few straight sections that are longer than maybe 2-3 pipes lengths, and all the rest are junctions. So sense junctions are even more UPS intensive, I see this as making Nuclear and oil builds even worse than they currently are. This seems like a step backwards honestly.

Now, if you are able to do like someone else here suggested and move all fluid stuff to it's own thread, this would pretty much solve the issue. Hopefully you decide to and are able to do this for the 0.17 release or shortly after. Or use one of the other suggested simulations that would work better. Otherwise I see big oil builds and nuclear still being not viable for larger bases.

[RokRoland]

It's really cool that Factorio forums are these days the place where I see people sign up just so they can post their two cents on some topic that interests them - well, sort of doing the same here as well.

Thanks for the well written update, some things provoked thoughts so here goes:

- You choose not to use pressure as a variable in the simulation in order to simplify, it appears to approximate reality to some extent (good)
- A situation is described which is not resolved yet in the fluid containers, a flow from a container are based on pressure so using velocity appears to be thinking in reverse quite a lot
- To some extent, in order to apply pressure based calculation with fluid containers, you would need to define volume and height of the container (actually also for the pipes too!) in order to run some meaningful simulation (does this open also a can of worms with terrain elevations? Perhaps not required)
- I do not know if with your current simulation the pumps create velocity, probably, I would really think they impart pressure and suction (negative pressure), now I thought about discussing pump cavitation due to lack of fluid (let's really not)
- Is actually consumer imparting suction on a pipe (causing velocity) or does there need to be imparted pressure on the other end?

In the end, if you can get away with the simulation in a plausible without considering pressure, volume and potentially also viscosity (if you want to make different fluids work in different ways, also potentially affecting the transfer of mixed fluid with viscosity - I do not think you want to go into soluble fluids - then you have to account for it) I will raise my hat.

However, I still raise my hat due to this interesting writing and tackling the challenge of the fluid system. As final note, I don't think you exaggerate the need of thorough testing at all - I'd much prefer testing on the developer end as compared to weeding out the bugs as the end user.

As the final salute, I had some time set aside for playing Factorio this Friday night, however ultimately I decided to spend this time instead on reading the blog, pondering about fluids, then writing this reply, so good job to you - though my base is now sorely missing some refactoring of chemical plants.

[Zulan]

I carry this idea around for a while now - unfortunately I never found the time to implement a prototype.

Basic model

The fluid network is as a network of resistors and apply Kirchhoff's circuit laws. This goes in the direction of electricity network, but does not have the drawbacks mentioned in the text.

• all pipe-connected fluid entities form a single network with only one fluid
• pipes are resistors (no capacity)
• sources, sinks and tanks have some capacity
• pressure = voltage, sources / sinks have a high / low voltage
• fluid flow = current
• Storages have a voltage between sources and sinks, there could be implemented to connect or separate networks
• Pumps separate networks and have to buffer a certain amount of fluid
• Sinks/sources/tanks have a small internal resistor so that there is no short circuit

The implementation sketch

• Pipe-only parts can be simplified to a single resistor
• Applying Kirchhoff's laws result in a set of linear equations
• Maximum available fluid / fluid space are boundary conditions (this could be avoided by limiting minimum (internal) resistance and voltage difference)
• The equations can be partially solved using the static resistances
• Ideally, the remaining computations based on dynamic voltages/current limitations are very simple and compact
• The cubic complexity may require segmentation of very large networks such that you don't have to wait seconds to add a pipe somewhere

Gameplay implications

• pipes do not store fluids any longer, they only transport them
• you can still compute and show flow (current) at every point in the network
• the scaling of a fluid bus with length and width is intuitively proportional
• splits can be made fairly, but far away points will get less share realistically
• tuning the resistance of pipes will allow for arbitrary flows, underground pipes can easily have a flow equal to pipes of their actual length

I haven't figured out all the details, particularly about the scaling of voltages to allow emptying a tank even if there are a few pipes in between while enforcing a sensible maximum current. A relatively high internal resistance might go a long way. I don't have a full understanding about the computation requirements, but I believe common cases can be done very efficiently while uncommon complex cases may require segmentation to be reasonable.

[darkfrei]

Can you add blue and green columns to debug menu?

[Nova]

I'm pretty much okay with most kinds of pipe mechanics as long as it's fair - every connection of a junction should be equally filled with fluids.

For some added convenience I would also like to know about the system capabilities - how much fluid can my pipe deliver? Is this pipe system enough to deliver the needed fluids from A to B? Do I have enough water for my nuclear reactor?

[Jap2.0]

sooo on average, how many pipes do you need per section for every junction in a system for it to run than faster the old system?

More than 2 + 2/x pipes, where x is the amount of pipes connected to the junction.

In the last example picture why can't some of the segments and junctions be merged further resulting in fewer entity updates? Consider a scenario where the segment on the left is attached to some fluid producer and the 5 segments on the right are each attached to a fluid consumer.

If A and B are each connected to a fluid consumer then junction 1 and segments A and B can be merged into 1 segment that has an input at junction 1 and where the output is split between A and B. The same can be done with segments D and E and junction 3 and from there you could possible merge the top and bottom segment with segment C and junction 2. You could even pre calculate the even distribution when merging these segments. When you merge A and B on junction 1 you know you need to split 1/2 to A and 1/2 to B. Then you do the same when you merge D and E on junction 3. Then when you merge segment C with the top and bottom segments you know that 1/3 would be distributed to each segment which means you can multiply the existing distributions by 1/3 giving you A) 1/6, B) 1/6, C) 1/3, D) 1/6, and E) 1/6.

That's basically the nuclear option they decided not to use.

About the pipe calculation.

Why don't you do the calculation per group instead of one calculation per piece of pipe?

Example,

To make thing simpler, let's say each pipe can hold a total number of 100 'unit' of water

Group A have 22 pipe total, 2200 unit total.

You fill the first pipe with 100 unit of water. The group A have 100/2200 unit with water. So each pipe need 1/2 unit each, in other words ~4.5/100 unit of water.

Of course, if you do that instantly, you will lose all the animation, but you can always update pipe value smoothly. In the end, it's 1 calculation per group and 1 value update per pipe.

And you'll lose the "wave" effect that we see on the FF. But, honestly, who noticed such wave feature existed? It's a gimmick that doesn't bring much to the game and is very harsh on the CPU.

That's very similar to what they ended up doing.

While the new proposed system seems better, I feel it will only actually improve performance on edge cases. If you are at a point where you have ups issues, which is the case for nuclear on big setups for exemple, you rarely have long stretch of pipes, mostly lots of intersections.

Hi @Dominik, thanks for your 1st FFF. And obviously, thanks for this rework you have done.
I'm also afraid, as djnono is, that UPS issues are mainly arising in megabases, where intersections are everywhere, even in nicely thought up builds.

The solution you have is I think the best one you have without making the fluid pipes overpowered (electric system solution).

But I'dd like to suggest another aproach to the UPS problem of fluids in the late game. Objects early game are moved mainly with belts, but in megabases/late game, we all know, whatever optimisations you can do, belts will always have more drain on UPS than trains + bots combo. Fluid can be moved by pipes and trains but do not have a usable bot equivalent (lets not talk about barrels ).

Why cant we have a late game solution to moving fluids without pipes? Like bots replace belts? Barrels are not a real solution, as assemblers cant use barrels directly, the add the whole barreling/un-barreling problem, you have to move empty barrels arround,... Nobody likes barrels. Sorry

Why not have a new placable mini fluid tank: one square meter. They would act as requester chests for fluids. This object would be filled by bots (maybe a new kind of bot, specially for moving fluids without needing to use barels). And assemblers could directly pump from them if they are in there fluid inbox position. The new bots would just take the fluids from the big fluid tanks, and move them to the mini fluid tanks. Really, 'just' a requester/provider combo for late game fluid transportation over small distances.

Helicopters can move water IRL: https://i.stack.imgur.com/5oMG8.jpg , Factorio bots should be allowed to do as well

Wether you like my proposition, thanks for reading till here. Love yall, thanks for the great game you give us. Chears!

That's called barrels.

Can you add blue and green columns to debug menu?

It's already there

Why not drop the entire fluid network on its own thread, using the proposed system, and handle the impact on the main update thread with a 1 tick delay ?

See, when writing it I totally forgot about the multi-threading. Yes, things like this should be possible and hopefully we will get to it too.

Have fun convincing Rseding to let you do this.
Then again, performance...


Some questions:
Do pumps, assemblers, refineries, chemical plants, and offshore pumps count as junctions?
What about tanks with 2 connections?
What makes you think that this will improve UPS in actual UPS-intense setups?

[Suigen]

I'm all in favor of having Pipe be split into different items for each shape.
Straight, Corner, T, +, all as separate items and unable to automatically interconnect would be amazing; for QoL (allowing pipes to run alongside each other without cross-contamination), and for realism (what engineer in their right mind would ever purposefully connect water to oil to acid?)

One solution would be to keep the 1 Iron Plate => 1 Straight Pipe recipe and then add new recipes that allow you to change any above ground pipe into any other - ex. one for Straight to Corner would be ingredients: Straight Pipe and craft time, output: Corner Pipe.

Or you could have completely separate recipes for each, all being 1 Iron Plate => Corner, 1 Iron Plate => T, etc. This seems like less work, less clutter in the recipe screen, and easier for players to read, but I'd still like the option of changing pipe segments into each other on the fly since that's mostly how it works now, but I could also see myself getting used to having to have specific segments stocked up. (especially since we already have to do that with above ground pipe and underground pipe being separate)

[bobingabout]

damnit, you answered a heap of questions, but not mine.

[AcolyteOfRocket]

I hope you improve the system of laying pipes, the autoconnection system can lead to annoying mixing of pipe fluids.

While I understand you can't simulate multicomponent fluids, I would like to make a suggestion - when two different fluids mix in a pipe, blow the pipe up immediately. This will prevent mixed fluids spreading along a pipe, which we will have to dismantle anyway in order to fix the problem. Much better to blow the pipe the instant they mix and prevent further mixing - also the player doesn't need to hunt over his pipework to fix contamination, he can see the break where it happened.

I believe this will be a lot more user friendly than it sounds

[majesty2450]

Have you considered simply implementing a cache?

I would think that the majority of the time the fluid simulation will appear cyclic or have some sort of pattern to it, so the simulation results can be looked-up rather than calculated since they likely already have been in the past. Even the cache is likely to be reused because networks will likely be tiled.

Lets consider the fluid simulation algorithm as a pure function, where the variables are:

• Flow-Topology : Determines the forces applied to fluid by the various connected components of the network. AKA each pipe, pump, storage tank, or production building effects the fluid of the network in a static constant way, such as distributing, consuming, or producing it at a particular rate.
  • Changes are rare and mostly represent changes to a blueprint or entity.

• Pressure-Topology : Determines the direction and momentum of fluid at each point in the network. AKA each entity changes the direction or momentum in some way specific to its type.
  • Changes are repeated and non-continuous, mostly representing actions of moving fluid into or out-of the network.
  • Utilizes pumps on storage tanks would ensure a constant rate of change regardless of tank pressure from contents.

• Fluid-Topology : Determines the volume and velocity of fluid at each point in the network. AKA the fluid itself...
  • Changes are common, this is what is simulated, but will appear cyclic. It is cache-able because it depends on the above which has minimal variety.