AWS Thinkbox Discussion Forums

Deadline (Houdini/Redshift) leaves an empty directory in my image destination with the name of the submitter node

When rendering a Redshift job from Houdini, I’m finding an empty folder left over in the parent folder of my image passes. If the Deadline submitter node is named ‘SUBMIT’, the folder will be also named ‘SUBMIT’. This normally wouldn’t be a huge deal, but when we go to publish the renders, the empty folder causes problems, so we must delete it first before running scripts. Has anyone experienced this, or perhaps there is a setting that might fix the issue?

I’ve got the same issue, but no solution except manually delete the folder.

Do you guys render with Houdini 18.5? And what version of Redshift?

Yes, we are rendering Houdini 18.5.672 with Redshift v3.0.55, and Deadline Monitor
Any insights?

I have a problem when “$OS” is used in the filename it will also create a folder called “Director” where the “$OS” is in the filename expression. I never had that problem before recently, but it have popped up on Houdini 19 now to :confused:

bumping this for visibility. This is still happening and we may have to write a post render script to manage it.

Hello @goshone

Can you please elaborate more about this ? Have you renamed Deadline ROP Node ?

Please provide task report of Job to check If any logs written related to creating a folder, If possible please share the archived Job to check configs of Job.

Also, provide the sample scene file , any reference files if needed, reproduction steps that helps us to reproduce the Issue on our end!

Yes, I did rename the deadline rop node. Could this be the issue? If I leave it default ‘deadline’ the empty folder is also named ‘deadline’.
And I am using $OS in the output filename as described by Heileif.

As for the task reports, I have attached a couple

examples. There is one from the Redshift translation, and another for the Redshift render. I didn’t find much in them, other than this one line from the translation task.

C:\ProgramData\Thinkbox\Deadline10\workers\Bladerunner10-3\plugins\6451c6e60355f0364c05eb65\ DeprecationWarning: expandString is deprecated. Use hou.text.expandString instead.
2023-05-02 19:45:23:  0: STDOUT:   output_folder = hou.expandString(output_folder_unexpanded)

Job archives are attached as well a sample scene that reproduces the problem on our end.

Josh (10.6 KB) (288.5 KB) (16.9 KB) (129.0 KB)

@Nreddy, were the logs helpful? Were you able to reproduce the issue?

@goshone I saw this thread today and I haven’t tried reproducing this issue locally but will give it a try this week.

Also a quick skim on the issue and the script, it seems like a normal warning with deprecation on “hou.expandString” but should work fine as expected. If you run the Hython.exe on a command prompt and run these below line as python it should not error:

>>> import os
>>> output = "$JOB/img/$HIPNAME:r/$OS/`$HIPNAME`_`$OS`.$F4.exr"
>>> output_folder_unexpanded = os.path.dirname(output)
>>> output_folder = hou.expandString(output_folder_unexpanded)
>>> print(output_folder)

I found the lines in the log where it creates the ‘submit’ folder if it helps. It errored on this particular render, so I was able to catch it.

2023-05-18 17:38:49:  0: STDOUT: Begin Path Mapping
2023-05-18 17:38:48:  0: STDOUT: b''
2023-05-18 17:38:49:  0: STDOUT: b''
2023-05-18 17:38:49:  0: STDOUT: End Path Mapping
2023-05-18 17:38:49:  0: STDOUT: ROP type: Redshift_ROP
2023-05-18 17:38:49:  0: STDOUT: C:\ProgramData\Thinkbox\Deadline10\workers\Bladerunner10-2\plugins\6466c40bf810fc1eb65e0c67\ DeprecationWarning: expandString is deprecated. Use hou.text.expandString instead.
2023-05-18 17:38:49:  0: STDOUT:   output_folder = hou.expandString(output_folder_unexpanded)
2023-05-18 17:38:49:  0: STDOUT: Creating the output directory "//nebula/Jobs/Axion/seq/FBI522/FBI522_020/houdini/img/AXN_FBI522_020_fx_roaches_v009/submit"
2023-05-18 17:38:49:  0: STDOUT: Failed to create output directory "//nebula/Jobs/Axion/seq/FBI522/FBI522_020/houdini/img/AXN_FBI522_020_fx_roaches_v009/submit". The path may be invalid or permissions may not be sufficient.

@karpreet did you have a chance to look into this issue?

We rotate who owns the forums, so Karpreet’s off and I’m on now and your thread’s fallen victim to some untidy handoffs. Sorry about that, we don’t intend to have folks waiting on us like this.

I’ve loaded up your scene, and I’ve been fiddling with how we’re building the output folder path. But I’m not able to re-create your behaviour. I’m suspecting the submission settings aren’t properly travelling along with the scene file. While I’m working on this sine we don’t see this trailing /submit in your archive job, could I get an archive of the job who’s log you shared on the 18th?

Hi Justin,
I have included a log file and archive as you requested.
Josh (68.3 KB) (2.8 KB)

1 Like

Having the A/B comparison of reports is very helpful, thanks!

What’s really odd is we’re giving the script we control Houdini with the same inputs but are getting different results but each report is from a different Deadline Worker, as you’ve got multiple on the single machine for each GPU.

That command is this:

"C:\Program Files\Side Effects Software\Houdini 19.0.657\bin\hython.exe" "C:\ProgramData\Thinkbox\Deadline10\workers\Bladerunner10-2\plugins\6466c40bf810fc1eb65e0c67\" -f 1001 1010 1 -o "$JOB/img/$HIPNAME:r/$OS/`$HIPNAME`_`$OS`.$F4.exr" -g -d /obj/Outputs/floor_roaches -gpu 2 -tempdir "C:\ProgramData\Thinkbox\Deadline10\workers\Bladerunner10-2\jobsData\6466c40bf810fc1eb65e0c67\0_tempbC8zl0" -arnoldAbortOnLicenseFail 1 "//nebula/Jobs/Axion/seq/FBI522/FBI522_020/houdini/hip/AXN_FBI522_020_fx_roaches_v009.hip"

The way the output path is generated is based on this text printed before we start Houdini:

Output: $JOB/img/$HIPNAME:r/$OS/`$HIPNAME`_`$OS`.$F4.exr

But that’s not being regularly output. So either both renders aren’t sending the same string to be expanded, or token expansion isn’t creating that same outputs with the same inputs.

To that end I’ve added some prints to a copy of that’ll show what’s being passed into hou.expandString and what it’s returning before it’s used anywhere else in the code base.

To use that file, make a backup of the existing DeadlineRepository10\plugins\Houdini\ and replace it with the file attached. Given we’re someone relying on chance this shouldn’t affect regular rendering and just add some troubleshooting logs for us.

The goal here is to figure out if the issue is in how the text is being expanded or the data we’re passing to it. The bits I’ve added have #jusbla debug prints at the end if you’d like to take a look at what’s going on.

Thanks! (35.8 KB)

Ok, I’ll give it a try today and let you know.

Privacy | Site terms | Cookie preferences