Page 4 of 4

Re: [0.15.x] Fluid mechanics

Posted: Sat Jul 29, 2017 4:36 am
by Zavian
Rseding91 wrote: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:
@Rseding91 I've never understood why you need pipes to not automatically connect to every adjacent pipe. If all layouts that could be built under the old system, can be built with the new system, then surely you can just connect a new pipe segment to all adjacent "merged pipes" (automatically merging multiple "merged pipes" when needed), and calculate the properties of the new "merged pipe" once it is placed? Shouldn't this be the same as a player building an identical layout using pipes that don't automatically connect? Or are you only planning to merge sets of pipes that have exactly one input, and one output, and hence want to discourage players from building networks with lots of cross/tee connections?

Even if the latter can't you simply implement it, explain how it works in a FFF (and add a link to the FFF to the changelog)? That way players who build suitable layouts which can benefit will automatically gain more performance, and players looking for more performance can try to optimise their layouts based on information in the FFF. Even if you only optimise one input/one output stretches of pipe which don't include boilers/engines/turbines then this will probably help mega-factories with large nuclear plants. (Though I'm not sure how you would design a refinery to minimise T connections to/from refineries/chem plants, and even in a nuke factory you will still have a need a lot of them).

Re: [0.15.x] Fluid mechanics

Posted: Sat Jul 29, 2017 5:04 am
by Rseding91
Zavian wrote:
Rseding91 wrote: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:
@Rseding91 I've never understood why you need pipes to not automatically connect to every adjacent pipe. If all layouts that could be built under the old system, can be built with the new system, then surely you can just connect a new pipe segment to all adjacent "merged pipes" (automatically merging multiple "merged pipes" when needed), and calculate the properties of the new "merged pipe" once it is placed? Shouldn't this be the same as a player building an identical layout using pipes that don't automatically connect? Or are you only planning to merge sets of pipes that have exactly one input, and one output, and hence want to discourage players from building networks with lots of cross/tee connections?

Even if the latter can't you simply implement it, explain how it works in a FFF (and add a link to the FFF to the changelog)? That way players who build suitable layouts which can benefit will automatically gain more performance, and players looking for more performance can try to optimise their layouts based on information in the FFF. Even if you only optimise one input/one output stretches of pipe which don't include boilers/engines/turbines then this will probably help mega-factories with large nuclear plants. (Though I'm not sure how you would design a refinery to minimise T connections to/from refineries/chem plants, and even in a nuke factory you will still have a need a lot of them).
Under the system I described a merged pipe set would only support having 1 fluid type in it at a time so it can't allow merging of 2 pipes that have different fluids.

Re: [0.15.x] Fluid mechanics

Posted: Sat Jul 29, 2017 6:50 am
by Zavian
Ah ok. I hadn't considered that, probably because I never want to connect 2 pipes with different fluid anyway. I think I've done that a total of three times, and in all three cases ended up having to remove all sections of pipe that had the wrong fluid.

Couldn't you just detect the error, not merge the networks, and highlight the offending pipe or pipe joint in red and print a console message 'Pipe disabled. Can't cross connect 2 pipes with different fluids'. It's not something a player would want to do in a stock game anyway. (I'm not sure whether there are any mods where it might make sense).

If tanks aren't going to be merged, then as an alternative solution you could just merge the networks and pick a winner, probably whicher ever fluid has greater quantity/pressure. Destroying a bit of fluid in a pipe shouldn't normally be an issue. After cross-connecting you probably need to rip up the contaminated pipes anyway. Destroying 500k in a tank farm would be pretty aggravating though.

Re: [0.15.x] Fluid mechanics

Posted: Sat Aug 26, 2017 10:26 pm
by nthexwn
I've re-read this entire post (including all of the comments) about 5 times now. I understand everything up to XKnight's "Application" section. The section starts off by describing a string of pipes/entities which is completely stable, maintaining the exact same flow rates, capacities, and pressures at each update tick. It then presents two equations which will presumably lead us to a flow versus distance formula once combined and solved.

Unfortunately it's not clear to me where these equations are coming from. I'm not understanding why zero_pressure+(max_pressure-zero_pressure)) got replaced with diff+flow in the flow formula. XKnight describes diff as "a water level difference between two adjacent entities" but I'm not sure specifically how he's calculating it. Is the value a ratio (IE: 1.0 indicates no difference), or a literal difference (IE: 200 - 50 = 150)? Flow seems to be up there in the numerator to indicate a constant difference in pressure at each tick because the system is stable, but I don't quite see how the math works out that we can just plug it in at that particular point in the equation.

I'm also not understanding where length=(capacity-flow)/diff comes from. Is this known from somewhere else, did somebody run a simulation that converges on these values, or is there some sort of logic to it that I'm not seeing?

Thanks for all the work that was done here!

Re: [0.15.x] Fluid mechanics

Posted: Thu Nov 09, 2017 8:10 pm
by promaty
So roughly speaking for simple calculations you should put a pump every ~100 pipes to maintain a flow of ~1000 fluid/s (gives you a tiny bit extra just in case).

Re: [0.15.x] Fluid mechanics

Posted: Fri Jun 21, 2019 6:40 pm
by Qeeet
XKnight wrote:
Sat Feb 06, 2016 5:16 pm
Recently, I was looking for deep explanation of fluid simulation, and I found only a few posts where other people asking the same questions but don't receive answer. So I performed my little research in this area.
Could you please say what program you used for creating those plots?

Re: [0.15.x] Fluid mechanics

Posted: Sun Oct 27, 2019 10:38 am
by imTheSupremeOne
Can someone restore pictures?.. :(

Re: [0.15.x] Fluid mechanics

Posted: Sun Oct 27, 2019 11:06 am
by imTheSupremeOne

Re: [0.15.x] Fluid mechanics

Posted: Sun Oct 27, 2019 1:41 pm
by DerGraue
imTheSupremeOne wrote:
Sun Oct 27, 2019 10:38 am
Can someone restore pictures?..
You are aware that the original post is over 3 years old and the fluid mechanics have been overhauled? Those mechanics don't apply anymore.

Re: [0.15.x] Fluid mechanics

Posted: Sun Oct 27, 2019 3:32 pm
by BlueTemplar
They had a few tweaks, but the overall logic still applies ?

Re: [0.15.x] Fluid mechanics

Posted: Mon Oct 28, 2019 10:08 pm
by DerGraue
BlueTemplar wrote:
Sun Oct 27, 2019 3:32 pm
They had a few tweaks, but the overall logic still applies ?
There are a bunch of friday facts on the topic.
They are calculated differently, they are multi threaded, they can not mix anymore. I would not call that a few tweaks.

Since they are calculated differently the formulas and charts of the OP won't apply anymore.

Re: [0.15.x] Fluid mechanics

Posted: Mon Oct 28, 2019 11:29 pm
by BlueTemplar
BlueTemplar wrote:
Sun Oct 27, 2019 3:32 pm
but the overall logic still applies ?

Re: [0.15.x] Fluid mechanics

Posted: Fri Dec 06, 2019 5:10 pm
by Linver
imTheSupremeOne wrote:
Sun Oct 27, 2019 11:06 am
Yay, they were archived:
https://web.archive.org/web/20171227174 ... 18&t=19851
Yes but should be restored in the main thread