Another bug bites the dust...

I meant to do a post about this yesterday (and another one on it a while back), but with all the finals stuff it kept slipping my mind (and also it seemed hardly too exciting).

After fixing the "particles explode" bug, Christine and I noticed that there was something still wrong with our water particle behavior - namely, that given enough time the particles would always compress down to the floor of the MACGrid. I've been trying to solve this final bug with the particle motion while Christine's been tackling level sets, and yesterday I finally figured it out. We have a function we named "constrain velocities" that sets velocities to zero on the boundaries of the MACGrid. We have it in our simulation in a place based on where we'd seen it in our notes, particularly in "Fluid Flow for the Rest of Us". As it turns out, though, we needed to run that step each time we modified our velocities (meaning after the advection AND projection steps), which in hindsight makes a lot of sense.

Not as exciting as Christine's update about working level sets (hooray!), but progress nonetheless. I've begun doing our final writeup as Christine finishes going over our level sets. This project is due tomorrow, but it seems as though we might finish...!

Marching Cubes ish

I've been working on implementing marching cubes and I've made some progress...It seems to be drawing the triangles semi correctly but I think our particles are not being distributed properly. Also, I can't figure out how to tell it to draw the sides since they're out of bounds... Here's a couple videos (particles aren't being drawn to size)

Sphere

 

Sphere with particles

 

Faucet

En route to level sets?

Soo I've been reading pretty much every document about level sets published online trying to make sense of it all because math is not my thing, and finally I decided to actually start writing code. I had been confusing myself with the 100 different ways that people do level sets, but I seem to have made some progress. I have cell centers drawn as yellow if they have a positive signed distance and pink if it's negative. I want to do narrow banding next, and tomorrow we're going to start investigating marching cubes. I haven't gotten a screen capturing software yet and we haven't worked out the frame rendering, so I made two super makeshift "animations". You get the idea though.... I threw in a couple stills afterwards as well since they're actually probably better to look at. As always, it's a work in progress. I'm just super happy we figured out the blowing up for the most part (Yay Jason! Stupid AMatrix...)

And Again!

I really don't know where these breakthroughs come from.

Literally over a week of trying to debug, and then three little lines after 20 minutes of code exploration fix everything.

I was going after our problem of "liquid sim explodes after a while," figuring that "code doesn't reset properly" could take a backseat for now. It's only after I gave up in frustration and took a stab at the reset thing that I was able to make any progress. Fixing the reset thing took under half and hour, and by doing so I ended up fixing both problems. Ugh.

Here's some video of a water sphere and a "faucet" running (in real time - not recorded). Maybe not the most elegant thing ever, but... Looks good to me! Feels pretty good, too.

 

The next step (I assume) is joining Christine on level sets and maybe then adding on some bells and whistles to the finished product. Though to be honest, with this little time left and finals starting up tomorrow, I'll be grateful if we get the level sets working properly in time.

That's all for now,

Jason

Where We Stand

Hi,

So here's where we are now:

We discovered that dynamic cell resizing actually still works, and solved a small problem where we thought my updated code didn't work on Christine's computer (turns out it did). We realized that we weren't extrapolating velocities in the Z direction yet (as our early tests were in 2D and we just recently switched over to 3D) and we fixed that as well.

We have two main problems now.

