Thin Fluid Flip - Reducing PartSep makes it worse?!

[dpap]

Why when I reduce  Particle Separation looks worse than iot did when it was higher?

 

Adding resolution to the sim by reducing part. separation shouldn't just give more details to my fluid?

 

Why is it reducing the amount of surface that is being coverd by the fluid?

 

At the right side of the fluid almost half of the surface is not covered as it was when part.sep was 0.01

 

How can I have the whole surface covered and have enough resolution/detail at the same time? Am I doing something wrong?

 

Thanks!

thin fluid flip.hip

[gui]

the values are too low. I think u shouldn´t use particle sep lower than 0.03, don´t know where I heard it.

 

Try to fake it somehow (since it´s cg, it´s already fake!), perhaps using a thicker emitter than resizing it...

 

I know I didn´t answered your question, but as far as I know, I would take the route I am telling you.... 

[danw]

FLIP fluids don't behave entirely predictably when you change the resolution... they're meant to, but there are so many factors involved that it takes a lot of testing and experience to learn what effect changes will have.

 

Lower resolution fluids tend to fill a larger volume than the same sim at a higher res - as all FLIP fluids tend to be slightly oversized by around the thickness of the radius of the particles... if you increase the res, you reduce the particle radius, gaining finer details, but also reducing the bulk of the fluid.  It's more noticable in certain cases than others, but I've found it's almost always the case.

 

...so, the simple answer is, you don't have enough fluid to fill the area you want it to... emit slightly more when you increase the resolution.

 

 

There are also numerous issues that can cause volume loss (or gain)... If you double the resolution of a sim, but keep the timesteps the same, your particles are traveling across twice the number of cells per-timestep, and if they cover too may in a single step, the fluid simulation can't preserve the volume of the fluid, and it'll continually shrink as the sim runs.

 

 

Collision separation only defines a higher/lower resolution collision field, which in this case would probably make very little difference, as you don't have a lot of fine-detail in your collision object.  I don't think it affects offsets or anything else, just the detail level that the collider is transfered into the simulation at.

 

If you want to bulk up your sim a little, you can also increase the Particle Radius Scale... although that will tend to lose details and make the sim more blobby.  I'd say you're best off just increasing the physical size of the fluid you're emitting, and testing your timestep settings to make sure you're avoiding volume loss.

[dpap]

@gui  "Fake it!!!" I keep saying that to myself but in this case I dont' know how ! 

For particle separation as far as I know depends heavily on the size of simulating objects/ scene size. I mean 0.03 is propably fine for aswimming pool but for a glass of water it can go down to 0.001!

 

Check the last post on this:

 

http://forums.odforce.net/topic/18684-fluid-simulation-and-scene-scale/?hl=%2Bflip+%2Bscale

 

 

@dannw   Thanks for all the info! I tried with a bigger source as you and gui suggested but not much has changed have a look

 

http://vimeo.com/user26136771/firsttest

 

Btw I thought that the "Sub steps" parameter was the one on the AutoDopNetwork but then realized it was the "Substeps" on the flipsolver ..Quite confusing. I'll resimulate with more substeps as well and repost the results.

 

Thanks guys!

 

Edit: I did resimulate with 8 substeps(and bigger source) but the difference is small. It's a little better than the oginal sim but nothing great.you can see the attached video.

8 substeps.avi

Edited March 23, 2014 by dpap

[gui]

Hi! Whats the problem with increasing a little the thickness of the source and collision??

 

I have changed the gravity too. See if was what you were looking for...

thin fluid flip.hip

[dpap]

Thanks Gui for your answer.

However I am afraid that with so high particle separation you can't get a mesh with nice details. Your file gives me similar results to the first picture( on the right) ...I need more detail.

 

Can anyone clarify for me if the flipsolver has an adaptive step which decreases or increases during the sim  ?

 

And the way I control this is with the value of the CFL  condition , did get that right?

 

What's role of the  "Sub steps" parameter on the  AutoDopNetwork Node?

Edited March 25, 2014 by dpap

[LPriest]

Substeps in the autodop network is the substeps of the entire simulation.

For example if you have fast moving collision objects or emitter DOP substeps are the answer so you can emit and collide on subframes.

-Everything in DOPS will recook on each substep.

 

The CFL condition will adapt how many substeps are taken based on the distance the particles travel, useful for fast moving particles.

This doesn't sound like it's useful to your case.

 

One thing I'd do off the bat is change your update velocity method to rebuild, this is the more correct FLIP method.

If this is set to the default the velocity field for the next frame after each step is adveted from the divergence solved velocity field rather than rebuilt from the particles. This can result in very stringy inaccurate results in some situations.

 

I'd also go inside the flipsolver and change the advection method on the advect_particles DOP to HJWENO which is a nicer advection method.

 

The thing I think you're battlign against is the resolution of your velocity grid, change 'grid_scale' parm on the flip object from 2 to 1 and see how you fair.

 

L

[danw]

I'm not so certain about the Update Velocity method (or the Update Surface method for that matter)... I presumed similar, that it would have a major effect on the simulation, but when I've tested it, setting "None", "Advect" or "Rebuild" all seem to give an identical simulation result.

After digging around in the FLIP solver, as far as I can tell the field-setup stage of the simulation always rebuilds both fields from the particles no matter what you pick... the difference is that the final result at the end of a timestep is after the particles have been advected by the result of that timestep, but the rebuild doesn't happen until the start of the following timestep, so your cache of the simulation will have the previous frame's surface and velocity stored if you selected "None".

 

