On this page |
概要
![](../../images/pdg/for_loops.png)
TOPs Feedback Loopブロックは、一連の 直列による実行 工程を 何回も 実行することができます。
TOPネットワークは既になんというか並列ループのような挙動をしています。 というのも、TOPネットワークはスケジューラの設定に基づいて可能な限り同時にたくさんのワークアイテムを実行します。 つまり、"入力別に同じアクションを繰り返す"挙動はまさにTOPネットワークの挙動そのものなので、通常ではループを構築する必要がありません。
とはいえ、場合によっては並列ではなく直列に一連の工程を実行して、前のワークアイテムの出力をそれ以降のワークアイテムの入力として使用したいことがあります。
単純なシミュレーションなら、このような処理は既にROP Fetchノードを使えば制御することができます。このROP Fetchは同時に1ジョブ1フレームとして実行するバッチを生成することができます。
複数のノードが絡んだループまたはループさせる回数がまだわからないといったもっと複雑な使い方になると、 フィードバックループ を使用した方が良いです。
フィードバックループのブロック内では、TOPネットワークはノード毎にワークアイテムを実行するのですが、下流のワークアイテムが上流のワークアイテムに依存した状態で、それらのワークアイテムを直列に実行します。 そして、1回目のループですべてのワークを完了させた時に、そのブロックに2回以上のループ回数が指定されていれば、Beginノードに戻って次のループに進みます。
Tip
設定によっては、フィードバックループのブロックは、並列で 複数の直列ループ を実行する こともできます 。
例えば、1回づつ一握りのビー玉を瓶に詰めていくRBDシミュレーションを想像してみてください。 この処理全体を単一シミュレーションで実行することができますが、瓶の底に積み上がっていくビー玉は安定せず、次々にシミュレーションされるオブジェクトの数が増え続けていきます。 これを管理する1つの方法は、1回目に詰める一握りのビー玉に対してRBDシミュレーションを実行し、その結果を2回目のシミュレーションの静的オブジェクトとして使用することです。 3回目のシミュレーションでは、1回目と2回目のシミュレーションの結果を合わせたビー玉を静的オブジェクトとして使用します。それ以降のシミュレーションも同様です。 TOPsでは、ROP GeometryとFeedback Loopをループブロック内で使用することで、このような処理が可能になります。
(Feedback Loopはコマンドサーバーチェーンの実装でも使用します。その場合、1回づつコマンドをサーバーに順々に送信してください。)
How to
To... | Do this |
---|---|
Feedback Loopブロックを作成する |
|
ループ内のワークアイテムに基づいて"副タスク"を並列でクックする |
![]() ループ内のノードからループ外のプロセッサに接続した場合(つまり、ループのEndノードに接続しなかった場合)、そのプロセッサのワークアイテムは、ループ内のワークアイテムに基づいて生成されるようになりますが、 通常通りに並列でスケジュールが組まれるようになります。 これは、ループ内のワークアイテムに基づいているもののループさせる必要のない"副タスク"で役立ちます。 例えば、ループ内では画像を生成してからその画像を制御していきたいような場合では、ループ外ではその生成された画像のサムネイルを並列で生成することができます。 |
Tipsとメモ
-
フィードバックループにはどのプロセッサノードも使用することができます。とはいうものの、現在のところ、フィードバックループ内では動的なパーティショナまたはマッパーを使用することは できません 。パーティションに同じループ回数目からのワークアイテムのみを含める場合であれば、 静的な パーティショナーを使用することが できます 。別のループ回数目のワークアイテムを無理やりパーティション化すると、そのパーティションノードはエラーを報告します。
-
ブロックのBeginノードとEndノードは、その関係性をわかりやすくするために同じカラーを設定してください。For-Loopツールで配置されたデフォルトのノードのカラーはオレンジですが、そのノードのカラーを変更することができます。これは特に入れ子化したループと区別するのに役立ちます。
ブロックを囲んだ境界は、Endノードのカラーと同じになります。
-
Beginノードは、ループさせるワークアイテムを生成するプロセッサです。
-
各ワークアイテムは、同じループの前のワークアイテムに依存し、その反復回数とループ番号を識別するためのアトリビュートを持っています。
Block End Feedbackノードは、関係しているループの反復に基づいてワークアイテムをパーティション化するパーティショナーです。 フィードバックループ内のノードは自由に必要な数だけワークアイテムを追加していくので、パーティショナーはそれらのワークアイテムを収集することができて便利です。 Beginノード内の2回目のループのワークアイテムは、1回目のループのパーティションに依存します。それ以降のループも同様です。 ループが動的にワークアイテムを生成する場合、そのBlock End Feedbackノードの Use Dynamic Partitioning も有効にしなければなりません。
-
フィードバックブロック外のノードを、フィードブロック内の複数入力を持ったノードに接続することができます。
TOP Attributes
以下のアトリビュートの名前は、このノードのパラメータを使って設定することができます。
|
[int] |
ループの反復回数。入れ子のフィードバックループを使用する時は、レベル毎に反復回数を指定したいので、このアトリビュートには配列値を指定することができます。
一番外側のループのループ反復値は |
|
int |
ワークアイテムがどのループに関連しているのかを追跡します。
このアトリビュートは、同じFeedback Beginノード内で複数の独立したループを生成させる時に関係します。
例えば、 |
|
int |
現行ループの合計の反復回数。 |
Tip
ループを入れ子にした場合、配列を扱わなくて済むように、loopiter
/loopsize
アトリビュートの名前にレベル毎に異なる名前を付けても構いません。
パラメータ
Work Item Generation
このノードが静的または動的なワークアイテムのどちらを生成するかどうか。 このノードのワークアイテムが静的に計算可能かどうか、もしくは、動的に生成させる必要があるかどうか分からないのであれば、通常では、これを"Automatic"のままに設定してください。
Dynamic
このノードが常に動的なワークアイテムを生成します。つまり、上流のワークアイテムが判明するまで待機し、その上流のワークアイテムから新しいワークアイテムを生成します。
Static
このノードが常に静的なワークアイテムを生成します。つまり、ネットワークを実行する前にパラメータ(と上流の静的なワークアイテム)に基づいて必要だと思われるだけの数のワークアイテムを生成します。
Automatic
入力が静的(静的なプロセッサ、静的な入力のみを使ったパーティショナー、マッパー)な場合、このノードは静的なワークアイテムを生成し、そうでない場合、動的なワークアイテムを生成します。
Iterations from Upstream Items
Iterations パラメータの代わりに入力の静的なワークアイテムの数に基づいて反復回数を設定します。
Iterations
Beginノードに上流のワークアイテムが存在すれば、入力のワークアイテム毎に、ここで指定した回数だけループが実行されます。
Copy Inputs For
入力ファイルをループアイテムにコピーさせる方法を決定します。 デフォルトでは、上流のファイルがすべての入力ファイルにコピーされますが、1回目のループだけ入力ファイルをコピーすることも何もコピーしないこともできます。
No Iterations
上流の入力ファイルをどのループ反復アイテムの出力にもコピーしません。
First Iteration
上流の入力ファイルを1回目のループの出力ファイルリストにのみコピーします。
All Iterations
上流の入力ファイルをすべてのループの出力ファイルリストにコピーします。
以下のパラメータを使用することで、このノードで生成されるワークアイテムアトリビュートの名前をカスタマイズすることができます。
Iteration
ワークアイテムの反復回数を含んだアトリビュートの名前。
Number of Iterations
反復回数の合計数を含んだアトリビュートの名前。
Loop Number
ループ回数を格納するアトリビュートの名前。
Examples
example_top_feedbackbegin Example for Block Begin Feedback TOP node
このサンプルでは、フィードバックループの作り方について説明しています。
See also |