前回の記事(【構造解析Tips】クラウド分散処理を活用してRESPでオプショニアリング(コンピューテーショナルデザイン))は、
構造の世界に関わるコンピュテーショナルデザインに対して、RESPを用いたオプショニアリングの概念を提唱し、それを実現するためには
  • 簡単にパラメトリックスタディを行うためのモデルを生成できる(RESP-D Script)
  • パラメトリックスタディの計算を現実的な時間で計算できる (Bunshin)
  • スタディした案を簡単に比較できる(RESP既存の結果処理および可視化の取り組み)
が必要と説明しました。 今回は、そのオプショニアリングをより運用しやすくするため、意匠の世界で大人気のGrasshopperとの連携の可能性を探ってみました。

なぜGrasshopperを視野に?


私も実務でRESP-D Scriptを試用して、パラスタ用のモデルを効率的に生成できて非常に便利でした。一方、そのために用意するデータ(レシピとよびます)はJSON形式のテキストデータであり、構造設計や構造解析をする方には少々扱いにくいものと思いました。 特に、大量の検討ケースが存在する場合、いちいちエディターでJSONファイルを編集するのは、操作性および可読性に欠けます。編集中に「あれ、何ケースを作ったっけ?」と混乱する場面は少なくありません。 そこで何かインターフェース的なものがあったらいいなと、最初に思いついたのはGrasshopperです。意匠の世界でよく使われているとはいえ、Grasshopper自体は「ビジュアルプログラミングの環境」であり、使い方によっては構造の世界でも十分活用できそうと感じました。
特にパラメトリックモデリングと可視化に特化した環境(ツール)として、今回のRESP-D Scriptとの相性が非常にいいです。無論、RESP-Dに内蔵したUI、あるいはウェブアプリの作成なども考えましたが、やはりエンドユーザーでもカスタマイズできる環境という点を考慮すると、Grasshopperは優位に立ちます。 正直なところ私も普段Grasshopperを使う機会が少なく、今回は勉強を兼ねてGrasshopper上でRESP-D Script(レシピ)の生成&実行の簡易ツールを作ってみました。
下記、このツール(GHforRESPと呼びます)を説明しつつ、RESP-D Script & Bunshin の使い方も紹介していきます。

簡易ツールGHforRESPの紹介


極単純なツールではありますがイメージ図は下記図1になります。

図1

Visual Studioなどの開発環境で専用のコンポーネントを作る路線もありますが、今回はエンドユーザーの視点から、手軽さ重視という方針で、既にGrasshopperに搭載されているGHPython Scriptを使いました。 ツールは図1のように4部分に分けられています。こちらは実際にRESP-D ScriptとBunshinを運用するときの手順でもあります。
  1. (青)検討ケースの生成部。一つの青色ブロックは1ケースを意味します。
  2. (紫)レシピの生成部。青で設定した内容をJSONファイル(RESP-D Script)として生成します。
  3. (緑)レシピの実行部。ワンクリックだけでパラスタ用のファイルが自動的に生成されます。
  4. (赤)Bunshinの実行部。大量のファイルをクラウド上で同時計算します。
仕様の説明は下記になります。
  • 入力部分:主にGrasshopperでよく使われているPanel、Value list、Number slider、Boolean Toggleを使用しています。
  • 処理部分:今回は実質GHPython Scriptコンポーネントしか使っていないため、全てPython言語で実装しています。
  • 出力部分:JSONファイル、各ケースのRESP-Dのdzファイルの生成および、クラウド上で計算するためのバッチファイルの実行です。

実践してみる

図2の制振間柱ダンパー(オレンジの部材)が沢山配置されている超高層建物に対して、上からダンパーを一本ずつ(①、②、③、④… ⑭まで計14ケース)減らして、各層の層間変形角がクライテリアをクリアしているかを確認しつつ、どこまでダンパーを減らせるかの検討を例に実践してみます。

図2

14ケースのモデルファイルを効率的に生成するためのRESP-D Scriptの一部を下記に貼ります。
▼ここをクリックしてRESP-D Script(JSON)を展開/折りたたむ
まずは今回のツールを使って上記のJSONファイルを生成します。
図3のように青のブロックで第1ケースを作ります(ダンパー①を削除します)
Memberコンポーネントとは、変更を行いたい対象部材を指定するコンポーネントです。
  • MemberType, MemberSubType:プルダウンメニューからColumn、HystDamperを選択して、編集の対象となる要素(間柱ダンパー)を指定します。
  • Floor, Frame, Axis:対象間柱ダンパーの場所を指定します。RESP-Dの指定方法と同じです。(単体も範囲指定も可能)
  • ActionQueries:指定した要素に対しての操作を選択します。今回は「削除」、「Delete」を選択します。
