Friday Facts #260 - New fluid system

Regular reports on Factorio development.
WilliamR
Manual Inserter
Manual Inserter
Posts: 1
Joined: Wed Oct 17, 2018 4:08 pm

Re: Friday Facts #260 - New fluid system

Post by WilliamR » Wed Oct 17, 2018 4:39 pm

Hey,

first of all, I didn't read the full article. (I'm supposed to work right now) However, I'm really interested in this topic and I have some input from the perspective of a audio developer. Basically, some thing I've noticed while studying audio stuff is that linear systems behave similar in electronics, fluid dynamics and in acoustics. its the same idea every time, be it voltage vs current or pressure vs velocity.

In digital audio, we have the issue of writing discrete systems that mimic the continuous real life system. One method for wave propagation is finite difference method which seems to be what your current state is. You have a fixed number of samples (pipes) and a fixed number of updates a second (tick rate) that you update every pipe using some formula based on neighbouring pipes.
Something that we use in my company more often is wave guides. For instance, a guitar string, once excited, will throw a wave in both directions of the string. The sum of those waves (or the difference, depending on some definitions) is then equal to the deflection of the string, or the velocity. The stuff we have to simulate is what happens to those waves when they meet a "change" in the medium. I.e, when the wave reaches the end of the string, it' can't continue like normal and has to reflect.

The idea is simply but it can be applied to basically everything. Pressure in a pipe or standing waves of water should be absolutely doable. The beauty is that you don't need to simulate what happens in the pipe (or across the string), at least not for linear systems. You only need to deal with what happens when the impedance changes. For instance, what happens to our waves when they meat in an intersection. What happens when they "see" a big tank, or a pump.

However, you guys have quite different requirements. The limited throughput for instance would probably mean a nonlinearity. In theory, you can always increase the pressure to put more stuff through a pipe. In reality, that's not really the case...

User avatar
steinio
Smart Inserter
Smart Inserter
Posts: 1980
Joined: Sat Mar 12, 2016 4:19 pm

Re: Friday Facts #260 - New fluid system

Post by steinio » Wed Oct 17, 2018 5:07 pm

How about eliminating pipes completely and only offer barrels *duck and cover'
Image[url=steam://friends/add/'.76561198315557255.']Image[/url]
Transport Belt Repair Man
My little mods: Link | My favourite mods: Bob's Mods | Angel's Mods | Yuoki Railway Core | EvoGUI | Logistic Train Network
Factorio Cheat Sheet by Denis Zholob

View unread Posts

User avatar
Oktokolo
Filter Inserter
Filter Inserter
Posts: 414
Joined: Wed Jul 12, 2017 5:45 pm

Re: Friday Facts #260 - New fluid system

Post by Oktokolo » Wed Oct 17, 2018 7:44 pm

WilliamR wrote:
Wed Oct 17, 2018 4:39 pm
first of all, I didn't read the full article.
No problem. Bringing in fresh ideas without contaminating his thoughts by reading about the requirements or previously discussed solutions first is the best method for participating in lengthy discussions anyway.

Jap2.0
Smart Inserter
Smart Inserter
Posts: 1748
Joined: Tue Jun 20, 2017 12:02 am

Re: Friday Facts #260 - New fluid system

Post by Jap2.0 » Wed Oct 17, 2018 9:52 pm

steinio wrote:
Wed Oct 17, 2018 5:07 pm
*duck and cover'
At least you know to do that, maybe you should work on knowing not to suggest things that everyone will hate you for?
There are 10 types of people: those who get this joke and those who don't.

mudcrabempire
Burner Inserter
Burner Inserter
Posts: 9
Joined: Sun Oct 28, 2018 2:44 pm

Pipe mechanics similar to transport belts

Post by mudcrabempire » Sun Oct 28, 2018 3:07 pm

[deleted (duplicate from the next post)]
Last edited by mudcrabempire on Mon Oct 29, 2018 6:32 pm, edited 1 time in total.

mudcrabempire
Burner Inserter
Burner Inserter
Posts: 9
Joined: Sun Oct 28, 2018 2:44 pm

Re: Friday Facts #260 - New fluid system

Post by mudcrabempire » Sun Oct 28, 2018 6:53 pm

At the risk of repeating an already posted idea:

How about treating the fluid in pipes like items on transport belts?
-Stuff that produces fluids unloads it onto the "belt" (into the connected pipe segment).
-every pipe segment transfers it´s content to the next at a defined speed.
-junktions are treated like splitters.
-fluid tanks are treated like those chest things you place next to irregularly used belts: they fill up from the surplus in the pipes, and if the pipes are underfilled, they empty themselves to keep the pipes full.
-pumps can be used to make the flow in the next few pipe segments faster (think of upgrading the next few "belts" into faster "belts").

The main difficulties would be to "reserve" pipes for a certain fluid, so they don´t mix, and to tell the fluids in which direction to flow, since pipes work both ways, as opposed to transport belts.

That would obviously not be a lot like real-life pipes, but it could be a simple and not too calculation intensive solution (I think, haven´t checked).

McDuff
Fast Inserter
Fast Inserter
Posts: 123
Joined: Sun Jan 11, 2015 11:09 am

Re: Friday Facts #260 - New fluid system

Post by McDuff » Mon Oct 29, 2018 10:31 am

mudcrabempire wrote:
Sun Oct 28, 2018 6:53 pm
At the risk of repeating an already posted idea:

How about treating the fluid in pipes like items on transport belts?
-Stuff that produces fluids unloads it onto the "belt" (into the connected pipe segment).
-every pipe segment transfers it´s content to the next at a defined speed.
-junktions are treated like splitters.
-fluid tanks are treated like those chest things you place next to irregularly used belts: they fill up from the surplus in the pipes, and if the pipes are underfilled, they empty themselves to keep the pipes full.
-pumps can be used to make the flow in the next few pipe segments faster (think of upgrading the next few "belts" into faster "belts").

The main difficulties would be to "reserve" pipes for a certain fluid, so they don´t mix, and to tell the fluids in which direction to flow, since pipes work both ways, as opposed to transport belts.

That would obviously not be a lot like real-life pipes, but it could be a simple and not too calculation intensive solution (I think, haven´t checked).
The problem with this is that pipes can flow both ways while belts can only flow one way.

McDuff
Fast Inserter
Fast Inserter
Posts: 123
Joined: Sun Jan 11, 2015 11:09 am

Re: Friday Facts #260 - New fluid system

Post by McDuff » Tue Nov 20, 2018 12:23 pm

Is there any chance of an update of how this is going in a new FF?

User avatar
Klonan
Factorio Staff
Factorio Staff
Posts: 3281
Joined: Sun Jan 11, 2015 2:09 pm

Re: Friday Facts #260 - New fluid system

Post by Klonan » Tue Nov 20, 2018 12:23 pm

McDuff wrote:
Tue Nov 20, 2018 12:23 pm
Is there any chance of an update of how this is going in a new FF?
Yes, we will give an update soon

sarcolopter
Inserter
Inserter
Posts: 34
Joined: Sun Jul 26, 2015 5:08 pm

Re: Friday Facts #260 - New fluid system

Post by sarcolopter » Tue Nov 20, 2018 4:54 pm

Jap2.0 wrote:
Fri Sep 14, 2018 10:14 pm
Tankh wrote:
Fri Sep 14, 2018 1:49 pm
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.
smurphy1 wrote:
Fri Sep 14, 2018 8:17 pm
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.
Elok wrote:
Fri Sep 14, 2018 9:07 pm
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.
Garlik30 wrote:
Fri Sep 14, 2018 7:02 pm
djnono wrote:
Fri Sep 14, 2018 5:34 pm
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 :roll: ).

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 :oops:

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 :mrgreen:

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.
darkfrei wrote:
Fri Sep 14, 2018 9:43 pm
Can you add blue and green columns to debug menu?
It's already there
Dominik wrote:
Fri Sep 14, 2018 6:08 pm
djnono wrote:
Fri Sep 14, 2018 5:34 pm
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?
It's not barrels, it eliminates the barreling and emptying assemblers, and doesn't involve an extra item.

