1. HOUDINI_PATH内にpdg/typesディレクトリ(例えば、~/houdini18.5/pdg/types)を作成します。

2. 新しいスケジューラにちなんだ名前のディレクトリを作成して__init__.pyファイルを追加(例えば、~/houdini18.5/pdg/types/customscheduler/__init__.py)することで、カスタムスケジューラ用のPythonパッケージを作成します。

3. その新しいパッケージディレクトリ内にカスタムスケジューラ用のPythonモジュール(例えば、~/houdini18.5/pdg/types/customscheduler/customscheduler.py)を作成します。

4. そのcustomscheduler.py内部でスケジューラタイプを実装します。すぐにでも何かを動作させられるように、最初のうちは私どもの内部スケジューラをサブクラス化するのが便利かと思います。以下には、ジョブを連続生成するLocal Schedulerの単純な例を載せています。

import os
import shlex
import subprocess
import sys
import tempfile
import six.moves.urllib.parse as parse

# LocalSchedulerクラスをimportできるように、$HFS内のスケジューラタイプフォルダをPYTHONPATHに追加します(この時点ではLocalSchedulerクラスはまだ読み込まれません)。
import pdg
sys.path.append(os.path.expandvars("$HFS/houdini/pdg/types/schedulers"))
from local import LocalScheduler
sys.path.pop()
from pdg.utils import expand_vars

class CustomScheduler(LocalScheduler):
    def onSchedule(self, work_item):
        print("onSchedule {}".format(work_item.name))
        item_command = work_item.command
        item_id = work_item.id
        item_command = self.expandCommandTokens(item_command, work_item)
        job_env = self._generateEnvironment(work_item, 0)
        # 必ずディレクトリが存在するようにし、ワークアイテムをシリアライズ化します。
        self.createJobDirsAndSerializeWorkItems(work_item)
        # ジョブ変数を置換してから、Houdini変数($HFSなど)を置換します。
        item_command = expand_vars(item_command, job_env)
        item_command = os.path.expandvars(item_command)
        self.workItemStartCook(item_id, -1)
        # shlexを使用したいので、コマンド内にはunicodeが含まれないようにします。
        if sys.version_info.major < 3:
            item_command = item_command.encode('ascii', 'ignore')
        argv = shlex.split(item_command)
        try:
            log = subprocess.check_output(argv, shell=True, env=job_env)
            with tempfile.NamedTemporaryFile(delete=False) as f:
                f.write(log)
                work_item.setStringAttrib("custom_log", f.name)
            self.workItemSucceeded(item_id, -1, 0)
        except subprocess.CalledProcessError:
            self.workItemFailed(item_id, -1, 0)
        return pdg.scheduleResult.Succeeded
    def getLogURI(self, work_item):
        log = work_item.stringAttribValue('custom_log')
        if log:
            return parse.urlunparse(('file','', log, '', '', ''))
        return ''

1. __init__.py内部で、新しいスケジューラタイプを登録します。

from . import customscheduler 

def registerTypes(type_registry):
    print("Registering customscheduler") 
    type_registry.registerScheduler(customscheduler.CustomScheduler, label="Test Custom Scheduler") 

1. PDGは初期化する時に、新しいスケジューラタイプを登録するcustomschedulerパッケージをimportするようになります。PDGはTOPsのTabメニューにcustomschedulerを表示します。

1. TOPネットワーク内にPython Schedulerノードを作成します。

   このノードには、スケジューラの挙動を定義するコールバック関数用のフィールドが備わっています。 このノードは、他のスケジューラと同様に動作し、コールバック関数フィールドに入力されたPythonコードを評価して実行します。 これは、作業ネットワーク内でスケジューラコードを試行することができて非常に便利です。

2. このノードのタブで色々なPythonスニペットを記入する方法に関しては、以下のコールバックの実装方法を参照してください。

