Hi
when starting a top cook the current file gets saved and gets processed with something like this:

our current tools for farm submission work like this:

• the hip gets saved
  
• the hip file gets copied to a /submit directory with a unique hash added to the file
  
• now the file is used for processing on the farm, all file out nodes add this file path as a attribute in the geo
  

the reason why we do this is that whatever happens You for sure can restore a file with simulation settings, as long as You have a cache or a playblast You can hunt down the file that generated that cache. I would like to use that workflow with pdg as well, but is there a way?
now You work on Your file and might change stuff so it is impossible to recreate the simulation that might have been approved. As there can be a lot of dependencies in a file this easily happens.

right now the cooking process start a batch like this:

is there a way to modify this so we can inject the copied file, instead of the original hip?
something like this:

thanks
Martin

You can set your scheduler Working Directory to be something like $HIP/submit , then on the ROP Fetch options turn on Reset $HIP on Cook.

The scheduler should copy your hipfile to the working directory to be cooked, and the latter option makes sure all $HIP references point back to the original folder.

thank You, that is quite amazing.
Is there a way to generate a unique hip file name, so it does not get overwritten?

sanostol
Is there a way to generate a unique hip file name, so it does not get overwritten?

hi Martin,
not in front of Houdini, so only a guess:
maybe with a filecopy -> wedge -> filerename combination? And the Wedge with a single attribute (like an integer range called `@foo`), but one that uses a different seed for each cook?
just a try…
Fuat

EDIT: ah wait, wouldnt know how to change the seed per cook …hmm

Hi Fuat ,
I just want to have a snapshot of the processed file, not wedge dependent.
But as You constantly change stuff when working with TOPS and sometimes there are a lot of dependencies, things might change and simulations do not behave like in the cached version any more. Consider a collision object reused in several sims. and You change something for a later sim, that would also affect a sim that is already approved. And now You have to extend this approved simulation.
Right now this would be at least not cool. But when every sim that is processed gets a scnap shot version of the hip and the name of the snap is added as a attribute to the cache, You can easily go back and see what changed and fix it, or just sim the file. But You are not stuck.

sanostol
the hip file gets copied to a /submit directory with a unique hash added to the file

sorry for the confusion…you are right.

what i meant by the wedge was to use that random `@foo` integer variable (in the wedge TOP) in the copy/rename step, so for example
`oldname.hip` to `oldname_foo.hip`, like:
$HIP/myfile.hip would be copied & renamed to $HIP/submit/myfile_837426477.hip
and this should happen each time you submit (before it sends to your caching/ROP TOP)

(you could of course combine a mixed hash like on your case,
`oldname_int_string_int.hip`)

but again, since the random seed wont change, it wont work.
(i should think first, then write…next time

always appreciate Your input! maybe a custom cook tool could do the job, that thats a unique environment variable and copies a the file with the unique id as well.