bjorntfn
Manual Inserter
Manual Inserter
Posts: 2
Joined: Thu Nov 22, 2018 7:29 am

Re: Friday Facts #260 - New fluid system

Post by bjorntfn » Thu Nov 22, 2018 7:47 am

Regarding UPS optimization I have a suggestion.
I'm not familiar with the game enough to know whether this is already happening, but it can't hurt to suggest anyway :)

What if we could disable the fluid simulation for a fluid network that has reached a "steady-state"?
Then re-enabling under certain conditions which have changed that network.

Take a nuclear (or boiler) power setup for example, with 1 water pump (1200 water / sec input), some pipes, and 11 (not 12) heat exchangers.

Eventually the water in the network will reach 100% full and there wouldn't be a significant change to levels/flow anymore.

The network would remain in this steady-state unless:
- New components added to network (pipes, sources of water, sinks of water)
- Existing components changed (deconstructed, upgraded, or otherwise changed their production/consumption)

The fluid simulation could be disabled when a steady-state is reached, eg when all network components are showing less than 0.1% change in fluids from the previous 60 ticks.

Steady-state disabled when the network changes and then the fluid simulation for that network needs to happen again.

If there were more exchangers than water available, assuming the exchangers have a constant/predictable draw then a steady state could still be obtained.

The amount of water available to each heat exchanger would settle at some value less than the optimal draw, lets say 50 units/sec, and then the network updates could just hold at that steady-state, until one of the conditions above changed to force the simulation to start again.

This assumes a predictable/constant supply and demand in the network, which might make it difficult to apply to oil processing (unless that becomes more predictable)
It would help to make steam power more viable for larger bases though.

User avatar
BlueTemplar
Fast Inserter
Fast Inserter
Posts: 162
Joined: Fri Jun 08, 2018 2:16 pm

Re: Friday Facts #260 - New fluid system

Post by BlueTemplar » Thu Nov 22, 2018 8:08 am

Thank you, but I already made that suggestion 2 months and ~160 posts ago. :P
viewtopic.php?p=378984#p378984

Including the change needed : that fluid producers/consumers work in flows (1 unit every X ticks) instead of pulses ( Y units every cycle).

( And others did speak about two-"phases" simulation too :
viewtopic.php?f=38&t=62489&p=379663&hilit=state#p379663 )

bjorntfn
Manual Inserter
Manual Inserter
Posts: 2
Joined: Thu Nov 22, 2018 7:29 am

Re: Friday Facts #260 - New fluid system

Post by bjorntfn » Thu Nov 22, 2018 11:46 am

Ah thanks, I hadn't seen those discussions.
Good to know it has been suggested :)

Post Reply

Return to “News”