# Baking a Fluid at 150res crashes, but baking at 300res doesn't?

I've been having this problem for a good week now. I have a very simple scene set up. Water comes out of a pipe and lands in a pan. There's literally nothing else.

That being said, whenever I try to bake the fluid at 150 resolution, my computer crashes. I noticed when attempting to bake with Task Manager open that Blender's ram usage goes up to 6GB (I have 8GB and am getting more this Summer). After I view the spike, it crashes.

I haven't always had this problem with baking, as I baked this scene at a resolution of 300 and had no problems. I would like to think that the linked scene would be harder to bake because the cup is a deformed shape, and this scene's pan is a square object (less geometry). Please correct me if i'm wrong.

Here's my fluid settings for the scene I'm trying to bake followed by my fluid settings for the cup scene (bake-d without issues).

The cup scene obviously would require more RAM, right? It even says so, so why can I bake that scene, but not a less demanding one? Its also worth noting that I have been able to bake the pan scene multiple times before it stopped working. Is there some kind of cache I might have filled up? I have tried reinstalling Blender and clearing the fluid cache folder.

Here's my RAM usage when baking the cup scene:

As I mentioned, when I bake the pan scene (at less than half the resolution as the cup scene) my RAM usage flies up to 6GB and crashes my computer.

Crashing .blend file:

• I wonder if the difference in simulation time is the issue, the pan will be evaluated for 4 (seconds?) while the cup for just .7 (seconds?) – user2816 Jun 4 '16 at 17:48
• @root I tried changing the time to .7, still crashed. – Josh Silveous Jun 4 '16 at 20:39
• Have you tried clearing your /tmp/ folder? – Shady Puck Jun 4 '16 at 22:31
• That would be the cache_fluid folder next to the blend file not the /tmp/ folder. – sambler Jun 5 '16 at 9:51
• @ShadyPuck I have tried both of these, neither work. – Josh Silveous Jun 5 '16 at 16:29

The issue with the extra ram usage comes from the tubing you have the inflow located inside. While the rest of your scene appears to be simpler than the glass simulation, this pipe as an obstacle around the inflow object is where blender is having trouble. It appears that the biggest issue is the bend in the pipe.

For a solution, cut the pipe as it passes into the domain and disable the fluid obstacle settings for the pipe outside of the domain.

The easiest way to do that would be to select the end of the pipe and the next edge loop and use P->Selection to separate the end into a new object.

• The water doesn't travel through the bend in the pipe. Look at my first screenshot, the sphere is where the water starts. – Josh Silveous Jun 5 '16 at 16:29
• I know the water doesn't go down there, but as an obstacle the whole object is used in the simulation, Actually it would seem to be the length of pipe not just the bend or number of vertices. If you use a small part of pipe as I suggest it uses about 500MB but if you then extend it back past the wall (just with verts at each end) it quickly uses over 7GB. – sambler Jun 5 '16 at 17:52
• I don't think that's the problem, because i was able to bake just fine with that same shape/structure before – Josh Silveous Jun 8 '16 at 5:10

After examining the Blend you provided, the solution to make this bake again is actually rather simple: Apply the scales of the sphere, the tube and the end ring on the tube. Doing this is always recommended when using physics. That's all I did, and this Blend here is baking fine again:

samblers idea of cutting the tube was by the way very valid: The tooltip in Blender on the volume initialisation type tells you explicitly that complex volumes might require too much ram in initialisation. You might also improve baking times if you follow that advise. I was in a first test also scaling down the emitter sphere in the tube to 0.8 before applying scale, because I could see intersections between fluid mesh and tube on the very first frame already. That was while I turned the fluid collision off for the tube alltogether, and then it baked immediately.