Initialization and Cleanup タブのPythonスニペットを使って、最初にスケジューラを起動した時に実行させるコード、TOPネットワークがクックを開始した時に実行させるコード、ネットワークがクックを停止した時に実行させるコード、スケジューラがもはや不要になった時に実行させるコードを記述します。

この作業ディレクトリは、TOP Networkのコードが実行されるディレクトリで、通常では生成ファイルが保存される場所です。 ファームセットアップでは、この作業ディレクトリを共有ネットワークファイルシステム上にしてください。 PDGは、作業ディレクトリのlocalパス、さらに、remoteパスも知っている必要があります。 localパスは、ユーザのファイルシステム上の有効なパス(ネットワークがクックする場所)で、remoteパスはリモートレンダーファームホスト上で有効なパスである必要があります。PDGで指定されたパスを使って、localとremote間のファイルパス変換が行なわれます(それぞれlocalize、delocalizeと呼びます)。

localとremoteのパスを生成/変換するコードは、スケジューラによって異なります。 例えば、スケジューラソフトウェアには、共有ディレクトリを検索するための独自のAPIが用意されていたり、システム環境変数(例えば、$REPO_DIR)を設定する必要があることもあります。

Python Schedulerノードには Working Directory パラメータが備わっており、コード内でself["pdg_workingdir"].evaluateString()を使用することで、そのパラメータにアクセスすることができます。 慣例として、このパラメータには、localのフルパス、または、ファームファイルシステムのマウントポイントを基準とした相対パスのどちらかを指定します。

これは、ジョブのスケジューリングを行なう“実際のワーク”を実行する重要なメソッドです。 このメソッドは、ノードがワークアイテムを処理してスケジュールを組む際にコールされます。 このメソッドは、pdg.WorkItemオブジェクトをwork_itemとして受け取ります。

WorkItemデータを受け取って、それを使ってインテグレートしたい独自システム内でスケジュールが組まれたジョブを作成できるように、ここには スケジューラ特有の ロジックを実装しなければなりません。 そのロジックには、特定の変数が定義された環境でコマンドラインを走らせたり、依存ファイルをコピーしたり、スケジューラAPIをコールするといった処理が必要になります。

• command文字列アトリビュートには、ジョブを実行するコマンドラインを格納します。

• スケジューラが後でジョブを照会できるようにジョブ毎の固有なキーを必要/受け取る場合には、WorkItem.nameを使用してください。

• ジョブがスケジュールに組まれたら(または、エラーに遭遇したら)、このスニペットはpdg.scheduleResult値を返すようにしてください。

ファームスケジューラのAPIのポーリング(問い合わせ)を使ってジョブの進捗を監視したいことが多いです。 これは、onTickコールバックの実装によって行なうことができます。 このonTick関数の戻り値のpdg.tickResultは、PDGにバインドの状態を知らせます。

例えば、ファームスケジューラの接続が切れて復旧できなくなった場合にSchedulerCancelCookを返すことができます。 SchedulerBusyとSchedulerReadyは、onScheduleコールバックを制御できる準備が整っているかどうかをPDGに知らせることができます。 これを利用することで、サーバーや他のリソースの負荷を制御しながらフェームへのワークアイテムの投入を制限することができます。

tickPeriodとmaxItemsのスケジューラ系ノードのパラメータを使用することで、onTickとonScheduleのコールの頻度を設定することができます。

onScheduleStaticを参照してください。 これは、静的クックモードでのみ利用し、現在のところTOP UIには露出されていません。

ジョブのステータスが変更されたことをTOPネットワークに伝えるためのメソッドを必ず実装しなければなりません。 スケジューラソフトウェアから通知を受け取る方法は、実装によって異なります。 しかし、Houdiniには、再利用できそうなコードをバインドしたいくつかのスケジューラのPython実装が同梱されています。 $HFS/houdini/pdg/types/schedulersと$HHP/pdgのソースコードを調べることを強く推奨します。

