コンピューテーショナルデザインとオプショニアリング
昨今、建築業界ではコンピューテーショナルデザインが盛り上がりを見せています。一方、実際に「コンピューテイショナルデザイン」というと、多くの人は「あぁ、Rhinoceros,Grasshopperね」というイメージを持たれるような印象です。
ですが、それらはコンピューテーショナルデザインを実現するためのツールであって、ツールを使うことがコンピューテーショナルデザインではありません。
一方、私達のような建築構造に関わる人間としては、コンピューテーショナルデザインをどのように構造設計に活用していくか迷うところではあります。 そんな中で、少し前から、「オプショニアリング」という言葉を知りました。 Option + Engineering からなる言葉のようで、以下の記事によると「複数の選択肢を比較検証しながら案を決定する」というもののようです。
トルコで世界最大の免震建物が完成、設計期間はわずか1年
調べてみると、「Optioneering」で検索すると英語の検索結果が多くヒットしますが、「オプショニアリング」で検索すると上記の記事くらいしかヒットしません。 個人的には、「コンピューテーショナルデザイン」というより上記の「オプショニアリング」のほうが活用シナリオがよくわかったので、実践してみることにしました。
オプショニアリングに必要な要件
どのような機能があればオプショニアリングがスムーズに行えるのでしょうか。 私は以下と考えました。- 簡単にパラメトリックスタディを行うためのモデルを生成できる
- パラメトリックスタディの計算を現実的な時間で計算できる
- スタディした案を簡単に比較できる
このうち、3に関してはこれまでRESPで取り組んできた可視化や結果処理の技術を組み合わせることで比較的容易に実現できます。 問題は1,2です。 このたび、これらの1,2の要求をかなえるため、「RESP-D Script」と「Bunshin」という2つのシステムを開発しました。
RESP-D Script とは?
RESP-D Script とは、私達のチームで開発・販売している「時刻歴応答解析向け統合構造計算システム RESP-D」のモデルデータから、パラメトリックスタディ用のモデルを生成するための仕組みです。
2021年11月現在、この機能は試験的に内部運用している段階です。 試験運用の段階なので、いまの使い方はモデルデータ加工用の設定ファイル(以下、レシピと呼びます)をテキストデータとして準備すれば、それに応じて複数のモデルを作成できるというものになります。
たとえば、以下のようなテキストファイルです(JSON形式と呼ばれるフォーマットになります)。
{
"OutputDirectory" : "OE",
"Plans": [
{
"Code": "NoDamper",
"Description" : "ダンパーなしのモデル",
"Members": [
{
"MemberType": "Brace",
"MemberSubType": "Damper",
"Floor": [ "1F", "3F" ],
"Frame": [],
"Axis": [],
"ActionQueries": [
{
"QueryType": "Delete"
}
]
}
]
}
]
}
上記のレシピでは、「指定したモデルから、1F~3Fのダンパーを除去したモデルを生成する」という処理が記述されています。 その他にも、「ダンパー符号を変更する」「部材プロパティを一部変更する」といった記述が行なえます。
テキストデータを使う、となると抵抗を感じる方もいらっしゃるかと思いますので、今後は画面から設定できるようなプログラムも実装したいと考えています。 一方で、テキストデータがベースになっていることで、何らかのプログラミング言語で動的にレシピを生成したり、あるいはGrasshopperと連携させてレシピを生成する、といった可能性も考えられます。
Bunshinとは
RESP-D Scriptでモデルをたくさん作れるようになったとしても、計算時間が膨大になってしまえば本末転倒です。 特に計算負荷が大きい振動解析が必要だったりすると、計算時間の関係で質点系でスタディしたり、案を絞り込んで数パターンのみ検討、という形で妥協した経験がある方は多いと思います。そこで開発したのが「Bunshin」というシステムです。
本サービスも、試験段階の内部運用中となります。 Bunshinでは、計算をすべてクラウド上のマシンで行います。その際、1ケース1マシンとして解析処理を分散させます。これにより、ケース数が多くなってもすべてのケースを同時に計算開始できますので、大幅な高速化が期待できます。
これまでもRESP-Dでは、単一のPC内でのケースごとの並列処理は実装しておりますが、単一PCのCPU数には限度があり、実際には10並列以下が限度となります。また、並列させるほどメモリも大量に必要になるため、計算中はほかの作業を行えなくなる懸念もあります。
Bunshinでは、実際の計算はクラウド上のマシンで行いますので、自身のPCには負荷をかけません。そのため、理論上は100並列、1000並列も可能になります。
実践してみる
以下のような鉄骨20階建てのモデルのダンパー検討を行いました。Bunshinの効果を見るため、あえて地震動のケースは絞り込まず6ケース検討します。
ダンパー配置は、配置箇所を変えずに1階あたり4基設置とし、オイルダンパーの容量500kN,1000kN,1500kN,2000kNおよびダンパーなしの5プランを検討しました。
計算時間
計算時間として参考のため、1プランについて単一のPCで1スレッドで計算した場合とBunshinを使った場合の所要時間を計測しました。 Bunshinでは基本的には並列化数を増やしても、ダウンロード時間や結果の集計処理の時間が変わるだけで大きく計算時間は変動しないため、すべてのプラン(5プラン、全30ケース)を実行しました。結果を以下に示します。
単一PC (シングルスレッド) | Bunshin | |
計算時間 | 19分47秒 | 8分55秒 |
計算ケース数 | 6 | 30 |
1ケースあたりに換算した時間 | 198秒 | 18秒 |
完全にケースごとに並列化させれば理論上は最も時間がかかる1ケース分の時間ですべてのケースが計算できるはずですが、結果の集計時間やクラウド側のマシンの起動などのボトルネックの影響で、Bunshinの計算時間は6ケースで単一PCの半分程度にとどまりました。
ですが、Bunshinでは5プラン分並列で計算しているため、1ケースあたりに換算した時間で比較すると10倍以上高速化されていることがわかります。
この結果から、Bunshinを有効に活用するにはそれなりのケース数があったほうがいいことがわかりました。
数分で終わる計算数ケースでは単一のPCで並列計算を行ったほうが有利ですが、たとえば5分程度かかる計算を100ケースとか、1時間以上かかる計算を20ケース、のような場合にはBunshinは非常に有効に活用できると思います。
計算結果
計算結果の一部として、ダンパーなしと1000kNダンパーの結果を示します。今回は目標層間変形角を1/125とします。結果として、ダンパーなしだと大幅に目標値をオーバーしており、1000kNとした場合はぎりぎり満足していました。ダンパーなし
ダンパー 1000kN
つづいて各プランを比較します。各プランの包絡最大応答値の層間変形角を結果を比較したものが以下になります。 各プランの比較結果より、それぞれの結果を参考に以下のようにダンパー量を決定しました。ダンパー不要な階を減らしつつ、1000kNでも満足していたものの若干余裕が欲しかったため変形が大きい階は1500kNとしました。
決定案(黒一点鎖線)と各プランの比較は以下のとおりです。
今回のモデルはそれほど弾塑性が著しくなかったため概ね予想通りの結果となり、並列計算した各プランの検討結果が大いに参考になりました。
まとめ
- Bunshinによるクラウド分散処理では、数10から数100のケースを並列すると非常に効率が良い。
- RESP-D Script, Bunshin を活用すれば、いままで計算時間の関係で妥協していたプランの検討が現実化し、立体振動解析によるオプショニアリングができる。
なお、コンピューテーショナルデザインの真の意義は、ツールを使うだけでなく、「やりたいことに応じてツールをカスタマイズする」というところにあると思います。
特に、構造分野においてどのようにコンピューテーショナルデザインをどのように活用しようか模索されている方、アイディアを実現するためにRESP-Dを活用されてはいかがでしょうか。
カスタマイズ、ご相談も承っておりますので、お気軽にお問い合わせください。
採用情報
構造計画研究所 RESPチームでは、いっしょに働いていただけるエンジニアを募集しています。構造設計・構造解析だけでなく、プログラミング技術を活かして新しいものを生み出したいと思っている方、ぜひご応募ください。 採用HPはこちら→https://www.kke.co.jp/recruit/