resize container and -Y

[substep]

Hey Guys, I'm working on a fairly large pyro sim, and I can't seem to get the resize container DOP to do what I want.

Basically, I'd just like it to not resize into -Y. I'm running into lots of empty voxels below my groundplane, and would just like the bottom of the container, clamped to the ground.

In Maya, I can do this by making -Y a closed boundry, and turning off "resize closed boundries"

It seems like in H, If I attempt this, it still resizes my closed boundry, and pushed down into -Y.

Thanks for the help!

[Hudson]

Hi I am not sure what is wrong in youe scene. It would be easier to find a solution if you posted a scene isolating the simulation. Anyway here is an example scene doing exactly what you want to achieve. I have used the closed boundaries option several times in many simulations whitout any issues.

/chees

resize_od.hipnc

[substep]

Hi Hudson, thanks for your reply and scene file.

I think the only difference between the hip you graciously uploaded and my hip, was having clamp to initialized dynamic on.

I have it turned off, letting my container grow to where it needs to. But it seems that messes it up. On the second frame, the container resizes to fit the emitter, then clamps the -Y side of the container. Leaving my fluid that was once on the ground, now floating.

I guess I just want my container, that's sitting on the ground plane, to remain on the ground plane, and be able to resize every other direction freely, except for -Y

I'm somewhat new to pyro, and H in general. So I'm guessing I'm just missing something

Thanks!

Edit: I think answered my own question. But I guess I just dont understand the relationship between "enforce boundries" and "Clamp to Maximum size". Nevertheless, Just setting clamp to manual, and giving it a huge size limit, and setting the center Y to be half of the size Y.

Edited September 5, 2013 by substep

[Hudson]

Good to know the problem is solved. In the future try to read the help notes for the node you are using if you already haven't. SideFX has done a great job on documenting those. . Sometimes it is difficult to understand anyways. Often I create simple scenes like these and change the parameters so I can visualize the changes before applying into a larger sim..

[substep]

I did have another question though, but don't really feel the need to create another thread for it. Some of these sims I'm working on are very big, and can take many hours to sim. What's a good workflow for tackling these, assuming that at some point, the machine is gonna crash. lol.

What I've been doing is caching out sim files from the command, and loading those back in through explicit cache, then caching out the bgeo's. This works nice, cause I basically pick up where I left off if there is a crash in either the sim, or writing bgeos.

Now though, some of my .sim files are growing over 10gb a frame. So I stopped caching out sim files, and just starting caching out bgeo's directly. Except with "explicit cache" turned on, on the DOP net, and only caching 2 frames.

I thought this would work nice, as it only stores the last couple .sim files, and I thought i'd be able to pick up where it left off after a crash. But the DOP net complains about it, and won't load the sim to continue writing bgeo's.

I hope I explained that ok, Is there a better way that I'm just not aware of? or any tricks you can suggest?

Thanks!

[Hudson]

Hi again. glad I could help

I have to be honest I cannot remember last time I simed out something to disk. I usually go straigth for a bgeo

My tips to make these file smaller would be the following:

1. Delete all attributes you know you wont need before caching out a sim using an attributeSOP. It also includes the groups. In a pyro simulation you have 0 = density, 1,2,3 =vel, and others just middlemouseklick on your dop-import. Delete those using a delete SOP. Just remember to keep the name-attribute if you are deleting primitive attributes because it contains the fields you will want to keep (ex density, vel, temp and so on). If you want to use a .sim file you could do the same and just uncheck the fields you do not want to export.

2. Optimize your simulations. If you have a large sim you could simply break it down into smaller pieces. Recently I had to create a huge dust, sim to create and to speed it upp I actually kut the source into two halfs(it was an symetric source) in order to iterate faster

3. Go for a low-res sim to get the right motion and up-res it in a later stage. It will let you get through several iterations and at the end you win a lot of time. and spare some on your disk-space

This is what I can figure out by now

Edited September 5, 2013 by Hudson

[substep]

Hi, Thanks. That all makes a lot of sense, and helps a bit. I've done as much as I can to optimize, I'm a huge advocate of simplicity and trying not to overdo things... sometimes

I guess I'm just looking for a good simulation workflow, that allows for multiple houdini sessions (crashes) with the least amount of RE-simming/caching. In situations where it's much too expensive to 'start over' from a system meltdown. is there anything?

Thanks!

Edited September 6, 2013 by substep

[Guest tar]

Why are you getting crashes? It might be cheaper and better to have more Ram?

[substep]

Hmmm, I'm maxed out on ram. I figure 32gb, plus a 32gb swap would be enough.

[Guest tar]

The crashes part is the interesting bit - what's causing it?