Flip particles get stuck on collision

[ch3]

I am simulating a beer overflow and somehow I can't get all the particles to slide down the collision geometry, which creates artifacts when meshing the simulation.

Friction is set to 0 for both the flip object and staticObject (not animated), stickOnCollision on the flipSolver/volumeMotion is off and I have also set collision detection to none under the flipSolver/ParticleMotion

Any ideas of what to try?
Thank you

 

(All the blue particles on the side of the pint don't move much towards the end of the sim)

[Rence]

Can you upload the hip file?

[Librarian]

from Asia Forums
""""""""""""""""""""""""
It seems that Fruit has the concept of Boundary Condition, and there is also an advanced class called No-Flux Condition. …… What is the name super-cool, but in short, it's just a story if you don't pay attention to the direction of velocity near the collision. Since it is everyone who loves reading even such a blog, you will be particularly accustomed to the bullshit of the maintainer of this blog. Yes, in fact I just wanted to use a special word because it's cool However, I've certainly noticed this as a hint, when I tried to make a slimy thing using viscosity, the liquid near the collision inevitably stuck to the object, and no matter how much the viscosity was lowered, it did not work, after all. It can even be shaped like a staircase ... If you're a visitor of viscosity, you know? Especially when it's closed, I want to see it slipping down! I'm scared of the director's request! Hey you know! This is just proof that No-Flux isn't working. If you're wondering what this guy is saying, first look at this on the big screen.
The surface may be weird, and it sticks to the object and sometimes doesn't run off, certainly the slower the speed, the worse. When I searched the net, I could see improvement if I lowered the Surface Extrapolation to zero, but it's still erratic. Even if you say the problem of resolution, that is the root, and if you raise the resolution in the first place, you will die So what is the cause? Probably it was possible to make an error in velocity
The particles are hidden for easy viewing, the red one is the collision object, and as you can see, the velocity of the surface part is out of order. Now, let me give you an explanation of the technical language I mentioned earlier ♪ Boundary Condition refers to the Fluid Flow near the surface (probably velocity itself). How close will it be specified? To the last minute, probably 1 voxel in this case And No-Flux Condition means that the direction of velocity in Boundary must be 100% along the surface. According to the book I introduced the other day The velocity at the collider surface cannot have normal component, but only should be parallel. (By Fluid Engine Development p.183) That's right. No normal component, that is, velocity that just wanders to the surface, without moving away from or penetrating into the object. This velocity doesn't follow it no matter how you look at it! Since the Project Non-Divergent dop itself for velocity calculation is a black box, I can not confirm what is inside, but this is probably a mixture of the velocity of FLIP (liquid) itself and the collision velocity of the "middle" of the object. Something may have gone wrong, something that shouldn't contain any velocity other than collision velocity inside the object in the first place. But it doesn't matter what the reason is, the quick solution is to fix only the velocity of the surface part, and even if it is not physically accurate velocity, you can fix it by pointing the direction of velocity to the tangential direction. To do this, calculate the tangent using the normal of the object, and extract only the tangent component from velocity as the inner product (velocity is the amount projected on the tangent vector). I have to release the OTL edit lock in order for these operations to be performed after Non-Divergent, but it's easier than I expected.
By the way, the formula of the projection amount of A on B is A ・ B / || B || ² ・ B, vex code dot (A, / dot (B, * B This is a complete solution in theory. However, since it is a theory, one problem and a mysterious bug occur here! !! I think that the image quality of the video is poor and it is a little difficult to see, but the velocity is also almost tangential, but there is a slight deviation. If you normalize the projection vector itself calculated by the inner product, the direction will be perfectly tangential, but if you apply the original speed, the direction will change for some reason, houdini specification or 32 bit float I don't know if it's an error, but it's true that the results have improved, so for the time being, that's all for today. Finally, I will briefly explain what is called Surface Extrapolation. As I mentioned a bit earlier, there is a collision velocity in the "middle" of the object (in this case it's zero velocity because it's not moving), but how much is Extrapolation when extending the collision velocity out of the object and mixing it with velocity? It's a parameter that determines the length of the distance (repeat, the unit is ... maybe a boxel (;'∀')), and the volume doesn't match the shape of the grid perfectly with the surface of the object. I think that the larger the extrapolation, the slower the collision velocity is extended to the outside, which also widens the gap between the FLIP and the surface.
 

[ch3]

Thank you @Librarian for your in depth response I really appreciate.

After some more reading I found out about the slip on collision parameter on the solver which helped by a lot!