As far as I can see, this only affects the whitewater simulation you'll run afterwards, as it requires the surface and velocity fields as well as the particles.  If you're using VDB meshing to build the final surface from the particles, I don't think the fields are used in that stage at all.

 

Setting Rebuild or Advect on the sim only actually appears to be forcing the sim to run the same process twice per timestep, once at the start and once at the end.  To my eye, it looks like you could get essentially the same result if the whitewater sim sourced the following frame's surface/velocity fields rather than the current frame's one... assuming you had pre-cached the FLIP sim (and ran an extra frame at the end)

 

(EDIT: Actually, thinking about it, the velocity field gets manipulated after it's rebuilt at the start of the timestep, so selecting "None" would actually give you the velocity field after it'd been pressure-solved and whatnot, not a copy of the previous frame's velocity... so presumably it is important to "Rebuild" it... but still only so that it's accurate for the whitewater sim.  If you're not running a whitewater, I can't see much point turning it on.)

 

 

Interesting information about the advection method.  I'll have to do some testing to see what effect switching to HJWENO has.  It struck me as odd that they wouldn't have selected the most accurate method as default... but then I read the help page and it contained the immortal words "...it will explode" :-P  So I guess under certain conditions it isn't quite as stable!

Edited March 29, 2014 by danw

[ikarus]

You kind of need to look at the flip solver as an approximation to what an infinitely-detailed simulation would result in.  Low resolution effectively blurs your results, smoothing out higher frequency behaviors which over the course of a simulation can give you a vastly different end result.

 

my 2 cents

[johner]

I'm not so certain about the Update Velocity method (or the Update Surface method for that matter)... I presumed similar, that it would have a major effect on the simulation, but when I've tested it, setting "None", "Advect" or "Rebuild" all seem to give an identical simulation result.

 

[snip good conjecturing on Update methods]

 

Interesting information about the advection method.  I'll have to do some testing to see what effect switching to HJWENO has.  It struck me as odd that they wouldn't have selected the most accurate method as default... but then I read the help page and it contained the immortal words "...it will explode" :-P  So I guess under certain conditions it isn't quite as stable!

 

You've pretty much got it right on the Update methods.  The surface and velocity fields are completely rebuilt at the beginning of each timestep from the FLIP particles.  This is expensive but an important part of the FLIP method; the particles are easy to advect along with their attributes, so you get close to zero numerical dissipation of things like velocity (some is added back in via the Smoothing parameter).

 

Updating the fields at the end of the timestep is *mostly* important for secondary effects, although the surface field actually needs to be updated at the end of each timestep be before you do any sourcing via SourceVolume emitters.  By default SourceVolume will kill any particles inside the existing surface field, which keeps the emitter from over-seeding voxels and forcing Reseeding to clean up afterwards.  Ideally you have an accurate surface field available for that, but it doesn't have to be *that* accurate so advecting forward by the velocity field is usually good enough.   Remember this is all per timestep, not per frame, so with the default 2 substeps it's only half-a-frame's worth of time before everything gets rebuilt at the beginning of the next timestep.  If you have no emitters and no secondary effects you can set Surface Update to None for a small savings.

 

You're also correct that it's not FLIP that needs the velocity field updated at the end of the timestep; it's only for secondary effects like Whitewater.  Before the Whitewater solver existed the Update Velocity mode defaulted to None; now it's set to Advect but can be switched back to None if you have no secondary effects.  Note however the the Velocity advection is only done at the end of each DOPNet timestep, not per substep (i.e. that Gas Advect Field is hooked up to the main GasMultiSolver within FLIP, *not* the Gas Substep).  So at the default settings it's done once per frame, while the surface advection is done per substep and usually twice.

 

HJ-WENO advection is designed for accurate advection of Level Sets like the surface SDF field, so it doesn't apply to the FLIP particles themselves (as noted above simple non-dissipative advection of the particles is one of FLIP's main advantages.)  It's possible we should be using HJ-WENO for the post-process of advecting the Surface field, but again it doesn't need to be too accurate and it's usually not necessary at that small a timestep.  It becomes more important when the surface SDF is your primary representation of the fluid and you need to retain an accurate representation / volume over time.

 

You kind of need to look at the flip solver as an approximation to what an infinitely-detailed simulation would result in.  Low resolution effectively blurs your results, smoothing out higher frequency behaviors which over the course of a simulation can give you a vastly different end result.

 

 

That's a good way to think about it.  Fluid simulation (*liquid* simulation in particular) is also fairly chaotic; small changes in the initial conditions amplify over time even before changing the resolution.  

 

This change:

 

Thursday, February 6, 2014 

Houdini 13.0.316: The FLIP Solver's Reseeding operation now uses a time-varying random function to generate new point positions, modulated by the new Random Seed parameter. The time-varying function fixes a bug that could cause streaking in the particle distribution with Reseeding enabled as slow moving liquid leaves a voxel. Varying the Random Seed can also be used to generate multiple simulations with similar bulk motion but different splash behavior from otherwise identical simulation parameters. Note this change will give different simulation results for any FLIP simulation that uses Reseeding.

 

 

 

 

 

 

 

 

 

 

just adds a Random Seed to the Reseeding parameter, but modifying it can give useful / noticeable variation even from identical initial conditions.

[Guest tar]

slightly related; what are we seeing when we run the simulation and have the playback at a rate of 0.1, or slower, in the playback options?

 

There appears to be a mysterious movement of the particles at each timestep

SlowMoFluid.hip

Edited March 30, 2014 by tar