スケジューラがジョブのステータスの変更があったかどうかをポーリング(問い合わせ)する必要がある場合、onTickメソッドでポーリングする必要があることに注意してください。

あなたが使用しているスレッドまたはコールバックで、常にself(Schedulerオブジェクト)を参照しなければならないことを忘れないでください。

しかし、スケジューラソフトウェアがジョブのステータスの変更を検知したら、pdg.Scheduler (self)の以下のメソッドのどれかがコールされます:

これは、ユーザがTOPネットワーク全体を単一ジョブとして投入した時にコールされます。 これは、あなたが実装するかどうか選択自由なオプションの機能です。 例えば、HQueue Schedulerには Submit Graph as Job ボタンがあります。

• graph_file変数には、クックするTOPネットワークを含んだHIPファイルのパスが格納されます。このパスは、そのTOPネットワークをクックするマシンの作業ディレクトリを基準としたパスです。

• node_path変数には、HIPファイル内のクックするTOPネットワークノードのノードパスが格納されます。

もし あなたがこの機能に対応したい場合、あなたのコード次第では、Houdiniを実行するスクリプトジョブを作成して、それをスケジュールに組んで、指定したHIPファイルを読み込んで、指定したネットワークをクックすることができます。

file_pathのファイルディペンデンシーをローカルマシンからリモート先(例えば、共有ネットワークドライブ)にコピーする時にコールされます。 これは、ワークスクリプトで必要となるファイルを作業ディレクトリにコピーするために使用します。 このスニペットは、ファイルのコピーに成功するとTrueを返します。

これらのスニペットは、work_item変数にpdg.WorkItemオブジェクトを格納します。 ワークアイテムのデータ(必要に応じてスケジューラのAPIも一緒に)を使用して、それに該当するジョブのログ/ステータスのページの場所を特定することができれば、TOPインターフェース上にそのログ/ステータスをワークアイテムの情報の一部として表示することができます。

完全に静的なジョブの代わりに、最終的に実行されるすべての子Taskを持ったファームジョブを 保留 状態のプレースホルダーとして事前に収集することが可能です。 次に、PDGクックが通常どおりに進むと、カスタムスケジューラは、それらのジョブがonScheduleコールバックを介して準備が整った時に、それらのジョブを アクティブ化 します。

この手法だと、ファーム管理者は、静的なジョブ表現と同様にクックの全体像を事前に把握することができます。

ジョブを事前に収集できるようにするために、カスタムスケジューラは、クックの開始時に静的に生成されたPDGタスクグラフを検査する必要があります。 このタスクグラフはpdg.SchedulerBase.dependencyGraphを使ってアクセスすることができます。 TOPグラフは、タスクグラフを照会する前に完全に生成されている必要があることに注意してください。

以下のサンプルは、指定したTaskグラフからDOTフォーマットグラフを生成する方法について説明しています。 このDOTフォーマットグラフは、Graphvizソフトウェアを使って閲覧することができます。

def taskgraphDOT(scheduler, dotfile=None):
    import sys
    dependencies, dependents, ready = scheduler.dependencyGraph(True)
    outf = open(dotfile, 'w') if dotfile else sys.stdout
    outf.write("digraph taskgraph {\n")
    for work_item, children in dependents.items():
        if not children:
            continue
        child_list = " ; ".join((child.name for child in children))
        if len(children) > 1:
            outf.write("%s -> {%s};\n" % (work_item.name, child_list))
        else:
            outf.write("{} -> {};\n".format(work_item.name, child_list))
    outf.write("}")

# 目的のスケジューラを取得し、Taskグラフを生成してそのdepグラフを取得します。
node = hou.node('/obj/topnet1/localscheduler')
sch = node.getPDGNode()
output_node = node.parent().displayNode()
output_node.cookWorkItems(block=True, generate_only=True)
taskGraphDOT(sch, '/tmp/depgraph.dot')