The first is that, after a while, the particles stop behaving like water and simply explode (I've included a video below).

The strange thing about this is that oftentimes the PCG stops converging at the moment of impact with the ground, but the simulator will continue running like water for a good while afterwards before exploding. However, when we use a smaller number of particles (say 3) spaced out a good distance from each other, the PCGs always converge and the particles eventually come to a stop (as expected). The more particles we use, the faster the sim explodes (faucet gives us only a few moments of behaving properly). We think there's a few things that could be happening here:

1. Overlapping particles are causing insane, impossible pressures, causing the velocities to explode (Karl notified us of this one - he said the same thing had happened in his sim when they initialized particles in the same place). It would explain why the more particles there are the faster the simulation explodes, as more particles means higher probability of a collision.
2. There could be weird boundary conditions we're neglecting. There seems to be something strange going on with ground plane collisions, even when everything is converging properly and we're only using a few particles. Theoretically, the pressures should eventually cause all the velocities to go back to 0 (I'm assuming - I can't find confirmation of this), which is not happening even in the few particle case.
3. Memory issues. We don't have specific cause to believe this past "more particles = faster explosion", but I think we're both always suspicious of memory issues.

Our other problem, and the one we're really confused by, is that resetting the sim gets different results. Right now if we run the sphere sim twice then the first time it gets accurate results (then explodes) and the second time we get slightly less accurate results (it seems almost viscous, despite our having not implemented viscosity, and the motion is a bit off) but it also takes slightly longer to blow up. Even when we use only one particle, velocities of the sim come out different in the reset run. We don't know what the issue could be... We reset absolutely everything when "reset" is called. This will require a lot more debugging.

Since we know we need to try to implement level sets now, we've decided to start dividing up our labor (up until now it's been "let's both try and figure out what's going wrong"). I'm going to try to debug our current code over this weekend, and hopefully figure things out by Monday (I'm not entirely optimistic). Meanwhile, Christine has agreed to start looking at level sets and maybe start an implementation by that time as well. We'll see how it goes!

-Jason

P.S. If anyone reading this has any idea what the nature of our problems might be, please let us know!

And so it came to pass! (aka Finally!)

Wow. This feels like it's been a long time coming.

First of all, credit goes to Christine for not only being the one to realize we were setting up our A-Matrix wrong, but for essentially rewriting the linear algebra code from our smoke sims on a fundamental level to make things work (even if we ultimately don't use it). Also thanks to Joe, for confirming the theory I'd had (and dismissed) that we should be able to use the linear algebra code from the smoke sims if we just set all the values in rows of non-liquid cells to 0. With that in mind, I was able to go back into the code and pull this together:

http://www.youtube.com/watch?v=lX5Jyq8SNcI

 

You'll probably notice (of course) that not long after it hits the ground, the water... er... explodes, for lack of a better word. We're still working on that - after a certain point our PCG solver stops converging, resulting in insane, impossible pressures getting applied to the velocities and making the sim go crazy. We'll hopefully work out that bug soon.

Still, the main code clearly behaves as it's supposed to (up to a point), so the hardest part is (hopefully) behind us!

Here's a list of things we still need to do:

• Fix our "does not converge" error so that the liquid stops behaving erratically.
• Figure out the reason why resetting the simulation leads to more does not converge errors, and a difference in fluid behavior all around (less accurate on each "reset").
• Allow for dynamic cell sizes. After a quick test, I've discovered that somewhere in our code we stopped being able to handle it if the cell size is not 1.
• Level sets. We received feedback from our alpha (generally positive despite lack of working fluid simulation - thanks, Joe!) that said we really need level sets for our final project. So as soon as the bugs are ironed out of this one, that's likely the first thing we'll be tackling.

I'll update soon with more videos with cool stuff like larger cell sizes and different ways of initializing water (rectangular prisms, larger spheres, and a continuous water flow we call the "faucet") once we iron out a few of these errors.

Thanks for everything!

More debug progress!

So, after debugging and debugging for days, Jason and I have finally found the (hopefully) real root of our problems... we were setting up the linear system that needs to be solved to make the fluid cells divergence free completely wrong. We didn't adjust the setup from the setup of the smoke system and we've realized after some help from this paper that we need to completely alter our function setUpAMatrix(). We've figured the dimensions of our square matrix should actually be the number of cells that contain liquid, and there doesn't actually need to be a row and column for every cell in the MAC Grid as with the smoke simulation. So, we're going to have to change the implementation for our sparse matrix and pcg solver.

On a side note, while working on our Alpha Review we've realized our previous 3 step approach was completely out of order (we thought steps that came later came earlier and vice versa) so we are re-organizing our whole game plan. It's going to be a long night/couple of weeks but at least now we've figured out the main issue.