Vanishing liquid - again

[JuhaHo]

I think I have wrote about this years ago. In my simulation something has been consuming liquid until it's all dried up. I just know what makes it this time.

[zdravko_pavlov1]

Could you be more specific, please? Is it possible to give us a little bit more information about the rest of the setup?

[JuhaHo]

Thanks,

I'm using a geometry emitter for sending liquid to a rotating drum after I shut down the emitter liquid starts to vanish until there's no more liquid left in the drum. It should remain there until the drum is discharged from the other end. The faster the drum is rotating the more it "eats" the liquid. I have also a stationary container in the same simulation, the the liquid stays normally. The additional container is where the liquid is poured from the rotating drum.

[zdravko_pavlov1]

There is a documented issue where flip particles disappear when interacting with rotating geometry objects. Thank you for reporting this. We'll add one more vote to the bug-tracking system for this one.

[JuhaHo]

So, is it possible to switch solver do another that doesn't have this "feature"?

[JuhaHo]

So, I woke up 4 A.M. to study this. It seems this FLIP (Fluid-Implicit Particle) is used practically in every animation software except Maya, which uses Bifrost. Then there appears to be this Lattice Boltzmann Method (LBM), but it isn't implemented in any animation package I know.

I have spent somewhat three months with this project and in the end it's possible I can never finish it. I wish I had read the small print before signing the contract.

[Svetlin.Nikolov]

It's not an issue with FLIP, but rather with the way the particles interact with moving geometries. This code is not a part of the solver - any simulation software developer can do this any way they see fit. Phoenix in particular uses something that balances between speed and precision - it could be very slow to simulate but more precise, or very fast to simulate but much less precise. What happens when it's not precise - particles get inside of geometry which should be impossible. I had to choose between allowing the particles to pass through and potentially leak through moving obstacles, or to kill the particles, reducing their count. I chose killing particles as the lesser evil. The way you could cope with it is to increase the number of steps per frame - the more steps, the more precise the collision would be, and the less particles would die, but the simulation would run proportionally slower.

I'm afraid the interaction between the liquid particles and moving geometries must be rewritten from scratch for this to work in a different way. I believe it's possible to have perfect collision without terrible simulation speed, but I don't have the Phoenix code anymore to prove it.

Good luck!

[JuhaHo]

Thanks,

It got worse when the client said, this thing should be rotating - let's say five times faster. I had found some kind of balanced ratio between liquid amount and vanishing particles. Now after three month of trying, I'm back in square one. As usual, they let me know the real rpm after I had finished all the renderings.

I have made sure, it's not leaking outside the geometry, so it has to be internal, As a solution I will do iterations with grid size and sub steps to find the perfect combination. It will take another month or so to finish, but at least now I know what's causing this.

[Svetlin.Nikolov]

If the performance gets really bad when increasing the Steps Per Frame, one thing that might help is to use a simplified geometry only for the simulation, while the real model would be used only for the render. Is this an option for you?

Lower grid resolution should also help it simulate faster, though in this particular case it might not be that much helpful. If possible, please give it a shot!