Border colissions ignored?

[GottfriedHofmann]

Open the file from here: https://blenderartists.org/forum/showthread.php?373547-Lets-talk-about-Mantaflow&p=3215074&viewfull=1#post3215074

It has front, back, left and right unchecked, yet still the fluid starts filling the domain.

[GottfriedHofmann]

Oh and another thing I just noticed - when you change the resolution in that file to 128 it goes completely nuts...

[sebbas]

Oh yes, I see. Particles seem to hit domain borders that should not exist (i.e. open border).

I just looked at the scene in Mantaflow and found a small issue: setObstacleFlags() from Mantaflow currently sets cells at the domain border (those ones used for fractions) to type "Fluid" instead of "Outflow".

8379725 and 3ee4f50 fix this issue. setOpenBound() now also accepts phiOut as an additional (but optional) argument.

[GottfriedHofmann]

with the latest fixes the file acts weird both with 64 and with 128 resolution (top: 64, bottom: 128):

[sebbas]

Looks like too many drop particles. My first impression: Liquid leaves the simulation at the domain sides correctly now and so no volume of liquid builds up.

This also means that there is one "kill" condition less for drop particles (delete inside liquid). And so they just accumulate.

Solution should be to resetOutflow() for drop particles similarly to FLIP particles. That's currently not happening.

[GottfriedHofmann]

Btw: this is how the file simulates now without drop particles enabled - the inflow seems to be way stronger now:
Resolution 64 - https://www.dropbox.com/s/hhcbf6hfvp710cd/64.avi?dl=0
Resolution 128 - https://www.dropbox.com/s/3yn6aiil9dfkc55/128.avi?dl=0

[GottfriedHofmann]

I reduced the size of the emitter (at res 128) and the result is still extreme - it does not look accurate - it rather seems like the particles get multiplied and accelerated when hitting an obstacle...

[GottfriedHofmann]

Interesting comment on BlenderArtists about the settings in the file https://blenderartists.org/forum/showthread.php?373547-Lets-talk-about-Mantaflow&p=3216759&viewfull=1#post3216759

Blend file uses two settings that are always giving me unstable and unpredictable results.
Adaptative stepping : it avoïd particles death and always fills the domain for me.
A radius value different than 1 : Particles may die without logic and have an erratic movement.

[GottfriedHofmann]

After the comment I tried without adaptive stepping, which really helped the result:

And then with particle radius of 1.0, which made things slightly worse again:

It seems like adaptive stepping makes problems :(

[GottfriedHofmann]

Here the result without adaptive stepping and radius 1.0 and a time scale of 0.2:

[sebbas]

Yes, since adaptive time stepping just steps "more" for each frame it's like multiplier to this issue. I found that the root cause is probably because of different walls representations. On one hand the "Flag" grid now correctly sets outflow cells, on the other hand there is still the obstacle levelset representation which does not account for that. Going to try to "sync" them now .

[thunil]

Hi everyone, interesting, that the adaptive time stepping seems to be the culprit (or one of them). The inflow object probably uses an inflow velocity, right? Maybe there's something wrong with the velocity scaling... Sebastian - could you send me an export of the manta scene (only the python file)? Then I can take a look. Thanks, cheers, -> Nils === Technical University of Munich , http://ge.in.tum.de/ ===

…

On 12. Jul 2017, at 17:24, Sebastián ***@***.***> wrote: Yes, since adaptive time stepping just steps "more" for each frame it's like multiplier to this issue. I found that the root cause is probably because of different walls representations. On one hand the "Flag" grid now correctly sets outflow cells, on the other hand there is still the obstacle levelset representation which does not account for that. Going to try to "sync" them now . — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APrHfH61GTDa-_2D1VhwdkuuZrQ8UA9bks5sNOUegaJpZM4OUM8o>.

[GottfriedHofmann]

The inflow object probably uses an inflow velocity, right?

No that box is unchecked. It is a basic inflow object.

[sebbas]

After some experimentation, I am now boiling it down to the following: As long as all domain walls are closed the simulation runs fine for me. Once at least one wall is open, things get out of order.

So ideally, Nils, it would be helpful to have a Mantaflow liquid scene with fraction and additionally open domain support. That is, for example, an adapted version of flip06_obstacle.py where one can set arbitrary open borders.

That would be helpful. Here is also the Mantaflow script from that Blender file (at frame 30):
https://www.dropbox.com/s/29egm9kx6mo9mgy/manta_scene_github_issue_%237.py?dl=0

[thunil]

Ah, thanks! Good to know. Actually, the open boundaries also use a kind of velocity extrpolation - maybe they don't properly take the timestep into account! I'll check... Cheers, -> Nils === Technical University of Munich , http://ge.in.tum.de/ ===

…

On 12. Jul 2017, at 20:15, Sebastián ***@***.***> wrote: After some experimentation, I am now boiling it down to the following: As long as all domain walls are closed the simulation runs fine for me. Once at least one wall is open, things get out of order. So ideally, Nils, it would be helpful to have a Mantaflow liquid scene with fraction and additionally open domain support. That is, for example, an adapted version of flip06_obstacle.py where one can set arbitrary open borders. That would be helpful. Here is also the Mantaflow script from that Blender file (at frame 30): https://www.dropbox.com/s/29egm9kx6mo9mgy/manta_scene_github_issue_%237.py?dl=0 <https://www.dropbox.com/s/29egm9kx6mo9mgy/manta_scene_github_issue_%237.py?dl=0> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APrHfC7JTUwwqbIz9pkQ6KESB5eU3fJmks5sNQ04gaJpZM4OUM8o>.

[GottfriedHofmann]

Btw: this is what I get when I set all borders to collide (with 0.2 time stepping, no adaptive step and 1.0 radius)

[guilliamPL]

Hi,
More testing after commit https://developer.blender.org/rBfeda06e184ff0ebcddf6587a5ddcfba6a78bb78c

Video:
https://youtu.be/bk_sq1myXmM

Best,
Guilliam

[GottfriedHofmann]

Hey @guilliamPL can you run the tests with 128 res as well? Because that was the resolution I ran all my tests in (it seemed like a higher resolution made things worse).

[guilliamPL]

@GottfriedHofmann No problem. Please just send me your .blend file.

[GottfriedHofmann]

@guilliamPL it is the same one as you used with res 128 :)

[sebbas]

Regarding the liquid becoming "too fast" issue (as seen in Gottfrieds screenshot #7 (comment)):

The problem might be related to the primary velocity advection: What if, for instance, the domain is declared as open (no walls at all) but instead you manually set six walls with obstacle objects? Advection would then, due to the domain seemingly being open, try extrapolate velocities into outflow cells. However, in reality they don't exist since we placed obstacles at all borders.

I tested the outcome of this scenario with the same "waterfall scene" but changed the following: All walls are declared open and six obstacle objects now surround the domain.

Test 1: Domain open flag (from primary velocity advection) is kept as is. Since walls are open it's automatically set to "True":

Problematic region in red. The liquid looks like it's "flying" away.

Test 2: Domain open flag manually set to "False" (in code). Because of the obstacle objects, we know that the domain should be closed:

Test 2 looks more realistic to me. This open domain flag clearly makes a difference.

[sebbas]

@GottfriedHofmann I think #7 (comment) is at least not related to velocities.

Because of the small timestep and the closed domain, there are lots of particles in a small space. They splash against the wall, spread and the resulting mesh therefore looks really awkward.

Adding min / max particle fields (i.e. how many particles per cell allowed) to control the amount of particles might be the solution to this problem.

[sebbas]

The "exploding liquid" issues (aka the "velocity bug" during GSoC17) are now resolved. The important part was to explicitly set velocities in the inflow region (i.e. with no initial velocity the inflow region gets velocity 0).

Commit 373d96e closes this issue.