Fluid Inflow Fails To Fill Simple Tank Depending On Position In Tank

Here is a schematic of the simulation before baking. There is no outflow object.

In the following simulation, the inflow object is positioned inside the tank (obstacle) at about half the tank’s depth. It begins filling the tank at a reasonable rate, but then the level stagnates despite the inflow’s continuing constant rate.
https://dl.dropbox.com/s/2558mn6cpfrdu0m/Case36.gif

In the following simulation, all is identical, except the inflow object is positioned just above the tank. It fills the tank at a reasonable rate and then overflows (reasonably correct behavior).
https://dl.dropbox.com/s/5gdjhivnfjubh9i/Case35.gif

Why does the first simulation fail to fill the tank?

Other Info:

  • Scene is set to Blender units.
  • The domain dimension are 1.1x, 0.8y, 0.8z
  • The domain Real World Size is 0.5m (Setting it to 1.1 makes little difference)
  • All scales have been applied.
  • All normals are correct and meshes are manifold.
  • The inflow Volume Initialization is set to Volume, with an inflow velocity of z = -0.5
  • The obstacle Volume Initialization is set to Shell.
  • Bake resolution is 80 (Running at 200 makes little difference)

I have varied the obstacle impact factor, the domain optimization grid levels and compressibility, simulation speed, and probably a few other things. The only things that have significant effect are the height of the inflow object, a significant decrease in domain real world size, or a significant increase in inflow velocity.

In the real world, if I remember, the inflow velocity would equate to some sort of velocity head. And I suppose if this is low, the inflow might be cut off due to increasing static head on the inflow object. But I didn’t think the fluid simulator took account of these types of things. That is, I thought the inflow velocity was supposed to be non-changing.

I am also attaching the .blend for the case where the inflow object is inside the tank.

FillProblem36_Cache36.blend (464 KB)

Thanks for any explanations.

It would appear that the problem is inherent to the manner in which the fluid simulation works.
Similiar to problems you would encounter if the domain were to be completely filled with fluid,
it seems that positioning the inflow object in the scene, such that it becomes enveloped by
fluid also causes problems.

I re-created your scene in the Mantaflow fluid simulator (blender code implemetation by sebbas,
and based on the framework created by Nils Thuerey and associates- the same person who created the
original elbeem fluid simulator for blender), and it had the exact same issue.

I don’t want to mangle the explanation by sebbas as to why this happens, so I’ll just post the
conversation I had with him (and lucaRood) in #blendercoders:

gimble: sebbas: I was trying to re-create the issue that DavePSB was having with the elbeem fluid simulator, and it seems that mantaflow reacts the same way -> https://blenderartists.org/forum/showthread.php?410338-Fluid-Inflow-Fails-To-Fill-Simple-Tank-Depending-On-Position-In-Tank
gimble: sebbas: The mantaflow version is here: http://pasteall.org/blend/index.php?id=44369
gimble: sebbas: I was wondering if I set something wrong, or is this just an issue to be avoided?

sebbas: gimble: ah yes, I see what you mean

gimble: sebbas: The inflow rate noticeably changes once the inflow object becomes “submerged”

sebbas: gimble: i am not sure why elbeem behaves like that but for manta i know the reason:
sebbas: the thing is that the inflow object only refills cells with new particles
sebbas: so once the liquid level matches the inflow objects level, the inflow object has no cells to refill
sebbas: and hence it stops adding new particles
sebbas: so yes - I’d say this is a case you should avoid

gimble: sebbas: Ah, ok. hmmm, so “just the way it is” sort of situation I suppose? Not sure about why he set it up like that, and I can’t really think of any solutions to overcome that situation…
gimble: sebbas: thanks for the details :slight_smile:

LucaRood: sebbas: Are you talking about particle sims or voxel sims?
LucaRood: sebbas: cuz you talked about “cells”, and later said it stops adding “particles”.

sebbas: LucaRood: I just meant the FLIP particles that manta creates (you dont see them but manta uses them to create the mesh)

LucaRood: sebbas: Ah FLIP… that explains it :slight_smile:

gimble: sebbas: elbeem uses something similiar (or similiar explanation why it happens there)?

sebbas: gimble: i’d say elbeem does the same (just a guess …)

LucaRood: sebbas: What integrator is manta using for FLIP?

sebbas: LucaRood: uff not sure …

LucaRood: sebbas: Ok, np.
LucaRood: sebbas: I asked about the integrator, because depending on what it uses, it would be trivial to fix the submerged inflow issue.

sebbas: LucaRood: ah ok - to fix the problem I think it should also be possible to explicitly add new FLIP particles at each step (so not just refilling empty cells)
sebbas: I think there is an option for that in manta

LucaRood: sebbas: Yeah, but the issue is that if you add new particles within an existing fluid mass (filled cell), the simulation tends to explode when using most explicit integrators. Hence the integrator question :slight_smile:

sebbas: LucaRood: its using IntRK4

LucaRood: sebbas: Ah yeah, that is a explicit, though it is a fourth-order integrator, so should not be too “explosive” :stuck_out_tongue:

sebbas: LucaRood: ah okay - so something like second order would be much more “explosive”?

LucaRood: yes :slight_smile:
LucaRood: with rk4 you might be able to get away with just artificially adding particles, if the inflow isn’t too high.

So, if I interpret what sebbas said properly, the problem stems from the manner in which the inflow object
adds fluid to the domain: if fluid hasn’t moved away from the inflow object’s volume due to gravity,
initial velocity, or some other external force, it sees the fluid voxel as being full, and no additional
particles/fluid is added.

