Inner workings of the flip solver

[mnu]

Hi forum,

 

I'm currently dissecting the FLIP solver and trying to understand how it works. I found some nodes in the solver that I do not understand. Maybe somebody here can clarify what the nodes do that I circeled in the attached images and why they are necessary. They are advecting the velocity after the divergence projection step and after the FLIP update. I don't understand why this is necessary.

 

Thanx for your help in advance,

 

best Manuel

[tricecold]

as far as I know particles in a flip solver are moved by volumes, so advection would be for moving the particles to the new position based on volume velocities, and because the new position of the particles are going to effect the next frame, the flipvels create a new volume velocity to be used next frame. I don`t know about the stash node however.

[mnu]

Thanx for your reply Tim. But as far as I understand it the transfer of the volume velocities to particle velocities happens already in the flip_pic_update node. After that the results of the projection step are added to the initial particle velocities. The integration of the velocities to position happens in the integrate_particles node in the particle motion box I depicted above. That's why I don't see why the particle velocity has to be advected by the velocity field again before doing the integration.

 

Best Manuel

Edited June 3, 2015 by mnu

[eetu]

 I don't see why the particle velocity has to be advected by the velocity field again before doing the integration.

 

Firstly it's the other way round, the velocity field is either advected with itself (advect_vel_by_oldvel) or rebuilt from particles (rebuild_vel). And you are correct to question this, as it is not really needed for the FLIP solver - the velocity will anyway be rebuilt from particles at the beginning of next timestep.

 

My understanding is that this is done because some other tools, whitewater and such, like it if they can work with the updated current frame's velocity field. Without this step the velocity volumes would represent the previous timestep's situation. In my opinion these could be disabled by default, as they incur extra unneeded calculation in the default use case, but I suppose it has been deemed confusing if whitewater and such wouldn't work that well without going in and changing an option in the solver...

[mnu]

Hi eetu,

 

thanx for this explanation. Makes perfect sense. This is obviously what happens in the grey screenshot. But what happens in the orange screenshot? Here the velocity attribute of the particles gets advected by the velocity field before the Euler integration step is performed. Why is this?

 

Best Manuel

[TheDude]

 

this video is a really clear and short example of how it works, super useful

[mnu]

Thank you Jamie. I watched this literally 8 times althogether over the course of the last year. And I think I understand everything that Jeff explains. But he does not mention the advection I screenshotted in my first post. That's why I'm asking.

 

best Manuel

[eetu]

Ok. I think I can walk through it, at least let's try.

 

 

Coming in, particle v is the flip velocity at the location of that particle in space. A point sample of the velocity field calculated above.

 

stash_flipvel - we store the point sampled v to flipvel point attribute.

 

advect_particles - we calculate the path traveled by the particle in the substep, and store the vector from start to end in v. (Note that Update Position is disabled and Update Velocity enabled). This is properly advected in steps by taking a new sample from the vel volume at each step, and the point where the particle ends up is probably different from where it would be if it just had the point sampled v for the whole timestep.

 

calc_vec_back_to_flipvel - here we subtract the former from the latter, so now flipvel in essence contains the "error term", how much the actual advection differs from just integrating with v for the duration of the timestep.

 

integrate_particles - here the particles are actually moved and collision detection applied. (Maybe external forces applied too, I'm not sure?) This node doesn't read the vel volume, so it only integrates using the point sampled v.

 

update_v_back_to_flipvel - here the "error term", or rather "correction term" stored in flipvel is added back to the integrated v.

[mnu]

Hi eetu,

 

thanx again. So basically this operation is calculating a correctional term. But isn't the flip update and actually the whole solve done for every substep? If so the flipvel already contains a velocity that is based on a field sample per substep, no?

 

As v is changed before the integration happens, that means the Euler integrator uses the already advected velocity. And after this the velocity is restored to the flipvel value. Why do they do this with the difference vector. Wouldn't the result be the same if they just copied the original flipvel back to v again?

 

The Euler Integrator only integrates velocity to P as "Integrate Velocity" is checked. As far as I understand it does not change the velocity while doing so. 

 

I have to admit that I don't really get what this is good for. But thanx alot for your effort to clarify things. I would love to really understand the solver to be able to tweak it. But maybe this is to much of a desire :-)

 

best Manuel

Edited June 3, 2015 by mnu

[eetu]

But isn't the flip update and actually the whole solve done for every substep? If so the flipvel already contains a velocity that is based on a field sample per substep, no?

The whole solve is done according to the timestep specified on the top level of the dopnet, which is at 1 timestep per frame by default. There are some finer grained substep settings, but they happen within the processing of individual nodes (advection, project nondivergent etc), so the global timestep can be comparatively long. If the velocity field has a lot of curvature, the properly advected particles do move along curved paths and the difference to linear integration can be meaningful.

 

As v is changed before the integration happens, that means the Euler integrator uses the already advected velocity. And after this the velocity is restored to the flipvel value. Why do they do this with the difference vector. Wouldn't the result be the same if they just copied the original flipvel back to v again?

Ah, true, good catch, the integrator does indeed use the properly advected v - and that does cast some shadows over my interpretation of the whole thing. Oh well, refer to my signature.. Needs some more pondering.

The Euler Integrator only integrates velocity to P as "Integrate Velocity" is checked. As far as I understand it does not change the velocity while doing so.

That's a good question, although as it handles collisions, it would be weird if the collided particles didn't have correspondingly reflected velocities..