Interrupted Simulations

[art3mis]

I often find myself interrupting a long simulation just to ensure everything is working as it should.

But then when I try and finish the simulation  by specifying the frames where I left off, I often find that I am recooking the same frames, starting at frame zero.

For instance I interrupt the simulation at frame 100, then in the Cache or Vellum IO SOP specify the start frame as 101 and end frame as the last frame in my sequence.

Then a Save to Disk shows that I am recooking frames 1 thru 100 instead of starting at frame 101 as specified.

Why, and how do I prevent this from happening?

 

 

 

[ikoon]

Hi Jim, do you use .sim files? Enable Save Checkpoints and if you want to stop at any frame (not just after Checkpoint Interval), then you might like the Checkpoint Trail Length

http://www.sidefx.com/docs/houdini/nodes/obj/dopnet.html

[vicvvsh]

13 hours ago, art3mis said:

I often find myself interrupting a long simulation just to ensure everything is working as it should.

But then when I try and finish the simulation  by specifying the frames where I left off, I often find that I am recooking the same frames, starting at frame zero.

For instance I interrupt the simulation at frame 100, then in the Cache or Vellum IO SOP specify the start frame as 101 and end frame as the last frame in my sequence.

Then a Save to Disk shows that I am recooking frames 1 thru 100 instead of starting at frame 101 as specified.

Why, and how do I prevent this from happening?

 

 

 

 

Did you change Start Frame parameter wherever you simulated: in a Dop Network or a Vellum Solver?

Edited January 15, 2019 by vicvvsh

[art3mis]

Thanks guys! Need to revisit the documentation on the difference between .bgeo and .sim files.

The VellumIO SOP doesn't seem to have CheckPoint options. Will look at changing my workflow, perhaps with Cache SOP or...

 

No I usually never change the Start Frame on the actual Solver node.

[vicvvsh]

10 minutes ago, art3mis said:

No I usually never change the Start Frame on the actual Solver node.

When you simulate from not first frame you should

[anim]

you can try to increase cache memory for your sim

if the dopnet has all frames cached in the memory up until where you stopped it should just continue if you ask to render from there, unless something is invalidating the cache upon hitting the Save To Disk Button

so it may be dangerous as you are always risking that

 

you can also just do your initial cache by hitting Save To Disk In Background, which will do the sim in a separate thread

so in your scene you will be able to read and see how the sim is progressing, if you like it just let it finish or keep checking as the frames are being simmed

if you don't like just kill the background process

[Midasssilver]

.sim files are not a thing with the vellum solver sop. You need to use the vellum dops in a dopnet to have access to writing out .sim files.

Edited February 14, 2019 by Midasssilver

[madebygeoff]

I would love if someone had a better way to do this, but for very long sims, I've often broken the sim into segments with multiple solvers and IO nodes.

1st Vellum solver, 1st Vellum IO caches say 1 - 500, then plug that into another (2nd Vellum) solver with the same or similar settings but with start frame set to 500, and another Vellum IO caching say 500 - 1000. Then at the end you can just sequence blend between the two caches.

It's not pretty, but it works. Plus you can fine tune the sim settings slightly for each section of the sim if necessary and blend between them.

Also, there is the "File Mode" settings on the Vellum IO node. If you set it to "automatic" it is supposed to look and see if there is an existing frame and use that, and only if there isn't, then cook a new frame. However, I find that it works sometimes and not others and I haven't figured out why yet.