次はCode number(ケース名)、Description(ケース説明)を設定し、各入力項目をコンポーネントと接続すれば、ケース1の設定が完成となります。 ちなみに、コピーにより複数のMemberコンポーネントを作ることも可能です(複数のMemberコンポーネントをPlanコンポーネントの「Members」と接続すれば完成です)

図3

青色ブロック範囲内の内容を丸ごとコピーして次のケース(ダンパー①、②削除)を設定できます。最終的に、図4のように、( 図4はブラウザー上で見にくいですが、ctrl+マウススクロールで拡大してみてください)
各検討ケースのPlanコンポーネントを、レシピ生成部(紫)の「Plans」に接続すると、Grasshopper上でRESP-D Scriptの設定が完了となります。


図4

そのほかは、パス指定やファイル名指定など一般的な設定となるため割愛します。逆にこの辺りの設定は一回だけすれば基本は変更する必要はありません。
図4の示した通り、元のdzファイル(x_project.dz)をベースに、x_project-Plan2.dz(ダンパー①削除)と x_project-Plan3.dz(ダンパー①、②削除)二つのファイルが自動的に生成されました。早速dzファイルを開いて意図通りのモデルになっているかを確認します。

図5

指定したダンパーが削除されたモデルの生成が成功しました。あとはどんどんGrasshopper上でケースを追加して、最終的にBunshinの実行部(赤)のrunボタンを押すと大量のdzファイルをクラウド上で並列計算を行うことができます。 本来この検討は、元のRESP-Dファイルを大量にコピーし、いちいちRESPを立ち上げて部材削除、計算実行を十数回も繰り返してやる必要はありますが、上記のツールで簡単にパラスタ用のモデルを生成できました。さらにBunshinを活用することで計算時間も大幅に短縮しました。(【構造解析Tips】Bunshinによるクラウド分散処理で大規模モデルの立体振動解析を4倍以上高速化した
今回の業務は、正確に時間を測っていないのですが、モデル作成~計算終了までの時間は本来の1/10になっても過言ではないと感じました。

Grasshopperでやってみた感想&まとめ


今回は、RESP-D Scriptの各機能に対応した簡易コンポーネントを実装することによって、Grasshopper上でRESP-D Scriptの可視化をやってみました。
個人的にGrasshopperを採用する運用面と開発面のメリットとデメリットを下記にまとめます。 メリット:
  • (運用)dzファイルを開かなくても、各検討ケース、パラスタの内容を目に見えてわかりやすい
  • (運用)操作はコンポーネントのコピペやボタンを叩くだけでGrasshopper初心者でも使える
  • (運用)初期設定(パス指定、ファイル名指定)さえ完了すれば、パラスタのケースを素早く生成できる
  • (開発)ビジュアルプログラミングのおかげで、インターフェース(入力と出力)を気にせず、内部処理だけを実装すればよいので、プログラム初心者にやさしい

デメリット:
  • (運用)検討ケースがものすごく増えてくると、Grasshopper上でも見づらくなる可能性がある
    • その場合は、clusterなどの機能で対応したほうがいいかもしれません。
  • (開発)Grasshopperの開発環境や固有仕様に囚われる
    • 今回は、私のGHPython Scriptのpythonバージョンは2.7.8であり、さらに外部ライブラリが使用不可のため、結構苦労していました。
      自分のPCのpython環境と合わせる方法、あるいは外部エディターで編集する方法もあるようですが、安定性には確信がないため、また今度試してみたいと思います。詳しい方はぜひ教えてください。
      今回の実装の一部は下記の記事を参考させていただきました。ありがとうございました。
      https://zenn.dev/keiwatanabe/articles/ghpython-dictionary-output
  • (開発)コンポーネントの種類が増えてくると、Grasshopper上で管理するのは限界がある。
    • 大規模な開発をする場合は、手軽さを犠牲にVisual Studioなどの開発環境で汎用性のあるコンポーネントを作って、プラグインとしてGrasshopperに組み込むのは選択肢の一つです。
今後は、引き続きコンポーネントのプラグイン化や、RESP Script新機能の対応に取り組んでいきたいと思います。Grasshopperに限らず、やはり「やりたいことに応じてツールをカスタマイズする」に醍醐味を感じますし、RESPチームの特徴でもあると個人的に思いました。

返信を残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です