Re: Fluid mechanics
Posted: Wed May 03, 2017 1:02 am
Original post is updated to 0.15.x.
Math seems to be the same.
Math seems to be the same.
The level of fluid in a pipe is not indicative of flow. The way to tell whether or not you're facing pressure issues is if you have some producers (that are putting fluid into a pipe) with backed up output AND some consumers that are starved for input.t-lor wrote:question.
i have some weird problems with my plastic plants halting for gas every few seconds,
even though there is a half filled storagetank in the system.
I was assuming fluids worked like electric. IE just plug everything on the same buss in any order and it would work.
How can i tell if its a presure problem ?
do the pipes have to show full, or just empty ?
I was simply stating that my Python simulation, using the formulas from the forums, combined with my own deductions, for a series of pipes (147 of them) placed in each direction, with only a pump at one end and then looking at the value in the final pipe after exactly 20 seconds, perfectly matched the in-game version of the same experiment. It was a verification that together, it is a complete understanding of the fluid physics, at least where there are no 3-way or 4-way pipe segments. One which went beyond using an offshore pump and a single junction only, which if I remember right is what the formulas over here were derived from.Fatmice wrote: Yes, this is known and confirmed by devs a long time ago. Placing sources follow by a continuous section of pipes away from source will always have better throughput than placing pipes then source in the opposite direction of how the pipes were placed.The order does matter. Update is done North->South and West->East direction first. This is where order really matters. If you placed a pipe, then placed another pipe directly south of it, you can not stop the flow of liquid by disabling the southern pipe with the console. The reverse can be done. Also you can never place anything simultaneously. All entities are placed individually on each tick. Thus there is always an order or indexing number. This corresponds to their id number, which you can query through lua.
XKnight wrote:Note: do not forget that I've used only 2 pipe segments in my expiriments, so some erros are possible . If you find any differences between this theory and game-reality feel free to post your expiriments in this topic and I will do my best to explain it.
I was talking about the update order of the junctions between the pipe segments. Naturally, when you're placing pipes end-to-end, the junctions are updated in the same order that they are created. I was wondering what order the junctions are added to the end of the list when multiple junctions are created simultaneously, such as when placing a segment into a 3-way or 4-way position. My simulation verified that the updates are per-junction, that is, a flow rate is calculated from the difference in fluid levels between pipe A and pipe B, then the fluid is immediately transferred and the levels are updated, then the difference between fluid level in the newly updated pipe B and pipe C are used to determine flow between them. Junction A-B is calculated and applied, then junction B-C is calculated and applied (using the update from A-B), if that was the order they were created in. If the game did it better, then placement order would no longer matter, and the fluid physics could be multi-threaded (because the calculations would not depend on each other's results at all), making fluid physics run much faster, but the devs have no interest in doing this. Just an hour ago, I accidentally starved a row of heat exchangers of water because the placement order was wrong. All 8 of them (a single row) were getting nothing, so I picked up the pipes and put them back down in the right order, and all 48 of them were getting ample water again, as you would expect with 6 pipelines and 6 offshore pumps. Too bad construction bots can't do this.Fatmice wrote: The order does matter. Update is done North->South and West->East direction first. This is where order really matters. If you placed a pipe, then placed another pipe directly south of it, you can not stop the flow of liquid by disabling the southern pipe with the console. The reverse can be done. Also you can never place anything simultaneously. All entities are placed individually on each tick. Thus there is always an order or indexing number. This corresponds to their id number, which you can query through lua.
Just a small correction, the world is not infinite. It is neigh-infinite. You are hard limited to 31250x31250 chunks, but realistically limited to 31220x31220 chunks as you can not venture near the limit or you will crash when the game can not render beyond the boundary.PacifyerGrey wrote: Looking at the game world I would suppose that Factorio uses lists for everything as game world is infinite and the amount of entities is too so to conserve memory the list is the best way to go.
I was referring to the junctions, the connections between adjacent fluid boxes. Since these are not updated simultaneously for boxes with two junctions (as in a serial pipeline), I imagine that the same is true for 3- and 4-way intersections. This means that, when placing a pipe into such an intersection, multiple junctions are created simultaneously, yet are updated in a precise sequence during fluid physics calculations.Fatmice wrote:Nothing is placed simultaneously. Everything is placed serially, one after another. ...
There is suction in physics, because pressure can be negative.Fatmice wrote:There's no such thing as suction anyway, even with real physics.
Updates are, like I said, dependent on the orientation and direction of the connection. The sequence is top/left -> bottom/right, unless at chunk border, which is updated by the chunk order. I'm not totally clear on what actually happen at the chunk border and all of the magic that happen there.Aru wrote:I was referring to the junctions, the connections between adjacent fluid boxes. Since these are not updated simultaneously for boxes with two junctions (as in a serial pipeline), I imagine that the same is true for 3- and 4-way intersections. This means that, when placing a pipe into such an intersection, multiple junctions are created simultaneously, yet are updated in a precise sequence during fluid physics calculations.Fatmice wrote:Nothing is placed simultaneously. Everything is placed serially, one after another. ...
Did you actually read what Aru said or what I was referring to what Aru said or just drop by and make a comment? Suction in physics, under normal use of the word, is a phenomenon that arises out of disequilibrium of pressure. Disequilibrium can only happen among positive quantities. Within this topic, Aru was referring to the fact that entities do not generate disequilibrium, "suction", to move liquid from one pipe section to another. Liquid in the game is moved around like passing a hot potato. There must be a spot for the potato to land for it to be moved. Pipes are in fact chests with only 1 slot for 1 type of item.BenSeidel wrote:There is suction in physics, because pressure can be negative.Fatmice wrote:There's no such thing as suction anyway, even with real physics.
Yes, I read it. I was disputing the idea that there is no such thing as "suction". Pressure is caused by an inward force upon the mass. This means that under normal circumstances, when a liquid flows it is not due to suction, but (as you said) due to the disequilibrium of the pressures: the liquid is being forced not into the area with a lower pressure, but out of an area with higher pressure. This however is not the case when you look at negative pressure. If the liquid has the ability to either expand a vacuum, or travel to the places with negative pressure, it will expand the vacuum, so it's not being "pushed" from the higher pressure location, but pulled into the lower pressure location: hence true suction.Fatmice wrote: Did you actually read what Aru said or what I was referring to what Aru said or just drop by and make a comment? Suction in physics, under normal use of the word, is a phenomenon that arises out of disequilibrium of pressure. Disequilibrium can only happen among positive quantities. Within this topic, Aru was referring to the fact that entities do not generate disequilibrium, "suction", to move liquid from one pipe section to another. Liquid in the game is moved around like passing a hot potato. There must be a spot for the potato to land for it to be moved. Pipes are in fact chests with only 1 slot for 1 type of item.
*Under very special topics of physics, there are such thing as "negative pressure," but almost always those terms are used to describe concepts that are counter-intuitive and unrelated to pressure, an outward force, which can not be negative on the absolute scale. The term "negative pressure" is only used to convey the idea of inward pulling, like tension. It is unfortunate that a negative of vernacular, pressure, is used to describe some very counter-intuitive and special physical effects under very special circumstances.
I think the primary use of "negative pressure" is as a relative pressure, a difference between the pressure of two areas. The concept is widely used in real life as such, for example a negative pressure room for containing infectious agents, or yes anything with suction is also described as negative pressure. It's relative rather than absolute pressure, and I agree that it's a perfectly valid terminology that is widely used.BenSeidel wrote:Yes, I read it. I was disputing the idea that there is no such thing as "suction". Pressure is caused by an inward force upon the mass. This means that under normal circumstances, when a liquid flows it is not due to suction, but (as you said) due to the disequilibrium of the pressures: the liquid is being forced not into the area with a lower pressure, but out of an area with higher pressure. This however is not the case when you look at negative pressure. If the liquid has the ability to either expand a vacuum, or travel to the places with negative pressure, it will expand the vacuum, so it's not being "pushed" from the higher pressure location, but pulled into the lower pressure location: hence true suction.
Edit:
I also think that the idea of negative pressure is not that counter intuitive as you have put forward. As positive pressure is caused by the repulsion of the molecules within the substance, negative pressure is caused by the attraction of the molecules within the substance, similar to compression and tension for solids. Just because it's something that happens rarely or under specific circumstances does not make it any less real or harder to comprehend.
Thought experiment: if you let a glob of some liquid orbit the earth (and you are able to prevent freezing/evaporation/boiling etc) then how does the liquid stay clumped together under the effects of gravity? Surely the gravitational difference from one side of the glob to the other would cause it to be ripped apart?
And none of this matters as the fluid in this game is not based on physics. It is better said that pipes carry fluid as belts carry items. It's that simple. There is no pressure, positive or negative. The "pressure" in the code is just to provide direction of flow. When the fluid flow is rewritten, when Rseding91 get to it, all of this will change. No more weird flow or no flow because pipes were built counter to the update preference.BenSeidel wrote: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.
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.Fatmice wrote:And none of this matters as the fluid in this game is not based on physics. It is better said that pipes carry fluid as belts carry items. It's that simple. There is no pressure, positive or negative. The "pressure" in the code is just to provide direction of flow. When the fluid flow is rewritten, when Rseding91 get to it, all of this will change. No more weird flow or no flow because pipes were built counter to the update preference.BenSeidel wrote: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.
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.Aru wrote:But, rseding has no intention of fixing it from what I can tell.