Hi,
I'm working on a flip splash. One problem I have is that in the end of the lifetime I get these little drops that almost stop in the air and slowly slide down, looks a bit like a drop on a window slowly falling down. Any idea what is going on?

Could it be that they get 0 mass because they are so small so that is why they stop? They do not collide with anything.

One solution I thought of is to delete particles that have very low velocity, but that could introduce other problems maybe.

Cheers,
Andreas

I added a wrangle that deletes the particles when they flow slowly, but not that happy with this situation.
It seems a bit that the particles suddenly just stop, looks real bad.

Are you sure they're not colliding with the closed wall of your domain?

Enivob
Are you sure they're not colliding with the closed wall of your domain?

They are spread out all over I cannot see that is in the edges, plus I do not have collision on the edges.
Deleting based on speed was not great because it will kill them when they are turning around in the top.

I'm uploading the sim here. You will begin seeing the problems around frame 50. Here is an image that shows all the stuck droplets.

To me it looks like the droplets are hitting something, but its just in the middle of the sim. What could it be?

I can't seem to reproduce your issue. Perhaps you have the Cache memory setting too high? You may be running out of physical memory as the simulation continues. Try resetting it to the default, 5000MB and simulating again..?

Enivob
I can't seem to reproduce your issue. Perhaps you have the Cache memory setting too high? You may be running out of physical memory as the simulation continues. Try resetting it to the default, 5000MB and simulating again..?

Thanks for checking!

Oh, that is really strange. Can you double check in the Solver that the wrangle node is disabled (so it does not delete particles moving slowly). I did put a node in there that would delete slow moving particles. I thought it was disabled before uploading but best to be sure.

I have 256GB so would think it would be enough on this machine, but I can try with less cache.
When I analyze the Geometry Spreadsheet I see that the v.x and v.z is 0.0 for these particles. Also the L attributes are all 0.0 as well which is odd. However the particles are not dead.

I wrote this in a wrangle node. It deletes everything moving very slowly in x and z direction.

if(abs(v@v.x)<0.001 && abs(v@v.z)<0.001 && abs(v@v.y)<1.0) removepoint(0,@ptnum);

I still have this issue. The remove points works pretty well (I have modified it a bit) but it seems to be one frame behind. So I can see the particles stop and then they disappear the next frame. So looks a bit glitchy.I was wondering if this could be a bug in the Flip SOP since its so new?

Yeah that seems like a bug, although I've had weird stuff like this when you cut Activation like you are doing (tried without still had problems in your scene)

Rebuild it all the old DOP method and see... the new SOPS do have a ton of nodes going on under the hood that maybe is causing the problem, so could be a bug.

I managed to fix it by increasing the Simulation Global Substeps to 2. Takes longer to calculate of course but at least I do not get odd fake collisions in mid air.

This is the wrangle I used before btw
if(v@v.x==0.0f || v@v.y==0.0f) removepoint(0,@ptnum);

Of course having 2 substeps really increases simulation time so its not exactly the best solution. The manual they say its very rare that you need to increase this from one. So would be nice to find another way if possible.

Have you tried playing with FLIP Min/Max Substeps?

Also I wouldn't compare individual velocity components like that, unless you want to check for movement on specific axes, but even then a tolerance would be better:

animatrix_
Have you tried playing with FLIP Min/Max Substeps?

Also I wouldn't compare individual velocity components like that, unless you want to check for movement on specific axes, but even then a tolerance would be better:

float tol = 0.0000001;
if ( length2 ( @v ) < tol )
    removepoint ( 0, @ptnum );

I tested now to set substeps min 1 and max3. That got rid of the stuck particles. Not sure if its faster than having 2, maybe. I do find it a bit odd the the particles would just stop in mid air and then slowly fall down.

The reason I compared the velocities is I got very odd characteristics. They would be completely 0.0000 in x and z axis but they would have a bit of -y velocity.

Yes FLIP substeps is cheaper than global DOP substeps.

animatrix_
Yes FLIP substeps is cheaper than global DOP substeps.

Thanks! Just doing some benchmarks.
Would you use the previous DOP for flip now or the new SOP?
To me the largest benefit with the older DOP is that it can do whitewater, but you maybe do yours manually?
Do you have any tip for how to do a white water shader? I got a pretty good material for transparent water, but the foam part I'm not sure what the best way is to tackle. I looked at the default whitewater but it does not seem to do anything special in the material what I can see.

Andreas

Here are the benchmarks
Global Substeps 1 Min:1 Max: 1 3min 15sec
Global Substeps 1 Min:1 Max: 3 8min 33sec surprised that this is shorter
Global Substeps 1 Min:1 Max: 2 18min 31sec
Global Substeps 2 Min:1 Max: 2 34min 40sec

To me it seems like global really increases time. After that it seems mostly that the size of the shape depends the time. The max 3 is fast, but its because it creates a quite small splash.

I still say this is some bug, never really had this issue in DOP version of FLIP before. (except as I said, sometimes if you key activation in some sources, it would make strange things like this happen.)

Can you rebuild it in 18.5 or just not a SOP in 19 and see?

HM_2020
I still say this is some bug, never really had this issue in DOP version of FLIP before. (except as I said, sometimes if you key activation in some sources, it would make strange things like this happen.)

Can you rebuild it in 18.5 or just not a SOP in 19 and see?

It could be that the keyed activation created this problem. I have a new version where no longer key it, I just scale the collision mesh to 0 instead. Maybe that fixed it.
I will try the DOP Flips as well, but they are quite difference so will probably work there!

animatrix_
Have you tried playing with FLIP Min/Max Substeps?

Also I wouldn't compare individual velocity components like that, unless you want to check for movement on specific axes, but even then a tolerance would be better:

float tol = 0.0000001;
if ( length2 ( @v ) < tol )
    removepoint ( 0, @ptnum );

A problem I found with this version is that this will delete the particles as they turn around if they fly straight up. That is why I changed so I looked mostly at x and z.

AndreasOberg

animatrix_
Have you tried playing with FLIP Min/Max Substeps?

Also I wouldn't compare individual velocity components like that, unless you want to check for movement on specific axes, but even then a tolerance would be better:

float tol = 0.0000001;
if ( length2 ( @v ) < tol )
    removepoint ( 0, @ptnum );

A problem I found with this version is that this will delete the particles as they turn around if they fly straight up. That is why I changed so I looked mostly at x and z.

Oh yes in that case ignoring y would be better.