It appears that there is a possible solution, but it might lead to “exploding particles/fluid” if the
inflow rate is set too high. Then it becomes an issue of if this is implemented in the Mantaflow fs,
and if it would also be ported to the elbeem fs…

In the mean time; what can be done?..

It seems that the scene setup is somewhat “artificial”, in that you normally don’t see fluid materializing
in the middle of a tank out of thin air. Usually there would be a pipe into the tank either from above or
from below the tank. From above is no problem, but from below is. In that case you would have to resort to
some trickery or perhaps route the pipe from above the tank to enter from below the tank; keeping the
inflow object situated above the tank.

Another option would be to use SPH fluid particles and then use the CubeSurfer addon to mesh the result.
I tried a quick mockup, and it seemed to work, at least on a coarse level, though it is also subject to the
“exploding particle” isssue if you’re not careful.

1 Like

I am not worthy! Thank you guys so much for taking your time to discuss this. I couldn’t have hoped for a more qualified team to bat this around.

I vaguely understand the technicalities, and I am fine with “that’s the way it is”. And now that I know about this limitation, I know how to avoid it. I’m surprised this question doesn’t seem to have come up before. It will be interesting to watch whether any changes end up being made to the fluid sim code in the future.

The scene is a simplified one. It started with an ArchViz question on another non-Blender forum. I think the fellow was trying to simulate something like an infinity pool. I had a quick go at the problem, but quickly got sidetracked on the filling issue. I originally put the inflow object under the fluid because I wanted to minimize the turbulence at the fluid surface, which would disturb a smooth overflow. And this was simply easier than adding things like a bottom fill pipe etc.

@Gimble: I am intrigued that you are able to run other fluid simulators like the mantaflow version you mentioned (again, thanks for taking the time to do that) Is this through something like a special Blender build or something?

1 Like

Im jumping in here as well. I made this exact same scene and got it to fill if i increase the speed of the inlfow and its velocity

Good to see you Rombout! Yes, there are a few workarounds including the ones you mentioned, but I was more interested in why for future reference. I ran about 39 cases so learned a lot.

wow 39 variations of this scene?

PS i actually did animate the inflow Z-pos if i remember well, i also animated the inflow veloctity. Giving it more power over time, i did lead to wild river like effect in the corners as the water was forced upwards due to the bit exptreme inflow power

Is there still no proper fix for this? I have the same problem except in the animation I’m rendering the water MUST come from the bottom…

Basically it’s a piece of equipment which under pressure puts water into the chamber. The chamber is then pressurised and I can only flow water in from the bottom. As soon as the water has gone over the inflow then that’s it


I did a trick by animating the inflow object, this way it will fill. But not realistic ofcourse.

That’s a good trick. Another one might be to make the chamber one end of a big U-tube. The rest of the U-tube goes down below the chamber stand out of view, then curves off camera where it then rises to form an inlet where the inflow is (all off camera). I have seen some successful glass water pipe simulations like that and Blender doesn’t seem to have a problem making water gravity flow inside a pipe - around a u-bend in a sink for example.

Yea I fixed it by carefully animating the inflow upwards like rombout suggested and then reducing the velocity it fires out through time. The U-tube idea sounds interesting though I might give that a shout!

Hi again. I’ve found an alternative kludge/trick/work around that
seems to work quite well (at least with the fluid tank example posted
by DavePSB); that I thought I’d include for future reference.
I’m not entirely sure why or how it works, but it seems to trick the
Elbeem fluid simulator to continue adding fluid even when the inflow
object becomes submerged.

http://gimblender.com/blender/helpdesk/blenderartists/DavePSB/FillProblem39_Cache39.blend

Simply add a Plane, set it as a fluid obstacle, Volume Initializtion =
Shell, and position it either slightly above or even embedded slightly
into the top of the inflow object. It should be roughly the size of the
inflow object or a bit larger. Also, it seems to work best if the
obstacle Plane is placed vertically, such that it divides the fluid voxel
(so you may need to move it vertically if you change the resolution).

I also tried duplicating the inflow object, scaling it up slightly, and
deleting the lower face prior to changing it to an obstacle. This also
seemed to work, but created an “air pocket” above the inflow object
when it became submerged. It is possible to remove the air pocket by
using a Boolean object (Cube) which was sized to encapsulate the air pocket.
This boolean object is then set to “Union” with the Fluid Domain (after
the fluid simulation has been baked, of course). Also, you need to
disable the visibility of the original Fluid Domain.
Another issue with this “shroud” obstacle, is that you see an interaction
with the reflected waves from the sides of the tank. It can be minimized
somewhat by lowering the Obstacle’s “Impact” factor.
So the Plane Fluid Obstacle would be the best solution for the fluid tank
example, but I mention this alternative which may work better in other
situations.

I haven’t tried this technique with the other fluid simulation options in
Blender (Perhaps this work around isn’t necessary).

Current Fluid Options for Blender:

  1. MantaFlow by Sebbas:
    Currently a special build (but possibly a replacement for the current Elbeem
    fluid simulator in the future)?
  1. FLIP Fluids (Add-on) by RLGUY:
    Currently in Beta testing. It will be a paid add-on, but RLGUY has said that
    it will be priced fairly reasonably, so as to be affordable by hobbyists.
  1. SPH Fluid Particles (already built into Blender)
    May be used with PyroEvil’s Molecular and CubeSurfer Add-ons (free)

and

  1. Elbeem, of course.