David Oberst
davidoberst
About Me
Connect
LOCATION
Not Specified
WEBSITE
Houdini Skills
Availability
Not Specified
Recent Forum Posts
Tractor and Python 3 Jan. 6, 2022, 10:12 a.m.
Actually, you can write "str" to the tempfile if you open it with mode='w' or 'w+a', but converting the Tractor TCL 'str' text to bytes for the write() call would be good enough in this case. With the fix, the 'cook' task on the farm successfully spawns all the dynamic frame tasks to Tractor and the job succeeds? That would be great - I was reluctantly going to look into monkey-patching around this bug. It looks like 19.0.491 is there as a daily now - any rough idea when the next production build will be put together from 19.0.491 or higher?
Tractor and Python 3 Jan. 5, 2022, 12:37 p.m.
What's the status of Tractor and Houdini 19/Python 3? While Pixar hasn't done a full Python 3 Tractor release yet, they do have their "tractor" Python API package converted, in Renderman 24. We don't have RMan24, but they also provided a beta of the package in their forum, and we've been using that successfully with Nuke 13, for instance, and put it on PYTHONPATH for our Houdini 19 setups. We can do PDG/TOP submissions from Windows to our (linux) Tractor farm, but when the main PDG cooking task runs on the farm, it throws the error below, in pdgmq.py.
It looks like TractorSpooler.spool_tractor_task() has a "drain()" subfunction which creates a NamedTemporaryFile and tries to write the TCL text of a tractor job to it. In Python3, the temp files get opened "w+b" by default, and the write() method wants "bytes", while the TCL job text is a "str". The temp file should probably be opened with in explicit "w" mode so it will accept the TCL "str"?
Does a basic spooling problem like this mean Tractor is not currently supported by Houdini 19?
It looks like TractorSpooler.spool_tractor_task() has a "drain()" subfunction which creates a NamedTemporaryFile and tries to write the TCL text of a tractor job to it. In Python3, the temp files get opened "w+b" by default, and the write() method wants "bytes", while the TCL job text is a "str". The temp file should probably be opened with in explicit "w" mode so it will accept the TCL "str"?
Does a basic spooling problem like this mean Tractor is not currently supported by Houdini 19?
Exception in thread Thread-1: Traceback (most recent call last): File "/opt/houdini/hfs19.0/python/lib/python3.7/threading.py", line 926, in _bootstrap_inner self.run() File "/opt/houdini/hfs19.0/houdini/python3.7libs/hou.py", line 99522, in __threadRun self.__run() File "/opt/houdini/hfs19.0/python/lib/python3.7/threading.py", line 870, in run self._target(*self._args, **self._kwargs) File "/opt/houdini/hfs19.0/houdini/python3.7libs/pdgjob/pdgmq.py", line 211, in drain tempf.write(self._tractortaskqueue.popleft()) File "/opt/houdini/hfs19.0/python/lib/python3.7/tempfile.py", line 481, in func_wrapper return func(*args, **kwargs) TypeError: a bytes-like object is required, not 'str'
Tractor farm error with 18.5 Jan. 27, 2021, 4:48 p.m.
We have some code that automates selecting and triggering the submission of scheduler nodes to our Tractor farm. It has worked with 17.5 and 18.0, but with 18.5 the farm tasks spawned by the main PDG Cook task fail when Tractor tries to launch them, with hython complaining it can't find "<pdg_workingdir>/67890/pdgtemp/scripts/pdgjobcmd.py". "<pdg_workingdir>" is the path we supply to the scheduler.
With 17.5 and 18.0, Houdini put a copy of the .hip file and a "pdgtemp" dir into "<pdg_workingdir>", and inside "pdgtemp" were two directories with arbitrary 5-digit numbers as names, say "12345" and "67890". Both of these had a "scripts" subdirectory with "pdgjobcmd.py".
With 18.5, the two numbered subdirs are now at the main level of "<pdg_workingdir>". Both have a "pdgtemp" subdirectory, but only one ("12345") has the "scripts" subdirectory. Either your farm task code is writing the wrong numbered subdir into the hython command, or the scheduler setup isn't copying the "scripts" subdirectory into that numbered subdir as it does with the other one?
I'm going to have to dig back into that stuff again, but as far as I remember, all of that would be controlled by Houdini code given the "<pdg_workingdir>" we supply it, and nothing we'd be doing in configuring the scheduler node should be able to cause this sort of breakage? We're using 18.5.408 (submit from Windows, Python2, farm is Centos), and I also tried the current production build 18.5.462 on the submit machine.
With 17.5 and 18.0, Houdini put a copy of the .hip file and a "pdgtemp" dir into "<pdg_workingdir>", and inside "pdgtemp" were two directories with arbitrary 5-digit numbers as names, say "12345" and "67890". Both of these had a "scripts" subdirectory with "pdgjobcmd.py".
With 18.5, the two numbered subdirs are now at the main level of "<pdg_workingdir>". Both have a "pdgtemp" subdirectory, but only one ("12345") has the "scripts" subdirectory. Either your farm task code is writing the wrong numbered subdir into the hython command, or the scheduler setup isn't copying the "scripts" subdirectory into that numbered subdir as it does with the other one?
I'm going to have to dig back into that stuff again, but as far as I remember, all of that would be controlled by Houdini code given the "<pdg_workingdir>" we supply it, and nothing we'd be doing in configuring the scheduler node should be able to cause this sort of breakage? We're using 18.5.408 (submit from Windows, Python2, farm is Centos), and I also tried the current production build 18.5.462 on the submit machine.